Re: Lack of Subversion repository recovery tools

Erik Wrote:
>On 6/29/07, david.x.grierson@jpmorgan.com <david.x.grierson@jpmorgan.com>
wrote:
>> Eventually (a week or so later) they were unable to modify the objects
>> which had become corrupted. Fortunately the SCM system had tools for
going
>> through the repository identifying the components which were corrupted
and
>> then recovering their contents appropriately.
>
>Subversion protects you of problems like these: it sends over a delta
>and the md5 of the resulting fulltext if you apply the delta to the
>base-fulltext. Any additional or replaced bytes would result in md5
>checksum errors.

This would be exactly what I would hope for.

>> If you're in a job where you're able to turn around to management and
say
>> "sorry we've lost the last week's worth of development & it'll all just
>> have to be done again because our SCM system doesn't let us fix things"
>> then you're in a position of real power.
>
>How would you want the SCM tool to address an issue like this?
>
>(I'm quite serious here: how would your SCM tool know the NUL
>characters don't belong there, more importantly, how would it know
>which characters DO belong there?)

A completely fair point and one I agree completely with.

My point, however, was that *if* SVN wasn't quite so resilient to perform
the MD5 (which it is so it's not really a valid point but I'll plough on
regardless :-), and just accepted the NULLs then having to go to
management to tell them to restore an old backup because there were no
back-end manipulation tools is not a situation I'd like to be in.

> I do sympathise with the problems raised, but I'm not understanding
> what it is that you're asking for: Subversion WILL let you fix it as
> long as you know which characters should be there, you can always
> check out the wrong data and commit the correct data (which comes as
> close to 'repairing' the data as I can imagine...)

I guess the thing is that by performing the MD5 and transmitting that as
well you've avoided a situation where the client can unexpectedly corrupt
the data.

With other SCM solutions there are ways in which the data can be repaired
- for example manually editing the repository and then running some kind
of forced checksum update tool. This way any internal table of checksums
within the repository would accept that the forced modification was
correct and would then allow the repository to be marked "clean".

There could however be some kind of mechanism for even just performing a
check-state against the FSF database to ensure that it's in a consistent
state - and knew what kind of common issues might exist and what the
regular fixes for those might be.

Kind of like the way on HP-UX you had an inode editor with which you could
perform the lowest level manipulations of the filesystem to correct it -
or you could use fsck to have them automated *where possible* for you.

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