Lately I was very successful at evangelizing Subversion at turning people away from SourceSafe. Before you can turn developers away from anything, solid migration strategy is needed so here is how I do it...
Step 0: Setup Subversion
You need to set up Subversion, create at least one repository and create logins. This is quite simple if you follow instructions.
If you don't need to expose Subversion to the world, you really don't have to bother with Apache. Just set up svnserve to run as a window service and of you go. If you run Linux, you probably already have Apache up and running so you can use that.
My tip: I usually ad extra repository for developers to play with, store their own projects and so on. Tell developers, that they can store SQL files, configurations files, documents and much more on Subversion. It's not just for code! One day you'll be thankful they did. I also use this repository for test migrations.
When your Subversion server is up and running you can do migration.
Step 1 (optional): Check in everything
It's a good idea to tell everyone to check in the changes they have made and stop changing the code. Since this is not always possible you can skip this step and do little wrapping up at the end.
Step 2-A: If you just want to move source code and you don't care about source code history
This is a simple and fast way to migrate. You will not loose your history it will just become split. Before migration you will have to look it up in SourceSafe and from migration on it lives in Subversion. For small projects and teams this just might be good enough. But if you have a large team or want to completely get rid of SourceSafe skip to next chapter and migrate your history too!
Get latest version of your source code from SourceSafe.
Open the solution/project or whatever your current IDE calls the main wrapper around your code and unbind and disconnect from SourceSafe. Only Deleting .vsscc, .vssscc files will not help. At least not in .NET. .NET project files (*.csproj, *.vbproj) also have information about source control server so it's easiest to do it from Development Environment.
Create a new folder on Subversion server and do an initial commit of all your files.
Step 2-B: If you would like to carry source code history to new Subversion server
I use a utility VSSMigrate to do migrations when I need to preserve history. Since source code is available I did some minor adjustments to the code, especially handling special characters in comments and file names.
I usually prepare a migration folder like this:
- /win32 - I put a copy of SourceSafe 6.0d in here. Utility will run ss.exe heavily and 6.0d is a recommended version. If you only have 6.0 be sure to install Visual Studio 6 service pack 6.
- /work - temporary folder VSSMigrate utility will use.
- /VSSMigrate - copy of VSSMigrate executables in there.
VSSMigrate is little tricky. You should always run it from it's own directory so I create run.bat file and call that. You should provide a .ini file with settings as the only parameter.
I put VSSMigrate .ini in root of my migration folder for easy access. If you run VSSMigrate and it says it didn't find ss.exe it's usually because you didn't run it from it's folder. I got burned by this several times.
Another problem you might encounter is missing SSDIR environment variable. Best way to solve this is to put something like
set ssdir=\\<vssserver>\<vssfolder>\
in run.bat which I mentioned before.
Do a test migration first. Setup you VSSMigrate.ini so that it will do a migration in completely separate repository so you don't mess up with your production repo until you are ready. If you encounter an error during migration you can usually see what has gone wrong from the error message and text files in your working folder. If your migration fails you should open Repository Browser, delete migrated files, get rid of a problem and start again.
If you have problems with special characters in filenames you can rename them on SourceSafe before migrating.
I also had trouble with Unicode comments that were copy/pasted from email and I had to dig into C++ code of VSSMigrate and filter them. So you'll want to get VSSMigrate code, import it into your own Subversion source control and recompile. You'll need VS 2003 or VS 2005 with Visual C++ install in order to compile it.
I also changed original project so that MFC library is statically linked if you'll run this on a server without libraries installed.
Step 3: Cleanup
Now it's good time to get rid of all the files that don't belong to source control. Since you are protected by Subversion you can afford to make mistakes. In VS 2005 you can click on "Clean Solution" if you right click on Solution in Solution Explorer. For VS 2003 your best bet is Cleanup Sources Plus. You can also use Cleanup for VS.NET 2003 Solutions tool which does a good job of cleaning up. Don't forget to commit your changes.
My tip: rename your projects folder on SourceSafe. This way if anyone by accident still uses old source code they will get an error that the project doesn't exists. But the code is not lost. It's just under renamed directory. I usually use name = "_MOVED_TO_SVN_" + old_name.
What you really want to do after migration is to compare latest code from SourceSafe and latest from Subversion and compare them. I exclusively use WinMerge for code comparison but you might prefer another tool.
At this time you'll also want to tell developers that didn't check in files before you started migration to simply copy changed files over those that are under Subversion source control and check for changes.
Step 4: It's a wrap
That's is. You developers should now install TortoiseSVN, VisualSVN and any other Subversion client and under an hour you can teach them how to live peaceful life where code is safe.
If you need help with your migration, drop me a line using my contact form or comments and we will work something out!
Browse related articles on this site!