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

Re: recover from database crash

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-08-16 19:15:45 CEST

On 16.08.2005, at 16:23, Andreas Otto wrote:

> after a crash of our raid5 array I recover the svn database from an
> old backup.
> the problem is that the old state was !not! the state of the last
> check-in:
> some examples:
> host:>svn update
> svn: Reference to non-existent revision '2544' in filesystem
> '/path/to/svn/repositories/db'
> host:>svn commit -m new
> Sending MqSeries.config
> Sending WebMethods.config
> Transmitting file data ..svn: Commit failed (details follow):
> svn: Base checksum mismatch on '/applications/OpMenu/
> WebMethods.config':
> expected: e83613d37b51b9a182dace8b33bb860b
> actual: 8bc484dc39ad9face27831e60e60a6a1
> I'm not interested to get the !latest! level working ...
> I'm just fine to get anything working
> (e.g. start to check-in the current level to the HEAD release ,
> even if
> the HEAD release is old)

An answer I gave someone else recently will probably help you:


On 8 Aug 2005, at 05:55, Ryan Schmidt wrote:

> 1) Create an export of your "old" working copy (which has all the
> data in it that you want).
> 2) Create a new working copy from the repository.
> 3) Create an export of your "new" working copy (which is missing
> the newest revisions).
> 4) Create a diff (not an svn diff; just a normal diff) between the
> "new" export and the "old" export. (I suggest diffing exports,
> because if you diff working copies, you'll diff the .svn
> directories too which you need to avoid.)
> 5) Apply this diff to the "new" working copy.
> 6) Commit.
> 7) Throw away the exports and the "old" working copy.

If there are any other people who have working copies of the old lost
repository, these must be discarded as well (assuming they have no
changes that need to be committed), because they refer to a different
incarnation of the repository than you have now. You could
potentially avoid confusion by making your recovered repository
available at a different URL than the old failed one, to prevent
anyone from using the new repository as if it were the old one.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 16 19:17:56 2005

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.