Issue 118: mtn log direction control - A distributed version control system

Reported by Stephen Leake, Dec 24, 2010

Steps to reproduce the problem:
-------------------------------

1. mtn log --to h: --from w: --brief
2. mtn log --to h: --from w: --brief --next 10000 
3. mtn log --to h: --from w: --brief --last 10000
4. mtn log --to w: --from h: --brief

Expected result:
----------------
Listings 1 and 2 should have the same revisions, in the same order. 

Listings 1 and 3 should have the same revisions, 3 in reverse order

Listing 4 should be the same as listing 3

Actual results:
---------------
1 and 2 have different revisions; 3 is not reversed, 4 is the same 
as 2.

I suggest it would be best to have --to and --from specify the 
listing order. This is simple when each specifies a single revision; 
otherwise it is more complicated. Then a new option --limit could 
specify the max rev count without affecting the listing order.

Another solution would be an explicit --reverse option.

Output of `mtn version --full`:
-------------------------------
1.0dev

Comment 1 by Stephen Leake, Dec 24, 2010

Similarly, 'mtn log --last 10' gives the 10 most recent revs, but 
there is no way to reverse the listing order for that.

Comment 2 by Stephen Leake, Dec 24, 2010

If we had a selector designating the root of the tree (say 'R:', 
complementary to h:), then we could say that '--to defaults to the 
root', and 'log --from R: --to w: would give the reverse order from 
the default 'log'.

But for reversing 'log --last 10', the only solution is an explicit 
'--reverse'. Hmm. we could do 'log --from p:p:p:p:p:p:p:p:p:w --to 
w:', but that's not very practical.  Maybe 'p10:w:'?

At the same time, the listing order for 'mtn log -r today' is only 
partially defined, in the presence of several heads.

Comment 3 by Richard Levitte, Dec 25, 2010

The way it's currently implemented, the only way to get reverse 
order is to use --next.  Basically, --last and --next are the 
options that define order, and they do so from the starting point, 
--from.

I agree with you that it would feel more intuitive to have --from 
and --to define the order of the listing.  I sure would like to see 
that kind of change, say, in monotone 2.0 (I think it's a little too 
late for 1.0).  That would also mean that we could throw away --next 
and --last in favor of what you suggested, --limit.

About finding that 10th parent, couldn't we have another composite 
selector, could be called 'nth' (I've played a lot with Lisp, mmm'k? 
;-)), that takes a number as first argument, the rest being 
selectors.  It would give revisions that are that number of 'steps' 
away from the selectors it was given.  Positive numbers could go 
forward in history while negative numbers could go backward in 
history.  In that case, the reverse of 'mtn log --last 10' could be 
expressed like this: mtn log --from 'nth(-10;w:) --to w:

Status: Accepted

Comment 4 by Richard Levitte, Dec 25, 2010

Oops, missed a single quote there, that last possible command should 
have been this, just to clarify:

mtn log --from 'nth(-10;w:)' --to w:

Comment 5 by Thomas Keller, Feb 21, 2011

Sounds like a nice feature.

Labels: Type:Feature Request ~~Type:Incorrect Behavior~~