Thanks Paul — I was hoping there would be some other faster option but
(sigh!) I guess in my case (3) is probably the best option.
There may be another issue though — the rev# 0 properties on the restored
backup would still indicate that last merged version as being 84333 [ even
if I dumped and restored up to 84332 ]. Does this have to be fixed manually
too?
murli
On 2/22/08 9:40 AM, "Paul Koning" <Paul_Koning_at_Dell.com> wrote:
>>>>>> >>>>> "Murli" == Murli Varadachari <mvaradachari_at_facebook.com> writes:
>
> Murli> I am doing a backup of my production svn repository using
> Murli> svnsync ‹ somehow last night a new version got committed to
> Murli> the backup repository directly. AT this point all synsync
> Murli> operations fail.
>
> Murli> Here is the error message
>
> Murli> [root_at_svn001.sf2p ~]# svnsync synchronize --username root
> Murli> --password root svn://xxxx.foo.com/svnroot svnsync:
> Murli> Destination HEAD (84333) is not the last merged revision
> Murli> (84332); have you committed to the destination without using
> Murli> svnsync?
>
> Murli> Is there a quick way to fix this.
>
> I'm not sure about "quick"...
>
> Some possible approaches:
>
> 1. Rename the destination repository, create a new one, re-sync from
> scratch.
>
> 2. Restore from a backup of the destination directory, one that
> doesn't include the bad rev, and re-sync to that.
>
> 3. Use svndump to dump up to but not including the bad rev, svnload
> that into a new repository, that's your "repaired" repository.
>
> paul
>
>
>
>
Received on 2008-02-22 19:00:35 CET