[Monotone-devel] Re: user-friendly hash formats, redux

[Oren Ben-Kiki]

On Friday 10 December 2004 01:06, graydon hoare wrote:
> > So, what's your view on the idea of having fork certs, a --fork
> > commit option and using
> > <branch>.<version>[.<author>-<fork>.version>]* to identify
> > revisions?
>
> well, your current proposal has some problems you brush off:
>
>    - it requires some mechanism for differentiating trunks and forks

True. This is considered a feature; if you feel that differentiating 
forks and trunks isn't something you want to do, then the proposal is 
irrelevant.

>    - it is not necessarily stable if <author> commits from two places
>      and then syncs...

True - but if the author specified a --fork flag when he intended to 
create a fork and did not specify one when he intended to advance the 
trunk, there's no renumbering involved.

> but then, that's just a lesser form of 
> "unstable local IDs".. maybe acceptably lesser, but still real. 

True, there are scenarios where the ids are unstable - but they are 
*global* rather than local ids. That is, if I sync with your db, we can 
both talk about "foo.17", "bar.graydon.3" or "baz.oren.5" and be 100% 
certain we are talking about the same revision. This wasn't the case 
for some other proposals (e.g., the <author>-<seq-#> proposal).

> so I'm not really sold on this either. if we're going to think
> seriously about teaching monotone to differentiate between "linear
> trunks" and "diverging forks" (which is possible -- it has some other
> benefits), we ought to have that conversation in terms of *all* of
> its implications, not just that it happens to make number assignment
> easier. it probably makes some things harder too.

Agreed. So, are we going to seriously think about differentiating 
between forks and trunks?

Have fun,

 Oren Ben-Kiki