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?
