Re: [Monotone-devel] Branches in git and monotone

[Stéphane Gimenez]

Hi,

> However, git's approach does not allow the representation of multiple  
> heads within a branch, but changing it to allow this could be trivial  
> (just attach multiple revids to a branch name).

Yes I was thinking about that also in an even more primitive context.
What about a similar "multiple revids set" as a working state parent.

The following command:
mtn checkout -r a,b,c,d
would:
  - fail if there is no way to auto-merge a, b, c and d revisions (or
    maybe produce a confilcted working directory for workspace merge).
  - check out the auto-merged a, b, c and d revisions otherwise.

And the interesting command would be something like:
mtn checkout -r (a,b,c,d)+
which would:
  - fail in the same as before if there is no way to auto-merge a, b, c
    and d revisions.
  - checkout a working directory containing every revision which has
a, b, c or d as parent (recursively), and which will not imply any
non-auto-mergable conflict with other candidate revisions.

Candidates revisions which have not been included can be repported to the
user and he may choose to pick one (or compatible ones) and add it to his
revision set.

One can even think of a:
mtn checkout -r (a,b,c,d)+bugfixes
command, which won't contain any new features (this requires labels like
"fix" or "feature" to be assigned to commits)

Maybe there are obivious flaws to this model ?

If it happens to be usable, one can after that simpy consider "a,b,c,d"
as a branch, and give it a name. And maybe the possibility to use:
mtn checkout -r monotone-0.34+bugfixes
or
mtn checkout -r monotone-0.34,the-new-feature-i-need

A other (immediate) advantage I see to this model is that revisions
corresponding to automatic merges won't clutter the tree anymore (since
nobody has an obvious need for commiting those).

Also one may also generalise the "daggy fixes" to "daggy commits" and offer
the possibility to the user to compute the oldest ancestors (or ancestors
set) which can be chosen as parent revision(s) of the new revision, such
that auto-merging can be done (and eventualy such that some tests are ok).

Lot's of "maybe it can work". But I'd really like to know what monotone
people think about it.

Regards,
Stéphane.