Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Wednesday, March 08, 2006

Subversion: ouch!

So, all of a sudden, I'm having massive problems with my Subversion server. Basically, nothing works. I can't seem to check new files in (it appears to crash svnserve, resulting in broken pipe exceptions) and I also see problems checking files out.

I'm in the middle of a full backup of my laptop (before my big trip to Boston and then Tucson). I think, after that, I'll dump out my repository, and rebuild it as a file system (not Berkeley DB) version. I've heard people claim that SVN in server mode doesn't work well with Berkeley DB, but I had thought that was only when you have multiple users pounding on it.

This is frustrating, and bad timing. I'm concerned that I'll have data, or at least revisions, in SVN I can't access. We'll see. It's always something.

Anyway, this is why I haven't had a chance to update the code for the NFJS project to include the latest code and presentations. I can't get things into SVN so that I can properly build and deploy.

Update: It's possible that I have a bad sector on my hard drive (Acronis has found an unreadable sector ... it's impossible to say if this bad sector has anything to do with my Subversion repository). Either way, reading (if possible) the repository to a dump format, and building a new file-system repository, should be a reasonable approach.

8 comments:

Jamie O-H said...

Definitely use FSFS, Howard. It's really easy to dump the repo and then recreate it as FSFS and import the dump.

Anonymous said...

A couple of comments:
* FSFS "feels" faster than FSBDB (at least imvho)
* if you're running *nix be very careful about filesystem permissions - it's easy to hose an SVN repository by having different users try to access it directly (via the file:// protocol)

Anonymous said...

A couple of comments:
* FSFS "feels" faster than FSBDB (at least imvho)
* if you're running *nix be very careful about filesystem permissions - it's easy to hose an SVN repository by having different users try to access it directly (via the file:// protocol)

Anonymous said...

FSFS is a must. Our BDB repositories had been crashing almost every week under high load. With FSFS we haven't had a single crash.

Ben said...

I agree - definitely go with something like FSFS rather than Berkeley DB. We started out with a BDB backend and svnserve, but ran into problems that sound like what you have described. It was fairly simple to convert though with the instructions in the FAQ. We've not had any problems since.

Anonymous said...

Some people like to use SVK as frontend to svn.
http://online.effbot.org/2005_11_01_archive.htm#20051108
http://svk.elixus.org/

Anonymous said...

Some people like to use SVK as frontend to svn.

http://online.effbot.org/2005_11_01_archive.htm#20051108
http://svk.elixus.org/

Richard said...

Since BDB keeps a journal, you could have it rebuild the database (possibly after running chkdsk and having it mark out the bad sector.)

Once you have a working BDB, switching over to FSFS is a very good idea. I've been using FSFS repositories for something over a year and they work wonderfully. Checkouts are a shade slower than using BDB, but everything else is faster.

(Caveat: My svn servers are on BSD and Linux. Using FSFS hammers the filesystem pretty hard. I'm assuming you have NTFS as your file system, which should handle this fine.)