The reasons first:
- I wanted atomic commits, so I wouldn't break the repository so easily.
- Wanted atomic changelogs so I could have a nicer web front-end.
- Wanted directory histories, since moving files in CVS is a pain.
- Wanted simple revision numbers so I could integrate that with my bug-tracker (Wastebug).
Ok, so what happened:
Took an extra backup of CVS repository, but this was never needed. cvs2svn that I used didn't seem to write anything to CVS. Yeah, that's obvious, but the last thing you'd want to lose is your repository after all.
Ok, so you guessed it, I ran cvs2svn to convert my CVS to Subversion. Actually I only converted the actively developed projects, figuring that if something went wrong, it'd be less work to redo only some of the stuff.
Next, I reran cvs2svn about dozen times, even tweaked the dumpfile it output to get the directory layout I wanted into Subversion. Sure, I could have just moved it later, but I wanted all the history to have the right path from the start. This wasn't really hard, but took a few retries anyway.
Finally got the repository up the way I wanted. Backed up the dumpfile from cvs2svn, as I figured I might do something stupid with my new repository. Not that I ever did as it seems to be pretty hard in Subversion actually.
Wanted to setup a repository browser in web. I like to be able to browse my repository with a web-browser. It's easier to find specific revisions or changes that way, and I work from several locations. Figured out that ViewCVS works with SVN, but you don't get any benefits for atomic revisions that way. Quick (actually quite extensive) search around the web indicated that the only good Subversion repository web-frontend was part of Trac, an integrated bugtrack/svnfront/wiki.
Decided that as I was going to want integration with Wastebug in the future anyway, I could do that know instead. So I wrote a small Subversion repository browser Python-CGI, which has now take about a week. The script is stabilizing (and Wastebug could use a release too) so I think I'll release it pretty soon.
Subversion bindings were a mess. I initially though I'd provide remote support, but the client bindinds are as slow as using the command line client (that means SLOW) and the RA-layer seems to be unusable from Python (some necessary bindings seem to be missing). I initially wrote agaist the client bindings, but then rewrote the whole thing with fs-bindings instead, and got a much better architecture in the script. FS bindings need a local write access to repository, but since they are the only ones you can realistically use, who cares...
I might mention this is my first Python project ever, and trying to comprehend Python, SWIG (the interface generator) and Subversion headers (and their mappings) at the same time was pretty awful at first.
Ok, so now I'm happily managing both Wastebug and this script of mine with Subversion. Even with fs-bindings the browser is a bit slow, thanks to the way Subversion works, but it's tolerable anyway.
Currently, the script works standalone being pretty good subversion web-frontend. There's also some magic that allows Wastebug to proxy requests to it and embed all of the scripts HTML output into it's own layout, so you can keep Wastebug toolbars and stuff while browsing the repostory. Wastebug also catches bug:<num> as links to bugs without support from the script, so you actually get more with the embedding
Anyway, having my own browser, I now think Subversion has everything I need. It's not really perfect (say, the command line client doesn't allow setting extra options to diff, it's always default unified output) but even then, it beats CVS anyday. Highly recommended for everyone, but expect some little quirks when you migrate from CVS. It isn't perfect, but it's definitely better than CVS anyday.
Anyway, you might want to checkout that script of mine when I release it in a few days