monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Nathan Myers
Subject: Re: [Monotone-devel] Re: user-friendly hash formats, redux
Date: Fri, 10 Dec 2004 06:08:16 -0800
User-agent: Mutt/1.3.28i

On Fri, Dec 10, 2004 at 10:13:51AM +0200, Oren Ben-Kiki wrote:
> On Friday 10 December 2004 03:18, Brian P. Campbell wrote:
> > For instance, various people have discussed adding +n or -n for
> > walking up and down the tree, which I think is a great idea.
> 
> The +n/-n notation has a problem when there's a fork (or merge).

+n/-n is not very flexible.  Consider, instead, suffixes that I'll
represent symbolically as .p and .c, for parent and child.  Then, 
-2 looks like ".p.p" and +2, ".c.c".  On a merge, .p.p becomes 
ambiguous, but you can decorate it with, e.g., .pl.p or .p.pr, 
with "l" and "r" for left and right.  Maybe instead of left/right, 
you just specify one or two digits of the correct node's hash.  Or, 
maybe when you did the merge, you had to say which one was "left".  
Or maybe monotone assigns it at random, and tells you which is 
which when you look at the graph.  Or, maybe left is always the 
older one.  Or maybe most of the above, with different annotations.

Suffixes naturally support more interesting paths just as well, 
such as .p.cr for the right-child of my parent (presuming I'm 
the left child).  Where might only be a left or right parent, 
a node might have N children, so left/right is not necessarily 
meaningful for them, and a hash fragment or tag might be needed 
to disambiguate.

Nathan Myers
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]