RE: Trying to restore a corrupted repo

[snip]
> First step is to *write lock* the old repository, to avoid
> accumulating history on broken history.

Absolutely - and make sure the lock stays locked forever more.

> You will be *breaking history* due to the corrupted repo. You
> should ideally create a new repo to do the repairs in,
> explain the situation,and tell your user community to set
> aside their working copies and make clean checkouts when
> you're done. The old repo should be locked, and the new repo
> should have a new name to avoid any confusion.

What I've done in the past is to:
a) Write-lock the old repository;
b) Create and populate a new repository by whatever means are required;
c) Ensure nobody is trying to access either repository for the next few steps (pause Apache, or whatever);
d) Re-name the OLD repository to reflect its broken/BDB/whatever status;
e) Rename the NEW repository to the old name; and, finally:
f) Re-enable access to the repositories.

I even created a batch file to do this when we upgraded SVN recently and could no longer access the BDB repositories.

> This is one of the difficulties with the absolute central
> repository approach of Subversion and its spiritual ancestor,
> CVS. If anything happens to the central repository, you have
> to re-establish the effectively server/client relationship
> correctly or be at risk of corrupting your history, *again*.

This is why your servers should have an effective backup and restoration system. Ours uses a SAN with off-site backup. Then, if we catch the corruption early enough we've only lost a day's history.

> It can happen with more distributed systems as well, it's
> just more likely when one particular repository is considered
> canonical in your particular workflow. If the history is
> replaced or corrupted behind your back, you can be in real trouble.

I think this is true of any single-site storage system - electronic or otherwise. If there's a single point of failure, and you rely on the information/items, there's potential for (business) disaster.

Regards,

Geoff

-- 
Apologies for the auto-generated legal boilerplate added by our IT department:
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files.