Branko Čibej <brane@xbc.nu> writes:
> 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.
Hrm, okay, you convinced me. I'll code it with 'keep' as the default.
But will add to the FAQ item about repository growth, and to the Book,
so people can easily find out how to turn this off.
(Got some internal stuff to take care of first, before I start on this
& the auto-deltification work, so the commits may be delayed.)
-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:48:58 2003