Should log/missing -rX..Y be changed to be exclusive of X?

[Matthew D. Fuller]

On Sun, Feb 01, 2009 at 08:15:04AM +1000 I heard the voice of
Ian Clatworthy, and lo! it spake thus:
> 
> I've always got the impression that log (and now missing) treating
> the range as inclusive was a very deliberate choice. I wonder what
> cheers and/or resistance we'd receive if they were changed?

You'd get resistance from me.

Really, this isn't a weird inconsistency.  It's ENTIRELY consistent
with our model.  We don't have series of changes, we have series of
states.

The log message is a property of a state.  So a log request starting
from state X will naturally include the log message attached to state
X.  It makes perfect sense to show a log message for one state.
Saying "Show me the log for state 123" and "Show me the log for state
125" both make perfect sense, and it makes very little sense for "Show
me the log for state 123 thru 125" to suddenly stop including one of
the two.  Showing logs for multiple revisions is a direct extension of
showing the log for one revision.

The changes that LED to X from (parent:X) are not a property of the
state; they're prior to it.  So a diff starting from state X will
naturally not include those changes.  It makes no sense to show a diff
for one state (well, you maybe could figure a way to define it, but it
would always be empty).  There's no "diff one revision" to extend to
multiple.

And diffs don't "cover" a set of states like log does.  It could be
entirely reasonable to "log -r3..5 -r7..9 -r19..53" and show logs for
non-contiguous sets of revisions.  Diffs don't cover sets or groups;
they deal with two specified states, not any of the states in between
(except implicitly as those states live on in the 'end' state).


We shoot ourselves in the foot, in this much like some of the workflow
around checkouts, by using language suggesting (or maybe even
ourselves thinking of) differences in outcome as being the result of a
bunch of individual special cases, rather than simply the simple,
natural, and obvious result of _doing different things with different
things_.  It's not simply "revision specs are TREATED differently in
different commands".  Revision specs MEAN different things to
different commands, even if they LOOK the same on the command line.

If we can't articulate why different statements mean different things,
and resort instead to handwaving "Well, that's treated specially",
it's no wonder users end up confused.


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.