[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: The /. article

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-02-06 03:52:34 CET

On Tue, Feb 05, 2002 at 06:25:23PM -0800, Zack Weinberg wrote:
> On Tue, Feb 05, 2002 at 08:10:34PM -0600, Karl Fogel wrote:
> > The Berkeley atomicity helps, but it didn't give us commit atomicity
> > completely for free. We still had to do some of the same things in
> > the db that we would have had to do in the regular filesystem, to
> > achieve commit atomicity.
> >
> > I have no idea if it would have been harder or easier to do just using
> > filesystem primitives. We only had time to do it once. :-)
> Well, of course you had to do some work to implement it. I was
> primarily thinking of the work saved by being able to code to one API,
> with reliable cross-platform semantics. Also, the way to use the
> txn_* routines to implement atomic transactions is a lot more obvious
> than the way to use link(2)...

Well... we got quite a few other things from using Berkeley :-) Hot
backup and replication for starters. All kinds of existing tools that know
about BDB databases (e.g. Python or Perl bindings). A body of "community"
knowledge. etc

But I think best of all, we didn't have to write and debug the darned thing.
As a result, we haven't had one incident of data loss/corruption in the past
five months that we've been self-hosting. We haven't had to do any surgery
on the repository to extract bits that got lost. Nada.

(we have fixed some bugs in the *app* that has had some interesting
 repercussions on the data *in* the repository, but that isn't berkeley's
 fault at all; at some point, we'll probably just export/import the repo to
 clean out some of those tidbits)


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.