Douglas Robinson created SVN-4672:
-------------------------------------
Summary: Fix svnrdump to handle subtree references
Key: SVN-4672
URL: https://issues.apache.org/jira/browse/SVN-4672
Project: Subversion
Issue Type: Bug
Affects Versions: 1.9.5, 1.8.16
Reporter: Douglas Robinson
+Reproduction+:
Create a repository with this history:
{noformat}
<<< 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 >>>
{noformat}
+Descriptively+:
{noformat}
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)
{noformat}
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 [~julianfoad]+:
{quote}
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?
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
