Re: [Monotone-devel] Re: branching policy

[Daniel Carosone]

On Thu, Jun 15, 2006 at 12:07:38PM -0700, Bram Cohen wrote:

> Branches are centralized and persistent and form a spanning tree. 

This sounds like an interesting idea, and I haven't really begun to
digest yet what you're describing in detail.  As I try to do so, I
immediately realise that we're at risk of some terminology confusion.

When you talk about a spanning tree of branches, how does this relate
to DAG-style history?  Does your tree have just a single node for each
named branch, or are you talking about spanning across the revision
tree by branch membership?  In either case, does your use of "branch"
make assumptions about how DAG structure and branch membership might
relate?

As I'm sure you're aware, in monotone revisions can be members of
multiple branches, and branches can be discontinuous with respect to
the revision graph.  So first and foremost we've learned the need to
be quite careful about whether we're describing the branching
structure of the revisions DAG, or branch membership.  We've also
learned that the cases where the difference is important can be very
enlightening.  In the monotone world we also don't really *do*
centralised at all, though signed policy statements may replace
several things other systems control more directly with their
centralised implementations. (We also clash on the use of "pull", but
that's distracting at worst).

What I'm wondering about is how eliminating branch propagation loops
in your spanning tree relates to the existing graph between the
revisions (which has loops if you ignore directionality). I have a
half-formed suspicion that a significant portion of what you describe
can be boiled down to a few well-placed "neighbour" annotations
(certs) on specific revisions, together with some interpretation rules
for what it means for merges and propagates between revisions and
branches that do and don't have a "neighbour" cert on their various
kinds of ancestors (e.g. a neighbour cert on a minimal ancestor might
supplant one on a more distant ancestor). Or perhaps a different kind
of cert that blocks merges/propagates which must cross more than 2
such certs in single command.  Or even whether it's possible to just
infer much of your neighbourship property from the continuity of
branch membership up the ancestry tree.

We've speculated on various possible interpretations and uses for the
disjoint branch membership property (while recognising that in
practice it seems to be rare).  It's always felt to me like something
interesting and just waiting for someone to think up a really good use
for.  One workflow example is a kind of scatter-gather merge, where
various experiment branches would be marked successful with a cert and
then pulled back together with a merge (rather than the more
push-style 'propagate' command). Of course the underlying merge and
DAG result is the same, but the annotations and certs on that tree are
different and these differneces could be interpreted as significant by
workflow tools (like inferring branch closure, for example).  

What you describe sounds not so different at all from this.

--
Dan.

pgpDk0gbBoCS4.pgp
Description: PGP signature