[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 30 Aug 2019 04:09:42 +0000

Michael Ditum wrote on Thu, 29 Aug 2019 18:49 +00:00:
> 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.

Use authz on the source repository to hide that file from the user
svnsync authenticates as.

If you re-committed that file a few revisions later and want to preserve
_that_ copy, then stop svnsync before the revision that re-creates the
file. The easiest way to do this is to ^C svnsync, but you can also
install a start-commit hook on the destination repository that aborts if
HEAD is r1233, where the file was re-committed in r1234.

However, there's a catch. If you re-committed the file by doing 'svn
rm' and 'svn add' as two separate commits, or under different names,
this approach would work; but if you did the 'rm' and 'add' as a
_single_ commit, under the same name, authz alone won't help. If
that's the case, let us know.

Cheers,

Daniel

P.S. A word of warning: the trick of using start-commit to prevent r1234
from being committed only relies on a non-obvious property of
svnsync mirrors: they never have two in-flight commit attempts
simultaneously. The trick won't work on repositories whose use pattern
doesn't have this property.
Received on 2019-08-30 06:11:00 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.