On 06/17/2011 08:23 AM, Dirk Thomas wrote: > While working on issue 3830 i noticed the following behavior of svn log. > > 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.
> But when using HEAD instead of revision 9 (which should be the same) the
> commands:
> svn log -r 2:HEAD path-to-wc/A/D/G/rho@2
> svn log -r HEAD:2 path-to-wc/A/D/G/rho@2
> actually show the log of the wrong resource - namely A/D/G/rho@8.
>
> This looks like bug to me.
Hrm. Yep, that definitely looks weird. I'd love to know what's happening
differently here in this case.
--
C. Michael Pilato <cmpil...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
