Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.8.16, 1.9.5
-
None
-
None
-
None
Description
Reproduction:
Create a repository with this history:
<<< Started new transaction, based on original revision 1
* adding path : A ... done.
* adding path : A/AA ... done.
* adding path : A/AA/a.txt ... done.
* adding path : A/AA/b.txt ... done.
------- Committed revision 1 >>>
<<< Started new transaction, based on original revision 2
* adding path : B ...COPIED... done.
* deleting path : B/AA/a.txt ... done.
------- Committed revision 2 >>>
<<< Started new transaction, based on original revision 3
* adding path : B/Trunk ... done.
* adding path : B/Trunk/AA ...COPIED... done.
------- Committed revision 3 >>>
Descriptively:
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)
Attempt to: "svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
It fails with: "svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'"
Per Julian Foad:
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?