The Bumpy Road to Subversion

August 14th, 2005

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:

  1. Take the time to figure out what’s going wrong with CVS and address it.
  2. Grin and bear the CVS pain and manually edit a bunch of files again.
  3. 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.

4 Responses to “The Bumpy Road to Subversion”

  1. Faried Nawaz Says:

    I used subversion for several years for my personal projects (2001?-2004). Then I had a disk crash on my main dev box, and stopped doing development on my home computers for a while (I didn’t lose my repos — they were backed up to another machine periodically). I’m thinking of starting a couple of projects soon, but now I’m wondering if I should try distributed versioning tools, like darcs. For a list, see http://www.zooko.com/revision_control_quick_ref.html

    Big upside for me: no single repository. This is a major plus if I ever decide to allow others to work on my code. I don’t have to set up a repo server, give out accounts, or anything like that. As long as the people I’m working with have email + pgp or a web site, we can collaborate.

    Downsides: poor (if any) integration with emacs or xcode, fewer users, not as complete.

  2. Daniel Jalkut Says:

    Intersting page. After having such a relatively difficult time embracing what seems to be the current darling of the Open Source world, I’m having a hard time building up determination to try anything more obscure than Subversion!

    Let me know if you try Darcs and get convinced that I should unbury my head from the sand :)

  3. Nat Irons Says:

    If you think the Subversion installation process was bumpy, just wait until you’re motivated to install Trac. It’s pretty terrific once it’s up and running, but it’s the pickiest unix installation (with the most external dependencies) that I’ve dealt with in OS X.

    I can relate to the BDB failures — I was using subversion when those problems cropped up, and I lost most of two repositories before fsfs became available. I’ve been using fsfs since the 1.1 release candidates, though, and I’ve never had a reliability problem.

    Why is distributed versioning appealing? The cost of exposing a server to the internet, or creating user accounts for the typically low number of committers on even very large projects, seems negligible. My Trac/Subversion server is a blue and white G3 with a dyndns account.

  4. Faried Nawaz Says:

    The thing is, if I store my repo on a server somewhere all my commit/etc operations slow down (yes, I know svn diff is fast). I can’t use my home machine as a server because I use dialup, and I’m only online from home for a couple of hours a night, if that.

Comments are closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.