Please see S. Ramaswamy's post and patch here:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=101980
He's fixing issue #2287, by making 'svn log' able to take peg
revisions, e.g.:
$ svn log -rN url_that_does_not_exist_in_head@X
Here's how that should work: Subversion would first go to rX, find the
relevant path as determined from the URL, and then show rN's log
information *of that object*.
Unfortunately, today, 'svn log' wrongly behaves as if it already
supports peg revisions via -r. For example, watch this sequence:
$ svn log -v -r14998
------------------------------------------------------------------------
r14998 | lundblad | 2005-06-07 07:28:28 -0500 (Tue, 07 Jun 2005) | 8 lines
Changed paths:
D /trunk/notes/TODO-1.2.txt
M /trunk/notes/locking/TODO.txt
Cleanup in notes directory.
The items removed were either done, irrelevant or put in the issue
tracker.
* notes/TODO-1.2.txt: Remove.
* notes/locking/TODO.txt: Remove some items.
------------------------------------------------------------------------
$ svn log -rHEAD http://svn.collab.net/repos/svn/trunk/notes/TODO-1.2.txt
subversion/libsvn_ra_dav/util.c:826: (apr_err=175007)
svn: REPORT request failed on \
'/repos/svn/!svn/bc/15230/trunk/notes/TODO-1.2.txt'
subversion/libsvn_ra_dav/util.c:774: (apr_err=175007)
svn: '/repos/svn/!svn/bc/15230/trunk/notes/TODO-1.2.txt' path not found
Good, we expected an error. After all, 'TODO-1.2.txt' is gone in HEAD.
But, I just happen to know that it was modified in r13902. What
happens if we try that?
$ svn log -r13902 http://svn.collab.net/repos/svn/trunk/notes/TODO-1.2.txt
------------------------------------------------------------------------
r13902 | fitz | 2005-04-04 12:01:50 -0500 (Mon, 04 Apr 2005) | 2 lines
* notes/TODO-1.2.txt: Update.
------------------------------------------------------------------------
$
In other words, 'svn log' treated -r13902 as a peg revision, which
it's not. Subversion should have errored, on the grounds that it
couldn't find an object on which to trace history back to r13902. In
certain subtle situations (where objects with different identity but
the same name replace other objects at the exact same path) this means
that 'svn log' is actually incapable of expressing certain requests.
We've already fixed other commands, such as 'svn cat', to not treat -r
operands this way, and to use '@N' peg rev syntax instead. We just
hadn't gotten around to fixing 'svn log' yet -- that's what issue
#2287 is about.
If we make this change, 'svn log' will be consistent with other
commands. But, the behavior change will be unusually user-visible.
We could just say:
"The old behavior was a bug, get used to the nice, shiny new
consistency of everyone taking peg revs."
In fact, Ben Collins-Sussman and I think that's fine. But, it's
drastic enough that we thought we should ask here first.
Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 1 23:25:07 2005