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

Re: the dangers of DB_LOG_AUTOREMOVE

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-07-15 01:07:35 CEST

On Wed, 2004-07-14 at 16:37, Ben Collins-Sussman wrote:
> I wonder if you're right, here, Eric. Sorry, didn't mean to ignore your
> older comments. The reason we decided to activate LOG_AUTOREMOVE by
> default was because we were getting endless complaints about the
> repository "getting too large" by people who had no idea how to clean
> them out. Correctly dminning a BDB repository is a real barrier to
> entry for so many newbies.

People participating in this thread should be sure to review
http://www.contactor.se/~dast/svn/archive-2003-11/1478.shtml where we
initially decided to turn on this flag by default. Pretty much all the
same arguments were made back then.

I have two remarks to make:

  * In theory, removing unused logfiles should not be compromising
db_recover's ability to work. Perhaps "catastrophic" recovery wants to
make use of old logfiles, but really, it's BDB's job to be able to work
robustly while using space proportional to the current data set, not
proportional to the full history of DB operations.

  * Our reputation for preservation of data is not really going to be
affected by whether we keep logfiles. Either BDB doesn't crap out, and
we are seen as doing a good job, or it does crap out, and we are seen as
doing a bad job even if there's some magic arcane formula you could use
to fix up your data.

A lot of people seem to be happy with Subversion, leading me to believe
that for the most part, BDB doesn't crap out much in the absence of
permissions problems. But of course, ~every time it does, we find out
about it, so we may get the perspective that it craps out a lot.

In the long run, I think the answer is to make FSFS the default in 1.2
if it seems to work well, and to kill the BDB back end in 2.0 if we've
managed to write an SQL back end by that time.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 15 01:07:54 2004

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.