On 29-Jun-07, at 12:26 PM, email@example.com wrote:
> Toby wrote:
>> On 29-Jun-07, at 11:35 AM, firstname.lastname@example.org wrote:
>>> check-state against the FSF database to ensure that it's in a
>>> 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
> Consider the following scenario: Let's say you're running version
> and the latest version is 1.5.3.
> 1.4.7 contains a defect which under certain circumstances can cause
> 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.
In the more likely scenario of a corruption bug in 1.4.7, if it were
serious, it would merit a 1.4.8.
> 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
> repository formats which may experience this corruption (or
> 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
> 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: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jun 29 18:59:13 2007