[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Proposal for human readable revision IDs
From: |
Howard Spindel |
Subject: |
Re: [Monotone-devel] Proposal for human readable revision IDs |
Date: |
Tue, 06 Sep 2005 13:22:27 -0700 |
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] Re: Proposal for human readable revision IDs, (continued)
- [Monotone-devel] Re: Proposal for human readable revision IDs, Lapo Luchini, 2005/09/09
- Re: [Monotone-devel] Re: Proposal for human readable revision IDs, Andy Jones, 2005/09/09
- Re: [Monotone-devel] Re: Proposal for human readable revision IDs, Jon Bright, 2005/09/12
- Re: [Monotone-devel] Re: Proposal for human readable revision IDs, Andy Jones, 2005/09/12
- Re: [Monotone-devel] Re: Proposal for human readable revision IDs, Florian Weimer, 2005/09/13
- Re: [Monotone-devel] Re: Proposal for human readable revision IDs, Brian Downing, 2005/09/30
- Re: [Monotone-devel] Re: Proposal for human readable revision IDs, Daniel Carosone, 2005/09/30
Re: [Monotone-devel] Re: Proposal for human readable revision IDs, Hendrik Boom, 2005/09/09
Re: [Monotone-devel] Proposal for human readable revision IDs, Steven Grimm, 2005/09/06
- Re: [Monotone-devel] Proposal for human readable revision IDs,
Howard Spindel <=
- Re: [Monotone-devel] Proposal for human readable revision IDs, Bruce Stephens, 2005/09/07
- Re: [Monotone-devel] Proposal for human readable revision IDs, Chad Walstrom, 2005/09/08
- magic selectors (was Re: [Monotone-devel] Proposal for human readable revision IDs), Nathaniel Smith, 2005/09/09
- Re: magic selectors (was Re: [Monotone-devel] Proposal for human readable revision IDs), Zbynek Winkler, 2005/09/10
- [Monotone-devel] Re: magic selectors, Richard Levitte - VMS Whacker, 2005/09/10
- Re: [Monotone-devel] Re: magic selectors, Andy Jones, 2005/09/12
[Monotone-devel] Re: magic selectors, Richard Levitte - VMS Whacker, 2005/09/27
Re: [Monotone-devel] Re: magic selectors, Nathaniel Smith, 2005/09/27