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

ALARM !!! recover from database crash

From: <OttoA.External_at_infineon.com>
Date: 2005-08-18 09:59:08 CEST


  I don't understand the answer.
  From my point of view it is a normal behavior for a SW to recover from
  an old backup release.
  if I read this email I get the conclusion that it is not possible !!!

  I thing it is a business-critical design-error of subversion

  what I want:

  1. install an old backup
  2. perhaps run a svnadmin ??? command to clean up
  3. continue to work

  for me everything is perfect because I have a working old release
  including the history the old HEAD in the .svn directory of
  a checkout and the current changes in the working directory

  and subversion say I'm not able to recover !!!!!!!

  I'm not able to recover with the information below !!!!

Mit freundlichen Grüßen

   Andreas Otto

-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2005@ryandesign.com]
Sent: Tuesday, August 16, 2005 7:16 PM
To: Otto Andreas (IT OS PA external)
Cc: users@subversion.tigris.org
Subject: Re: recover from database crash

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 Thu Aug 18 10:01:43 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.