> 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? :-)
Shouldn't this discussion be taking place on dev@ ?
The ideal way to do this would be to do a log of HEAD:0 pegged at BASE.
But we can't trace efficiently trace history forward until we redesign the
schema in 2.0.
I'm -1 on just flipping the default to HEAD, since it would be horribly
bizarre to see a different line of history being logged, if the name log is
invoked on has been deleted and then replaced-with-history in HEAD, whilst
your your WC is still on the previous historical line.
+0.5 on log doing a relatedness check between URL@HEAD and URL@BASE, and
logging HEAD:0 if the test passes.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jan 3 11:36:39 2005