Hi,
I must admit, the solution proposed might look a little confusing :-)
How about:
1. Install your old backup repository
2. Check out the latest revision into a new working copy folder
-> this gives you a starting point where svn won't get confused
3. Copy the files from your old working copy (*not* the .svn folders!) into
your new working copy
4. Continue working on your new working copy
Actually, the solution below does the same by applying only the differences
and not bluntly copying everything. (one small difference: the "diff"
approach won't touch unchanged files, therefore some svn commands might be
a little faster until the next check in (-> different date, same size needs
a byte wise comparison to check if the file has changed))
Best regards,
Andreas
<OttoA.External@infineon.com> wrote on 18.08.2005 09:59:08:
> Hi,
>
> 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:
>
> http://svn.haxx.se/users/archive-2005-08/0347.shtml
>
> 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
>
---------------------------------------------------------------------
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:35:15 2005