On 2006-04-09 13:18:22 +0100, Max Bowsher wrote:
> Tagging wontfix, with a recommendation to close,
I agree that this bug should be closed, but not for the same reason
as given below.
> because the reason 'svn log' defaults to -rBASE:1 when run in a WC
> is actually dictated by the underlying structure of the Subversion
> database:
>
> Whilst the Subversion database makes it very easy to trace history
> backwards, the same cannot be said for tracing forwards. As a result, we
> don't have a good way of saying 'for this URL@BASE, give me the
> corresponding object in HEAD' - remember, due to copies/moves, URL@BASE
> is not necessarily the same object as URL@HEAD.
Well, -rHEAD:1 is syntactically correct, so that the above explanation
is not a good reason. In most cases, -rHEAD:1 would be fine and would
be more useful than -rBASE:1 (IMHO), and it would fail in rare cases.
A possible failure is not a good reason to reject any parameter as
being the default.
> The choice of -rBASE:1 deliberately accepts that we may not be showing
> as much log as might be expected, in order to ensure that we never show
> logs for some other incorrect object that happens to have taken the
> place of the WC's URL in HEAD.
Showing incorrect logs would obviously be a bug, since it would be one
with an explicit "-rHEAD:1". But by doing something like
ypig:~tmp/wc1> svn mv dir1 dir2
ypig:~tmp/wc1> svn mkdir dir1
ypig:~tmp/wc1> echo foo > dir1/file1
ypig:~tmp/wc1> svn add dir1/file1
ypig:~tmp/wc1> svn ci
in one working copy, and in another one, not yet updated:
ypig:~tmp/wc2/dir1> svn log -rHEAD:1
svn: E195012: Unable to find repository location for
'/home/vlefevre/tmp/wc2/dir1' in revision 3
I get an error, not incorrect logs, as documented in the Subversion
book:
The Peg Revision Algorithm
[...]
But what if OPERATIVE-REV is younger than PEG-REV?
[...]
Verify that the object's location (path-wise) in PEG-REV is the same
as it is in OPERATIVE-REV. If that's the case, at least the two
locations are known to be directly related, so perform the requested
action on the location in OPERATIVE-REV. Otherwise, relatedness was
not established, so error out with a loud complaint that no viable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
location was found. (Someday, we expect that Subversion will be able
to handle this usage scenario with more flexibility and grace.)
Note that a "svn up" leads to an obsolete current directory,
which is even worse:
ypig:~tmp/wc2/dir1> svn up
Updating '.':
D .
A .
A file1
Updated to revision 3.
ypig:~tmp/wc2/dir1> pwd
/home/vlefevre/tmp/wc2/dir1
ypig:~tmp/wc2/dir1> ll
total 0
ypig:~tmp/wc2/dir1> ll ..
total 4
drwxr-xr-x 2 vlefevre vlefevre 4096 2013-09-03 14:25:10 dir1/
ypig:~tmp/wc2/dir1> ll ../dir1
total 4
-rw-r--r-- 1 vlefevre vlefevre 4 2013-09-03 14:25:10 file1
Now, to come back to "svn log", I think that -rBASE:1 should be
the default for consistency with other commands, which apply to
BASE by default. Anyone can write a shell alias or a wrapper for
"svn log -rHEAD:1" to respond to the initial complaint: "It's
kind of annoying to have to manually specify every file in my
repository when I want to skim a complete log".
Note: the wrapper could also do other useful things, such as piping
the output to a pager if standard output is connected to a terminal
(just like what "git" does).
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
