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?
Received on 2017-02-22 15:11:19 CET