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:
- Xcode expects the Subversion utilities in yet another location,
/usr/local/subversion/bin/. So I made that work.
- 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.
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.