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
default?
-Karl
---------------------------------------------------------------------
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