[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-06-29 17:26:47 CEST

Toby wrote:
> On 29-Jun-07, at 11:35 AM, david.x.grierson@jpmorgan.com wrote:
> > ...
> > 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.
>
> And this is why I single out "software causes", because if you KNOW
> what the common "issues" are, THEY GET FIXED, and the administrative
> remedy is to install the fix. Additionally, in the case of a known
> bug, it may be possible to characterise the damage caused, and make a
> tool (if necessary) to repair this *specific* damage.

Except that upgrading is time costly (testing, validation, arranging
downtime, etc. etc.) and so some organisations (e.g. investment banks) are
upgrade unfriendly so keeping on the latest & greatest isn't always an
option.

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.

If an organisation were to experience this corruption whilst running 1.4.7
- what should they do?

Option A) Upgrade their servers to (at least) 1.5.0 to get the defect fix
and go through all of the pain associated with the upgrade (testing of all
new features, dump/load of repositories, etc. etc.)

Option B) Have a fixer tool included in version 1.4.8 which understands
repository formats which may experience this corruption (or downloadable
as a support tool for circumstances such as these).

I'd say it's more mature for any SCM vendor (be they open-source,
commercial or otherwise) to acknowledge such an issue, release a tool
which can repair any damage which *could* occur while they work on a full
fix.

Dg.

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 Fri Jun 29 17:27:22 2007

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