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

To remove or not to remove logfiles? (issue #1615)

From: <kfogel_at_collab.net>
Date: 2003-11-26 18:38:53 CET

Berkeley DB 4.2 supports automatic logfile removal. In issue #1615,
you can read all about how to make it happen. This is technically
easy, a small matter of programming.

The question is, which way should be the default -- keep the logfiles,
or throw them out? (It will be configurable, of course; this is only
about choosing a default.)

The argument for throwing them out by default:

   * The repository grows more quickly with the logfiles, and worse,
     the growth is proportional both to the amount of data *and* the
     number of operations done in the repository (including read
     operations, unless I'm totally crazy?).

The argument for keeping them by default:

   * Brane should make this argument. In the issue, he says: "I also
     suggest against making automatic log file removal the default. We
     should aim for data integrity and recoverability by default. If
     people want to potentially shoot themselves in the foot, we
     should offer the means, but not do it for them."

Since discussion threads are more productive when not started from a
position of neutrality :-), I'll add:

I don't really buy the argument for keeping the logs. Just because
Berkeley DB happens to offer this incredibly detailed audit and
recovery trail, doesn't mean we have to take advantage of it. CVS
doesn't even support such a thing. What are the circumstances where a
regular backup schedule with 'svnadmin hotcopy' is insufficient and
one would actually need these space-eating logs? Are such
circumstances common enough to warrant turning on the space-eating by


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 26 19:24:10 2003

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.