Thanks Erik. My point is that as my repository is corrupted I cannot use
svndumpfilter to shrink my repository. In fact I will have a nightmare
task if my only option is to
1 Use svnadmin dump to dump the repository up to the point before the
first broken revision
2 I don't know if there are more errors at higher revision levels as
svnadmin verify stops after the first error it finds
3 So, I have to repeat "svnadmin dump --incremental -r LOW:HIGH"
commands hoping that there are no errors within the LOW/HIGH revision
numbers.
4 Skip revisions which are broken
5 Repeat from 3 until all the revisions are dumped
Then after that I have to "svnadmin --force-uuid load" the revisions
using dumpfilter into a new repository. I have to do a "dummy" commit
for each of the revisions which are broken so that I keep the repository
revision numbers the same. Then hopefully, &deity; willing, I can get my
users to access the repository without noticing a difference.
Is the above my only hope with FSFS?
Cheers,
Chris Melikian
Important: Fidelity Investments International (Reg. No.1448245),
Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity
Pensions Management (Reg. No. 2015142) and Financial Administration
Services Limited (Reg. No. 1629709, a Fidelity Group company) are all
registered in England and Wales, are authorised and regulated in the UK
by the Financial Services Authority and have their registered offices at
Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11
9DZ. Tel 01732 361144. Fidelity only gives information on products and
does not give investment advice to private clients based on individual
circumstances. Any comments or statements made are not necessarily those
of Fidelity. The information transmitted is intended only for the person
or entity to which it is addressed and may contain confidential and/or
privileged material. If you received this in error, please contact the
sender and delete the material from any computer. All e-mails sent from
or to Fidelity may be subject to our monitoring procedures. Direct link
to Fidelity's website -
http://www.fidelity-international.com/world/index.html
-----Original Message-----
From: Erik Huelsmann [mailto:ehuels@gmail.com]
Sent: 30 June 2007 20:25
To: Melikian, Chris
Cc: users@subversion.tigris.org
Subject: Re: Re: Lack of Subversion repository recovery tools
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 Mon Jul 2 11:44:13 2007