I’ve long been a fan of CVS. I’ve used CVSNT and TortoiseCVS for ages. It’s a great (and free) way to keep my source code in check. I’ve scripted it on Unix with automated build and deploy scenarios. I’ve saved my bacon more than once with it in Windows when I got down a coded road that just didn’t work out. CVS is cool.

I’ve always wanted to test out Subversion – see how green the grass was on the other side of the fence. Eric Sink’s presentation to the Arizona .NET User’s Group was just the push. In passing, while discussing something else, he mentioned that anyone still using CVS should get onto SVN. Ok, time to make the move.

First step, I signed up to co-present Intro to Subversion at the Desert Code Camp – something about buring the ships in the harbor. It was by far the best move I could’ve chosen.

Next up, I fired up VMware, and created a “subversion sandbox”. I installed Subversion, the Windows Service wrapper, and TortoiseSVN. It was a natural fit from using CVSNT and TortoiseCVS. Ok, versioning folders was a bit weird at first. But TortoiseSVN even played nicely with TortoiseCVS’s hog of the available Windows Icon overlays. (see here.)

Next, I sat with the red book. I think my wife was not overly thrilled when I brought it to bed. It was great reading though. Ok, armed with knowledge from front to back, I was ready to tackle the conversion.

I installed CVSNT, TortoiseCVS, copied my repository onto the VMware session, and made sure it was good.

Next, a few more downloads: cvs2svn, python, the subversion python bindings, WinMerge, the kitchen sink, and some boots. (Actually the cvs2svn docs were great. Though the recipie was long, it was detailed, and effective.) I noted that since I was using CVSNT, I was in “uncharted territory”. I used the –use-cvs option. I also put svn, python, and cvs2svn in my PATH.

Since I work with various clients and various projects, and I didn’t want to flood the repository version number for unrelated content, I decided one repository per project. Splitting it out this way was actually quite easy. I just pointed cvs2svn to the project folder, and pushed go.

The conversion froze at various points with very undescriptive details about what I thought it wasn’t doing. Just when I was to give up, it’d pick right back up with the next step. I lost a few fingernails, but the data was gorgeous.

Once converted, I did some litmus tests: check the files out, are they the same as the ones I’m using for live development? Just about without fail, the crystal reports .rpt files imported as text files, and thus had inconsistent line endings. Off to Google University. A helpful post I’ve since lost pointed me to ‘svn propdel svn:eol-style’. All is now well.

Once WinMerge says the files are good, I copied the subversion repository into the main code production mechanism, copied the checked-out projects into the Visual Studio directories (to get the .svn directories spread everywhere), and it’s running. Ok, I had installed Subversion, TortoiseSVN, and the Windows Service in code production by now.

Quite honestly, the conversion was no big deal. It was more stress and careful planning than anything.

Ok, I’ve got svnserve running via the windows service. I’m working on authentication and authorization. I’ve got the svnserve.conf, passwd, and authz files set just so. I’m not overly thrilled that my password is in plain text in passwd, but I’m on a LAN, and the server is protected. Fine.

Back to the Code Camp presentation. Wendy, the co-presenter is awesome. My zeal for Subversion combined with my presentation experience, and her deep knowledge of the inner-workings of everything combined with her history of open-source and infinite contact network, and we’re a team to be reconed with. During our presentation practice, I start moaning about how I really enjoyed CVSNT’s Windows Authentication mode. She says use Apache to host Subversion, then use some mod_auth_something_or_other. Um, duh. In an instant, the 2x4 between the forehead, the synapses connect, and it makes sense.

Back to the VMware session. I spend Friday night. I start at 8 or so, end at 2 or 3 am. I get Apache installed, configured to port 81, get mod_auth_sspi.so installed and fired up, modify passwd, authz, and httpd.conf about 800 times, and it’s golden. In hind-sight, I’m sure the magic settings were probably within a character or two the whole time.

But now I’m shouting from the roof tops. I’m dancing a jig. (yeah, at 3 am.) I’ve got Subversion behind Apache, Windows Authentication, TortoiseSVN as a client, a batch file for creating and initializing repositories, and a presentation that just rocks. (Code Camp also went very well, by the way. I only called TortoiseSVN by my formerly well-known TortoiseCVS once.)

Ok, now that I’ve got Subversion up and running, the world opens up: CruiseControl.NET, TRAC, all those SourceForge and Tigris projects I wanted to wander through, but didn’t want to burdeon my bread-and-butter machine, life is gorgeous. Subversion is the bomb.

A few parting thoughts: I told Subversion never to check in these files (Global Ignore Pattern in the first screen of TortoiseSVN’s preferences): */bin */obj .cvsignore *.user *.suo */Debug */Release Other than that, everything is pretty much running out of the box.

I agree with Wendy that a better place to put these is in each repository’s ignore list. But since I’ll likely jump between repositories as often as the clients do, having one global setting – in spite of it being client-side – is nice. Some day, I’ll figure a way to script it into my automated repository creation script…

Some day I may also be brave enough to install Ankh, though I’d really rather see VisualSVN on my machine. Ankh just feels really heavy. If VisualSVN can get overlay icons in the solution window, I’m sold. They track renames and moves in the solution window, but they’re not great at catching the related .designer.cs files. For now, TortoiseSVN is doing just fine.

Rob