A few weeks ago a couple of colleagues and I established that our source control system (VSS 6.0d) needs to be updated. There were numerous issues that were plaguing our daily struggle with Source Safe – slow speed, frequent crashes and file corruptions. Naturally we began looking for alternatives of the aging software (version 6.0 was originally released with VStudio 6.0 and was only patched a bit with the release of VS.NET in 2002).
In a nice bit of synchronicity with our efforts, Visual Studio 2005 was just released and introduced a brand new version of Source Safe (it was internally labeled 8.0 – they even skipped a number!). Our hopes and expectations were high once we read what has changed in this version: Faster and more robust engine, Unicode text file support, proper web application binding and improved LAN access were the items that immediately caught our attention.
Having read through the docs, the next step on the agenda was to install VSS2005 and try to do the migration of the database on one of our test machines. It all went smooth to the point where I ran the analyze tool against the new database. It started reporting a lot of errors and inconsistencies, however, when it finished it said no critical problems were found. I’ve played around with the database to ensure no files or history is missing. It turned out that everything is ok. With a sigh of relief we scheduled the migration of our production database for the day after. After backing up the VSS folder (Always back up your stuff! You will see why very soon!), we upgraded to VSS2005 and ran the analyze tool. Those of you familiar with it know that it takes quite a while to finish checking everything, so we decided to go home.
The first piece of bad news came early in the next morning. The analyze tool did not run successfully. Actually, not only had it not run successfully, but it also corrupted our database beyond repair. Good thing we made that backup! After some research it was obvious that the old database was far too big and far too corrupted to be useable. We decided to split the thing into three new databases and import the old projects into the appropriate database. I would not go into details, but the whole process took about three days (the whole weekend and Monday) and was very painful. After the migration was complete I’ve created a daily (well it runs @ 4:00AM) task that runs the analyze tool against all three databases and scheduled a disk defrag right after that to maximize performance. We are also making backups daily.
Everybody here has been using the new databases for some time now and I must say that we can feel a slight performance improvement. More important, there have been no errors and corruptions reported so far. The whole migration did not go as smoothly as we anticipated, however, it was desperately needed as the old situation was beginning to slip out of control.
Do you use VSS2005? Let us know of your experience with it and if you had any troubles migrating. Feel free to drop us a line if your organization is using Visual Studio with a non-Microsoft source management system and tell us if you are having issues with it.
Vladimir Milev is a developer manager.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.