It's kind of annoying to have to manually specify every file in my
repository when I want to skim a complete log; it would be nice if there was
an option that caused "svn log ." to descend into subdirectories, similar to
the -R option for "svn revert".

  Daniel

retitle 287756 "svn log" should default to HEAD:1, not BASE:1
thanks

  It appears I was wrong about "log" not being recursive: although that
appeared to be the problem in a few special cases, what's happening is that
it's actually truncating the history several months ago.  "svn log -r 1:HEAD"
gives me the full history of the repository.  Sorry about that, but anyway,
it's not at all clear why "svn log ." and "svn log -r 1:HEAD ." should
produce different results.

  ...

  Ok, I see, the default is BASE:1, not HEAD:1, and BASE refers to the "base
revision of item's working copy", whatever that means.  Why not HEAD?  It
appears to me that BASE refers to the point at which the WC was checked out,
which seems like a useless place to start logging.

  Daniel

Hello Daniel,

In your paragraph here:

     Ok, I see, the default is BASE:1, not HEAD:1, and BASE refers to the
     "base revision of item's working copy", whatever that means.  Why
     not HEAD?  It appears to me that BASE refers to the point at which
     the WC was checked out, which seems like a useless place to start
     logging.

The BASE revision is not the revision where the working copy was checked
out, it's the last revision that the working copy has been updated to,
so for long lasting working copies, these may be significantly different
revisions.

Also, svn log behaves differently for paths in your working copy versus
on the server itself

$ svn help log
log: Show the log messages for a set of revision(s) and/or file(s).
usage: 1. log [PATH]
        2. log URL [PATH...]

   1. Print the log messages for a local PATH (default: '.').
      The default revision range is BASE:1.

   2. Print the log messages for the PATHs (default: '.') under URL.
      The default revision range is HEAD:1.

Presumably, if HEAD is revision 1000 and you're working on revision 900
and haven't updated in a while in your working copy, then running svn
log against the working copy, you'll want to see what's happened in the
past from 1 to 900 and not care about the "future" revisions.

If you do the same svn log against the URL that represents the file or
directory in the repository, then implicitly you're saying you don't
care about the revision in your working copy, so show all revisions.

If you do want this changed, I would suggest discussing it in greater
detail on one of the Subversion users mailing lists, probably the users one:

http://subversion.tigris.org/servlets/ProjectMailingListList

Also, the Subversion O'Reilly book available for free from

http://svnbook.red-bean.com/

is a good reference to figure out what BASE means.  It's where I went :)

Regards,
Blair

tags 287756 wontfix upstream
thanks

Tagging wontfix, with a recommendation to close, 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.

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.


Max.

I agree that this bug should be closed, but not for the same reason
as given below.

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.
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).