Using Subversion for source control is all the rage these days. Everyone’s doing the svn dance. In fact, my most popular blog posting is about vss to svn migration, so at least it’s a hot topic here anyway. I assumed there’s lots of people making the switch out there, and figured I’d write up a few things to think about if you’re considering the move.
Why subversion? Mostly because svn just works. It’s a great little tool for doing what you’d expect of a solid source control system. It’s lightweight, so you can use it just about anywhere. Also – it’s free, which is always nice. There are plenty of other options out there, and each have their merits. This particular post is about the journey from vss to subversion.
1. Why? Are you sure? Switching source control systems can be a real pain, especially if you’ve got a boatload of source. It’s definitely worth the effort in 99% of the cases, but sometimes the payoff just isn’t worth the disruption. If you’re a heavy Microsoft shop for example, you might want to consider jumping in with both feet and just moving on to the whole Team Foundation thing.
That being said, subversion rocks. Use it. 🙂
2. Preparing the new repo – You’ve got to install subversion somewhere, and create your new repository. You’ll need to decide if you want to use the svn: or http: protocol to access your repo remotely, most people just tunnel it thru apache over http:.
You’ll want to start off with a nice clean, standardized layout for your new repo. A safe bet is to use the old “trunk, tags, branches” route, with some default dirs in place (src, web, db, qa, lib, whatever).
If you’re not sure about installing/hosting it yourself, there are a handful of places that’ll do it for ya (dreamhost, cvsdude, … )
3. Exporting the stuff from vss – The trick here is to do it cleanly. You’ll most likely end up needing to delete all the .vssver files and whatnot. Also, decide if you really need the entire history of files in your new repo… that could get hairy. Migrating to svn AND keeping all of your checkin history intact in svn is outside the scope of this posting. We decided we didn’t and kept a backup (read only) copy of the old vss db around “just in case”. You know, in case we ever needed to refer to something 3 or 4 years old.
Guess what? We never looked back. 🙂
4. Importing the stuff to svn – This is where it can get fun. You’ll want to map your existing vss repository’s directory layout to your shiny new one. I ended up using a little perl script to get them all added into svn correctly. (vss2svn.zip)
5. Updating other various things and people – You may have some existing systems already pointing to your vss repo, make sure to list them all out and get em updated. We had a handful of build scripts that needed to be update to point to the new repo.
Also, be sure to communicate effectively to your team. You might even need to do a little PR for the effort, so make sure you’re clear on #1 above. Provide your users with ample docs and support info to make the transition easier. Maybe host a couple “svn how to” sessions, to get things moving.
6. Testing This needn’t be too complicated, just walk through a handful of typical use cases. For example, do a few svn checkouts, make sure you can connect and everything’s cool, try a build or 2 from svn, etc.
The key here is to find and address (or figure out workarounds to) the most likely issues, and be ready to help your users get around em.
7. Relax and have a beer You’re off! Now just relax, watch your source get modified, and start forgetting about “vss analyze and fix”
🙂
Release Management 