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
From: Ryan Schmidt [mailto:firstname.lastname@example.org]
Sent: Tuesday, August 16, 2005 7:16 PM
To: Otto Andreas (IT OS PA external)
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
> some examples:
> host:>svn update
> svn: Reference to non-existent revision '2544' in filesystem
> 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/
> 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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Aug 18 10:01:43 2005