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
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
