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
