In case your thinking about transitioning between Visual source safe ( VSS ) and Subversion ( SVN ), read on…
As a developer using VSS you end up spending a lot of time fighting VSS instead of having it do it’s thing as a normal repository should. At least that’s the usual story on bigger projects, VSS isn’t even considered a repository by a lot of developers, VSS is limited to 4GB in size.
I choose SVN as it’s really solid and fast, it doesn’t spoil that it’s open source and FREE of charge. SVN is considered one of the best, SVN is built on CVS and takes it to the next level. The installation on windows is a breeze it is available for other platforms as well. On top of that you can install apache server to allow access to the repository over http. If you have build scripts you need to create your SVN repository and make sure the scripts are building against it before you let your developers transition over. In our case I just sucked in the the VSS source tree into SVN. By doing it that way it does not include history from VSS, but it’s good enough to get the build scripts working.
Once we had the builds working correctly using SVN instead of VSS it was time to think about the final transition. That includes of course a code freeze, meaning no more checkins into VSS. The next checkin by the developers will be into SVN. We happened to be delivering a version around the same time as this transition between the repositories was talking place. A perfect point in time to transition just after the delivery of the new version.
With the build working using SVN the source was deleted from SVN as it didn’t include any history information from VSS. Then I went hunting for a good migration tool. VSSMigrate seemed to fit the bill It’s a simple C++ program, the author graciously includes the source code in case you need to modify it to fit your needs. I doubt you will need to, it works great straight out of the box. There is a simple configuration ini file where you put in your parameters about each repository, user / pass the usual. Kick it of and it will do the transition for you, it takes a while to run for a big project with a lot of checkins. This is because it will check in all revisions of the files along with the checkin comments from VSS and a VSS version tag. One manual step is needed, you will have to open up your project and solution files and remove all SCC / VSS references, otherwise VS will still try to bind your solutions to the old VSS repository.
The recommended directory structure in SVN is a little different than what we are used to in VSS. Below is a outline that most people follow for SVN and makes life easy once you start using it.
– trunk ( this is the directory that will hold your projects )
– tags ( this one holds tag / label directories from the trunk )
– branches ( this one holds branches from tags once you decide that you like to branch a tag / label )
For the SVN client we will use Tortoise which again is FREE. Tortoise integrates nicely into file explorer, all commands are one right click away or two of the menu. The commands in SVN are a little different than in VSS, but the usual checkout / add / delete / commit ( checkin ) are all there, of course a lot more similar to CVS than VSS. However the transition period from VSS to SVN for the developers should be pretty short as most of the commands are self explainatory.
Here is a short tutorial on using the tortoise SVN client, it goes through the basics.
If you also want SVN integrated into Visual Studio check out the SVN ankhsvn plugin. It’s pretty nice and works even better than the VSS plugin.