kfogel@collab.net wrote:
>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?).
>
>
Not this time. :-) The log files grow proportionally with the amount of
change (data) and the number of BDB transactions created, and we create
those during read-only ops, too.
>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.
>
True...as far as it goes. :-)
>CVS doesn't even support such a thing.
>
Irrelevant. CVS doesn't support a lot of things we do.
>What are the circumstances where a
>regular backup schedule with 'svnadmin hotcopy' is insufficient and
>one would actually need these space-eating logs?
>
Bugs in our code that can cause logical corruption of the repository --
that is, at the schema level. If you keep all the log files, you can
roll back (or forward) to a point just before the bug manifested itself.
Otherwise your data could be totally screwed, even when nothing is wrong
with the database files themselves.
>Are such circumstances common enough
>
They're not common, in fact I don't think it's happened in a released
version yet, but "this is a version control system" and users' data are
sacred.
>to warrant turning on the space-eating by default?
>
>
Given how much emphasis we put on data safety (remember the famous
"we're in alpha, but much more stable than many 1.0's!"), I can't see a
valid reason to turn on log file removal by default. Especially as
switching it off is as simple as passing --bdb-log-autoermove to
"svnadmin create". In fact, the argument against automatic log file
removal is the same as the one against switching off fsyncs by default,
and we provide --bdb-txn-nosync for that.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
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:41:31 2003