Many users (including me) are periodically confused and/or annoyed by
the fact that 'svn log' defaults to the working copy at BASE, instead
of at HEAD. That is:
$ svn commit -m "Commit a new revision."
[...]
Committed revision 245.
$ svn log
[... r245 is not shown, because it's too recent ...]
$
Sure, there are workarounds. You can pass "-rHEAD:0", or you can run
log on the URL, or you can run update before log. But these are all
inconvenient. Most people just want 'svn log' to Do The Obvious Thing
when invoked with no arguments.
IIRC, there were two reasons we chose to default to BASE:
* The "Unknown Future" problem.
If 'svn log' defaults to "-rHEAD:0", there is no guarantee the
working copy's URL even exists in the repository at HEAD. We
know it exists at BASE, of course, but who knows what may have
happened since then? (See comment in svn_cl__log() recording
that this was one of the objections.)
* The Consistency problem.
Other svn operations operate on the working copy at its base
revision, so 'svn log' should behave consistently.
The "Unknown Future" reasoning isn't terribly persuasive, IMHO. We
shouldn't be penalizing the 99.9% common case just to avoid a very
rare failure case. Especially when the failure case has an easy
workaround (pass an explicit -r option).
The Consistency argument isn't very persuasive either. Consistency is
not a virtue in itself, it is only a virtue insofar as it makes
Subversion easier to use. But in this case, the inconsistent behavior
would actually be more intuitive. We would never see people posting
to ask why they *are* able to see recent commits when they run log :-).
Have I forgotten any arguments against making 'svn log' default to
HEAD:0 instead of BASE:0? Are there compatibility objections? (I
would think not, but UI changes are always a judgement call.)
Would anyone object if we changed to HEAD:0 and made everyone's lives
easier? :-)
-Karl
Ben Collins-Sussman <sussman@collab.net> writes:
> > "svn log" has really annoying behaviour where is hides log messages
> > for revisions that are newer than what is currently checked out. I
> > read
> > a few messages that mentions this, and it seems that this won't be
> > changing
> > any time soon, but I find this behaviour horribly confusing.
> > Is there a configuration option that I can set to change this? I
> > thought there was a way to specify default args to a svn command, but
> > I can't seem to find it. I'd be happy if I could specify "-r HEAD"
> > as the
> > default option for svn log.
>
> 'svn log', with no arguments, runs the command on the '.' directory at
> BASE revision... just like every other svn subcommand. That means
> you're asking to see the history of every commit ever made to the
> working-dir at revision BASE, then going backwards in time from there.
>
> So, if your working copy is all at revision 8, and then you commit a
> change to foo.c, the whole working is *still* at revision 8, and foo.c
> is now at revision 9. If you run 'svn log', you're asking for all
> commits that happened to r8 of the directory. That means you *won't*
> see the r9 commit you just made.
>
> The two workarounds are:
>
> 1. run 'svn log' on a URL instead of '.'
>
> 2. run 'svn up' first.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 3 04:54:38 2005