kfogel@collab.net wrote:
> [I accidentally posted this to users@ first, but I meant to post it here.]
>
> 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? :-)
Yes, *big* -1 on just changing the default revision specifier to HEAD:0.
Suppose that you are working in a directory mydir, at revision 30, on trunk.
At revision 20, mydir was branched.
At revision 40, trunk mydir was deleted, and replaced with branch mydir.
You run svn log. If the default was HEAD:0, you will see the revisions on
the branch, not on the trunk, for the range r21:39. This is far worse
confusion than not showing recent commits.
(Note that the ideal would be to do a diff of HEAD:0 pegged at BASE, but we
cannot trace history forward until we improve the schema in 2.0)
An acceptable alternative would be to define a new revision specifier:
HEAD-IF-RELATED-TO-BASE-ELSE-BASE
Note that I am still -0 on this alternative. (My opinion has changed since I
responded on users@)
In my opinion, papering over a particularly common case of the consequences
of mixed revision working copies only serves to make the topic more
mysterious. I don't think we would be doing users any real favours by
allowing them to remain ignorant of mixed revisions for longer.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 4 11:19:20 2005