Subversion Perversion: Switching from Berkeley DB to FSFS

Warning! Warning!

I’ve spoken to two developers I know about my Subversion repository, and the reaction from both of them was:

You’re using the filesystem version, not the Berkeley DB version, right?

But while the first developer (hi, Wolf!) couldn’t give me a good reason not to use the default Berkeley DB version, which per the manual is better tested, the second developer (hi, Uli!) could.

On Mac OS X 10.3 Panther, Berkeley DB has a known corruption bug.

Good enough for me.

The manual actually does a really good job of explaining the steps needed to export your repository and then import it again in another format. Here are the steps I used:

svnadmin dump /My/Repository/ > dumpfile
// Move old repository somewhere else
svnadmin create --fs-type fsfs /My/Repository/
svnadmin load /My/Repository/ < dumpfile

I just rebuilt my entire project and ran it, and it looks great.

At least one of my commenters has mentioned various Subversion GUI-based clients. For now, I’m just using Xcode 1.5’s Subversion plugin. For the most part I like it, but there are two issues:

  1. Xcode expects the Subversion utilities in yet another location, /usr/local/subversion/bin/. So I made that work.
  2. Xcode’s Subversion plugin doesn’t handle bundles like nib files correctly. Known problem. So I have to check in nib files from the command line.

Another commenter asks, why Subversion?

I’ve heard both good and bad things about Subversion. The good: it discards a lot of the cruft of CVS, and it has some new features, esp. atomic multiple commits. The bad: I vaguely remember reading someone’s opinion that as far as going in a new direction, Subversion gets it all wrong. Was that in a weblog somewhere?

I guess my main reason for trying it was that it looked like it would be easier than CVS.

That’s it.

Oh, and if I did run into problems, the Subversion partisans I know might be more enthusiast about helping me because it promotes a product they like.

Nobody likes CVS.

6 thoughts on “Subversion Perversion: Switching from Berkeley DB to FSFS”

  1. If only I had been able to read this post a few months back when I setup subversion on my machine 🙂 I ran into the DB corruption a while back, so I switched over to the FSFS format; and I’ve wondered if I set something up wrong since I was seeing issue #2 that you mentioned as well (nibs don’t show changes in xcode). Thanks for the info!

  3. I always assume that a db file could get corrupted, even if there are no known corruption bugs. (What about disk failure? Cosmic rays?) It bit me at my last job once or twice. If a db file gets corrupted, chances are the whole thing is dead, unless you know enough about the file structure to do forensics. If you’re using the filesystem, CVS style, any corruption that happens is going to be less serious.

  4. “The bad: I vaguely remember reading someone’s opinion that as far as going in a new direction, Subversion gets it all wrong.”

    That would be Tom Lord, creator of tla:
    http://web.mit.edu/ghudson/thoughts/diagnosing

    Rebuttal:
    http://web.mit.edu/ghudson/thoughts/undiagnosing

    I read “Diagnosing svn” before trying svn, and first attempted to use tla. The main reasons I didn’t go with tla can be found in the tutorial of that time, which I see has since been rewritten.

    Briefly, if you followed the tutorial front-to-back, in order, it appeared you lost some files in your source. It turned out that the next page in the tutorial enlightened what was happening, but it freaked me out.

    In addition, the version of the tutorial I used advocated putting inventory IDs into source files. This is against my SCM philosophy in general and breaks binary files specifically. I see that too is no longer advocated — they now use .arch-ids directories.

    Basically, the bad tla tutorial shunted me to svn, which is good enough (with fsfs) that I haven’t cared to look back.

  5. > Xcode expects the Subversion utilities in yet another location,
    > /usr/local/subversion/bin/. So I made that work.

    Actually, if you look at your project info in XCode, where you activate SCM for it and select the kind of source-control you want to use, there’s an “Edit…” button right next to the popup list that will let you change the path to the subversion binary. No need to use sym links or whatever, just point XCode to your where your svn binaries are.

  6. Having used subversion, cvs, and tla, I would say that barring berkelydb bugs on the mac (great tip), aside, svn is the most user-friendly.

    My only (other) complaint with svn is that it doesn’t retain branching history in a sane manner. Every version is a checkin, and only some versions apply to some branches (typically). tla, however, would be awesome if it wasn’t both slow and cumbersome. The fact that branching in tla is such a time-consuming nightmare may explain why subversion chose the route they did. All said, I don’t think cvs is that bad.

Comments are closed.

%d bloggers like this: