Not too long ago I was convinced to switch to Subversion for one of my most active projects. Unlike some folks, I didn’t run to Subversion with CVS blood on my fingers, but it was nonetheless a CVS nuisance that finally pushed me over the edge.
I don’t know what happened to CVS in Tiger, but on my machine it started causing the Repository files that CVS keeps in its maintenance folder to be ill-formatted. Every time I added a new directory to my project, I had to go in and manually edit the “Repository” file so it actually pointed at my local repository directory. Big pain in the butt! Finally, when I was poised to add a bunch of directories to my project, I realized I could either:
- Take the time to figure out what’s going wrong with CVS and address it.
- Grin and bear the CVS pain and manually edit a bunch of files again.
- Take the opportunity to figure out what’s so great about Subversion.
I decided to be heroic and take option three. Needless to say, the road was not bump-free. I was reasonably happy with subversion’s documentation and install process, but lots of things that “just work” with CVS seemed not to be with subversion. Xcode integration seemed flakier. I had to succumb to the learning curve of Subversion’s “simpler but nonetheless different” way of handling branches and tags. Finally, I lost my Subversion repository to a “corrupt database.” Grr! This never happened with CVS! Subversion fans like to say that it happened all the time with CVS but it just wasn’t smart enough to tell me. Well, my in-tact repositories thank CVS’ foolish ignorance!
I complained about this database corruption on the Xcode mailing list, which was met with a number of very helpful responses which essentially boil down to “Duh! You’re not supposed to use the Berkeley DB backend in Subversion!” Oh, silly me. I just installed it and used the default. The thing even insisted on me installing a compatible version of Berkeley DB. The bottom line is “Always use the fsfs backend.” This is apparently the default in more modern releases, but I wasn’t so lucky. I now have a fresh Subversion repository that picks up about 2 months after my CVS repository leaves off. Fortunately, it was a fairly lazy 2 months on the project.
I’m now “back on track” with Subversion and am now willing to give a tentative thumbs-up. It does make many things feel “warm and fuzzy.” With the fsfs backend to the repository, I feel confident that my repository won’t be corrupted, and if it is, I can still get my data out. On the Xcode front, something has happened to make Xcode more happy with my Subversion repository. Maybe there was a yucky residual file in my old repository, maybe it didn’t like the output from the version I was using. Who knows. It is not perfect, but it is much better.
If you haven’t switched to Subversion yet, and would like an easy path to installing it, I recommend the pre-built binaries from Matthew E. Porter. The binaries are recent and default to fsfs for the backend. And you should always use the fsfs backend.