[Monotone-devel] Re: branching policy

[Bruce Stephens]

Bram Cohen <address@hidden> writes:

[...]

> Branches are centralized and persistent and form a spanning
> tree. New branches can be created by specifying the current branch
> to be their initial neigbor. Editing of branches is generally done
> as normal. There's a special 'pull' command to pull data from a
> neigbor into a specific branch.

That sounds like a convenient feature.  I'm forever doing "monotone
propagate --lca ... ..." to get trunk changes on to the branch I'm
working with.  (--lca because we're still using 0.25.)

I'd guess that kind of thing's fairly common.  (Doubtless it would fit
into management branches/policy branches, or whatever they're going to
be.)

I noticed njs mentioned AccuRev on irc, and I read a bit about that.
It sounds like their streams are intended to capture a similar kind of
usage.  (In detail it seems a bit too file-oriented to me, but
probably that works OK in practice.)

> There's also a reneigbor command to sever the connection to a
> specific neigbor and make a new one to a specified branch, which
> passes if (1) the reneigboring won't form a loop, and (2) the
> current state of the new neigbor has the lca with the old neigbor as
> an ancestor.

Yeah, I can see that might make sense, too.  I guess in monotone terms
that would be doing a merge with the new neighbour, and changing
however the semi-automatic propagation works?

As far as I understand it, this works more cleanly in AccuRev, because
streams needn't have any content.  They record changes to specific
files, with all the other files coming from parents; as you commit to
particular changes, you promote those changes, and then they're in the
parent stream.  So at times, a stream can be empty, so you can then
easily move it to take things from a different stream.

However, I think there's a chance something more limited would work in
other systems (such as monotone) as you describe, and be useful.

(<http://irsa.ipac.caltech.edu/work/jcg/SCM/accurev/> has some good
references to the AccuRev documentation, if anyone cares.)

[...]