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

Re: Lack of Subversion repository recovery tools

From: <david.x.grierson_at_jpmorgan.com>
Date: 2007-07-04 11:17:53 CEST

Toby wrote:
>> On 29-Jun-07, at 12:26 PM, david.x.grierson@jpmorgan.com wrote:
>> Consider the following scenario: Let's say you're running version
>> 1.4.7
>> and the latest version is 1.5.3.
>>
>> 1.4.7 contains a defect which under certain circumstances can cause
>> the
>> repository to become corrupted.
>>
>> This defect was identified in version 1.4.8 but wasn't actually fixed
>> until version 1.5.0 because it required a re-design of aspects of the
>> repository format which wouldn't have been appropriate to issue in
>> a point
>> release of the product.
>
>Very unlikely.
>
>In the more likely scenario of a corruption bug in 1.4.7, if it were
>serious, it would merit a 1.4.8.

Okay - just ran into the "read length line" error for the first time
today.

A developer in one of the teams that use our SubVersion repositories
couldn't checkout a directory which appeared to have become corrupted over
30 revisions before the HEAD.

I had to dig around for 1) information on this corruption 2) whether any
tools for correcting the corruption existed or would I have to start
hacking around with the revision file and a copy of the revision format
description trying to figure out what was up?

There appears to have been enough of a need for a fixer tool that John
Szakmeister has developed a tool for fixing the corruption:
http://www.szakmeister.net/blog/?page_id=16

This appears to be a perfect example of this kind of situation:

*) The developers are not 100% sure as to what is causing the corruption
because they don't have a mechanism for reproducing it - consequently they
are unable to say whether it's actually fixed yet AFAIK.
*) The corruption is serious enough that the revision in question (and any
dependent revisions) are broken until the corruption is fixed.

All that's required is a "this is a known issue - here's a
path/URL/description" to be spat out by a "svnadmin verify" command and
take the fsfsverify tool John's written into the distribution while they
look for a fix. This would allow them to state that there is a supported
workaround while they are looking for the full resolution to the issue.

This would have certainly made my life easier and slighly less scarey
today.

John - if you're still reading this forum - thanks so much for fsfsverify
it's saved my day!

Dg.

--
David Grierson
JPMorgan - IB Architecture - Source Code Management Consultant
GDP 228-5574 / DDI +44 141 228 5574 / Email david.x.grierson@jpmorgan.com
Sentinel House 2nd floor, 103 Waterloo Street, Glasgow G2 7BW
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal entities.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 4 11:38:29 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.