In the test repository used in log_tests.py the path "A/D/G/rho" is:
- created in revision 1
- deleted in revision 5
- recreated in revision 8
The following commands result in the expected error "Unable to find
repository location for":
svn log -r 2:9 path-to-wc/A/D/G/rho@2
svn log -r 9:2 path-to-wc/A/D/G/rho@2
On the server side, these are exactly the same request with one having a
"reverse" flag set. Because Subversion can only crawl history in reverse,
the server-side request will look like:
svn log -r9:2 path-to-wc/A/D/G/rho@2
But also because Subversion can only crawl history in reverse, having a peg
revision of 2 ("@2") and an operative revision of 9 ("-r9") is a problem
here. Subversion can't crawl forward in time from PATH@2 to see where PATH
lived in r9. The best it can do is ask "Does the history of the thing at
PATH@9 pass thru PATH@2?" In this case, it does not. The item was
recreated in r8, so it has no history prior to that.
The response you see from Subversion is exactly what is expected today in
this situation.
i disagree, this is not expected.
When selecting an item with path@PEG SVN should not return information about a
totally unrelated item.
See paragraph "The Peg Revision Algorithm" at
http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html
SVN might not be able to trace the history of items forward.
In a perfect world it would look where item path@2 is actually in revision 9.
But since this is not (yet) support it must check if the item at path@2 is
related to path@9.
If this is not the case - it must output an error.
Dirk
