Sleepycat and CollabNet Open Source Collaboration

Posted Feb 8, 2006 6:42 UTC (Wed) by Dom2 (guest, #458) [Link]

To be honest, I'd still choose the FSFS over the DB4 backend. The main advantage is that because
it's bundled with subversion, something else upgrading your DB4 libraries won't suddenly stop your
version control system from working. Unfortunately, this did happen to me. I switched to FSFS
when subversion 1.1 came out and I haven't looked back...

But I still love subversion. :-)

-Dom

Posted Feb 9, 2006 5:08 UTC (Thu) by Peter (guest, #1127) [Link]

Yeah, I can only think it means "automatic" in the sense of "whenever anything goes wrong, the system administrator will automatically go through a full recovery process

While I appreciate the cynicism, they really do mean automatically. This code was tested by doing normal subversion stuff but also having a thread running whose only purpose was to start a transaction then get kill -9'd. Once per second, or was it 10 times per second? Anyway, the ability for an application to avoid wedging the DB even when dying unexpectedly is new to DB 4.4, so your previous experiences aren't completely valid.

The annoying part of this announcement is that we are in the process of switching from CVS to SVN. I'll have to find out what this means w.r.t. the impact on reliability.

DB isn't the default backend. Most people recommend the FSFS backend instead, which is why it's the default. It's a little slower for some operations, and creates a huge directory (one file per revision, just like arch, so if you have 25000 revisions you get a dir with 25000 files, which doesn't perform well with certain filesystems), but it has the very nice property of not changing your old data - think of it as an append-only system. And it works over NFS, not that we'd necessarily recommend it.