Hi Chris,
> No of course things happen which we have no control over. That's part of
> the fun/headache of IT right? ;-)
Yes :-)
> What I am saying I that I am surprised there are no tools available to
> be able to recover a repository into a usable state. A simple(no such
> thing I know) tool is all that is needed to be able to mark a revision
> as bad and let and svnadmin dump/verify and the other tools work as they
> should.
>
> Do you think this is unreasonable?
Absolutely not! It's a very reasonable request! The only thing is that
this is the default in-production behaviour already: if a damaged
revision is not required to construct a later revision, it's simply
skipped and no damage will be detected.
With FSFS all changes in one revision are stored in one 'revision'
file. With skip-deltas [1] the chances become bigger that a large
number of those revision files have to be consulted, both on larger
trees (because there are more elements which have dependencies on
earlier revisions) and on larger numbers of commits (because chances
increase that different files in the same checkout will have been
modified in different revisions).
This makes FSFS more sensitive to broken revision files than the BDB
backend, which stores all file changes in one big database. If part of
that database gets damaged, you may only notice when you're checking
out the damaged file(s), but *only* when the revision you're checking
out actually depends on the damaged revisions.
So, we actually already try our hardest - even in production - to give
you all the output we can give you. With skip-deltas it's almost
impossible to actually mark a given revision as 'bad' and just proceed
with what we do have.
I hope that clarifies things a bit. The above is also an answer to the
'--try-harder' proposal earlier in the thread: we already do.
bye,
Erik.
[1] http://svn.collab.net/repos/svn/trunk/notes/skip-deltas
PS: Possibly, you can't help it, but could you please post without the
extremely long disclaimer? It has no legal value, especially on an
open and archived mailing list like this.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jun 30 21:25:10 2007