Hi Brane,
Thanks for the reply. Interestingly Daniel's reply had given me the idea to
try pretty much what you suggested and I gave it a go this morning and it
seems to be working.
Stopping svnsync in the right place wasn't hard as i dies as soon as it
tried to get the binary diff but before it's made any changes.
The one bit I didn't do was update the svnsync metadata. When I resumed the
sync it just automatically carried on with the revision after the one I had
just committed. Hopefully that won't cause any problems, it seems to be
working ok as I'm a lot further syncing than I've ever managed before
(crazy how many times we've had svndiff errors, luckily fsfsverify has
fixed all of the others so far).
Thanks for everyone's help!
Mike
On Fri, 30 Aug 2019 at 12:12, Branko Čibej <brane_at_apache.org> wrote:
> On 29.08.2019 20:49, Michael Ditum wrote:
> > Apart from using fsfsverify I also tried recreating the diff by
> > creating a Fedora 7 VM, running svnsync on it to copy the repo up to
> > that point and then manually committing the file and copying the
> > revision over to the copy of my original repo.
>
> Yikes. No, that definitely won't work.
>
> > Whilst this allows svnsync to get past that revision I then started
> > having lots of problems with incorrect byte offsets in later revisions
> > and once I (think I correctly) fixed started getting checksum errors.
>
> And that's why ... binary deltas rely on previously stored data, but
> unlike a text diff they have no context. You changed the source of the
> delta and that corrupted everything that depends on it in later revisions.
>
>
> > Does anyone have any ideas on how I can fix this revision? As I
> > mentioned before, the file gets deleted a couple of revisions later so
> > I don't really care about the contents of the revision but I'm
> > currently stuck and can't get any further in my svnsync.
>
> Daniel made the best suggestion, it would work like this:
>
> * create a new repository
> * svnsync up to the revision just before the broken one (stopping
> svnsync is the tricky part here)
> * commit that one file to the _synced_ repository, and update
> svnsync's metadata (in revision properties on r0) to skip the
> offending revision on the next run
> * svnsync to the end.
>
> You can do a similar trick with svnadmin dump and (incremental) load;
> the benefit of this is that there is no "stopping problem," but it will
> be much, much slower than svnsync. You _could_ combine both methods,
> i.e., initialize your target repo with a partial dump of the source up
> to your offending rX, then commit rX to the target repo, then svnsync
> from there.
>
> -- Brane
>
>
Received on 2019-08-30 15:14:27 CEST