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

Re: Decompression of svndiff data failed

From: Branko ─îibej <brane_at_apache.org>
Date: Fri, 30 Aug 2019 13:12:40 +0200

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 13:12:45 CEST

This is an archived mail posted to the Subversion Users mailing list.