[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Lack of Subversion repository recovery tools

From: Melikian, Chris <Chris.Melikian_at_uk.fid-intl.com>
Date: 2007-06-28 17:55:20 CEST

Now I really like Subversion. Been using it for 2 years as a user and
administrator and we've had a lot of success in implementing svn as the
version control system of choice for our continuous integration
environments against other more heavyweight tools such as ClearCase etc.
It's fast, lightweight, easy to get going etc

On the other hand, I've become very disillusioned with the lack of
documentation and tools on how to recover from corrupted revisions. The
problem we have is that we are trying to an "svnadmin dump" of our
repository in order to shrink it with svndumpfilter and we are getting

"Error: Invalid diff stream: insn 1245 cannot be decoded"

errors. We are using svn 1.3.2 on Solaris with FSFS as the back end and
svnserve as our repository access front end.

There are many, many emails listing the above error and very few
suggestions on how to solve this. There seems to be no way with the
supplied tools to correct this error. Fair enough if the revision is
corrupted but we cannot even mark the revision as bad or delete it and
so the repository stays in a corrupted state. The only tool we've found
is from the extremely helpful John Szakmeister with his fsfsverify.py
script but it hasn't solved our problem.

The other option is to perform incremental dumps in blocks skipping the
corrupted revisions. ie

svnadmin dump -r 1:4745 myrepo > dump_1_4745.txt <----- skip 4746,
the broken rev
svnadmin dump -r 4747:10000 --incremental myrepo > dump_4747_10000.txt
svnadmin dump -r 10001:20000 --incremental myrepo > dump_10000_20000.txt
svnadmin dump -r 20001:30000 --incremental myrepo > dump_10000_20000.txt

The problem with the above is that svnadmin verify will only tell us the
first revision which is broken and then stops. So we don't know if there
is a broken revision after 4746 using the example above. Plus, if we
want to keep integrity of revisions, we'd have to put dummy commits into
the new repository where the broken revisions were. Not nice.

I think Subversion is an excellent tool but more time needs to be spent
on the administration tools to underpin the repository and make it rock
solid before new functionality is introduced.

If the answer is to submit a problem report, then I'm perfectly willing
to do so.

By the way, if anyone does know how to fix the above then please let me
know. We've been spending a long time on this.

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 -
Received on Thu Jun 28 17:55:43 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.