Source control is the bedrock of your development effort, it contains the history of your entire project and it’s too important to trust it to VSS. Visual Source Safe is a horrible source control system and i keeps you from being productive.
Teams using VSS love to use exclusive locks on source files, this only creates contention for files and kills the team’s productivity. Even worse, VSS’s doesn’t support branching which makes refactoring your code doubly difficult, all your changes have to be made offline and manually merged into the “trunk,” and only is VSS insanely slow it has no concept of transactions, if a bug fix required you to change and check-in multiple files at once, there’s no way to figure out which files were checked-in together using VSS’s history feature.
SVN is a much better, free alternative to VSS, which supports many features that you expect from a modern source control system: branching and merging and transactions and atomic commits.
If you think your project’s history is stuck in VSS, it’s not, there’s a great migration tool called vss2svn which lets you migrate your entire VSS repository along with the project history to SVN.
You’ll need to download and setup SVN server and create a repository and users for your projects first, I recommend using VisualSVN Server if you’re on Windows. What follows is a painfully long migration, but it’s well worth it in the end.
- Download and extract vss2svn to a hard drive which has plenty of space, as a general rule, you should have enough space to hold three copies of your VSS repository;
- After making sure that your repository does not have any files checked out, take your VSS repository offline by disabling all access to it, then create a backup of your VSS directory; at this time, you should also delete/destroy any files/projects you do not wish to migrate to svn.
- Run the analyze command on your VSS repository, you’ll have to run analyze several times if the analyze utility encounter errors in your repository– this is very time consuming and but an important step.
- Now you’re ready to run the migration utility from the command prompt. You’ll need to use the following command: vss2svn.exe –vssdir <dir> where <dir> is the directory which contains the scrsafe.ini file. vss2svn.exe will generate a svn dump file which you’ll later import into your svn repository;
- finally, import the dump file generated by vss2svn by using the following command on the machien where your svn repository resides: svnadmin load /path/to/repository < dumpfile.txt
Related posts:
Yay for moving off to a much better source control provider!
Ben Scheirman - 28 Mar 09 at 6:21 am
I’ve done this migration 2 or 3 times now
Shey - 28 Mar 09 at 1:34 pm
What about sharing one or more files across sub-projects. SVN’s recommended approach is SVN:externals that is set outside of SVN and hence has to be done for every user separately.(Import/Export of these settings is surely a work around).
Also we’ve expereinced weird problems with SVN’s conflict resolution where sometimes one programmer’s header is merged with another programmer’s code body. It has to be monitored and sometimes done manually.
The reason to cite these problems is not to dis SVN (which has its own strengths) but to recognise that your choice of configuration management is a variable factor that differs from organisation to organisation. Have a good day.
Fawzia - 9 Apr 09 at 11:46 am
You don’t need to set externals for every user and you can add links to files (instead of copying them) in a project.
Sheheryar - 9 Apr 09 at 9:00 pm
This is exactly something I must do more research into, thanks for the blog post.
Yuonne - 11 Nov 11 at 3:33 pm