That code is in the backing code for svn_ra_replay(), where it also applies to
authz, not on the client.
@Julian Foad Can we use svnsync in this scenario, or does that break in a
similar way?
Bert
Sent from Mail for Windows 10
From: Julian Foad
Sent: woensdag 22 februari 2017 15:11
To: Doug Robinson
Cc: dev
Subject: Re: Bug in "svnrdump" ?
Doug Robinson wrote:
> This has been reproduced on 1.9.5 and 1.8.16. I've attached a dump of
> the simple test case repo.
Thanks. I was hasty -- I see what's going on. This is dumping a subtree
of the repo (/B/Trunk), and r2 was not dumped because it doesn't touch
the subtree, and it fails on r3 corresponding to step 3. This feature
(dump a subtree) is not possible with 'svnadmin dump'.
So the bug is that svnrdump doesn't know how to handle a copy source
that's outside the subtree being dumped.
That's rather poor. I believe the desired behaviour would be to replace
the 'copy' with a full 'add', and I believe that behaviour is
implemented somewhere else -- is it in svndumpfilter and/or svnsync?
If you could file a bug report that would be very helpful, thanks.
- Julian
> If so then it has a reproducible bug:
> ----------------------------------------------
> 1. Add following files into an empty repo.
>
> A /A
>
> A /A/AA
>
> A /A/AA/a.txt
>
> A /A/AA/b.txt
>
> 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt
>
> A /B (from /A:1)
>
> D /B/AA/a.txt
>
> 3. Copy folder B/AA to folder B/Trunk/AA
>
> A /B/Trunk
>
> A /B/Trunk/AA (from /B/AA:2)
>
> 4. run svnrdump command to dump B/Trunk folder.
>
> # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
>
> * Dumped revision 0.
>
> * Dumped revision 1.
>
> svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
> ----------------------------------------------
>
> Is this known already? Should I file a bug?
