Re: [Monotone-devel] Proposal for human readable revision IDs

[Howard Spindel]

As one other poster said, I'm a monotone newbie so I could be way off.

How about *relative* human readable revision IDs rather than all of 
the absolute schemes posted so far?

For example:

monotone diff <filename> --revision=p:1  where "p" stands for 
predecessor and the number following the p shows how many 
predecessors back you want to go?  By using a combined selector, you 
could restrict this to predecessors that you checked in if you wanted.

monotone is much better at figuring out predecessors and their SHA1 
keys than humans are.  This should require no changes to the database 
because the predecessor relationships are already known.  This also 
shouldn't (I don't think) introduce any problems related to local vs. 
global databases or name conflicts - you just get the predecessor 
stored in the database you're referencing, and you aren't creating 
any new names.

One could also consider a successor selection method.  Example:
monotone diff <filename> --revision=t:Release2.0 --revision=s:1

I understand that there could be multiple successors at a given level 
if there is a branch.  monotone could return a message that the 
selector is ambiguous and provide a list of the matching SHA1 
revisions.  I guess in the case of merging there could also be 
multiple predecessors at a given level - again, monotone should just 
say "selector ambiguous".

I don't know about the rest of you, but most of the other revisions 
of a file that I want most frequent access to are within one or two 
revisions of my working copy.

Howard