[RFC] Cherry-picking, reordering revisions and 2D versioning

[David Allouche]

On Fri, 2006-01-06 at 22:41 -0500, Kevin Smith wrote:
> Jan Hudec wrote:
> > I want to say ahead, that what I was thinking of certainly was not meant
> > as a simple tool. It was meant as a quite complex extension of the
> > deepest logic -- and as such of course as a long-term plan. It would add
> > another kind of relationship between revisions. And it is really just
> > vague suggestion -- the logic of merging is not really thought out yet.
> 
> I think you're on a very exciting track. I believe that one of the D-SCM 
> tools will implement something like this, and it will be a huge 
> advancement in the state of SCM. Good work.

I think that is exciting but too hairy for its own good, at least at
first.

Most of the interesting functionality of floating patches (stbzr...) can
be implemented without any of this "reincarnation" logic. I would like
the Bzr model of ancestry to stay really simple.

The common case that needs an extension of the current model is indeed
patch commutation, and it's just a special case of cherry-picking. It
would be sufficient to keep a list of "picked ancestors" that contains
only revision ids that are not part of the normal ancestry.

Here are the use cases:

      * Picking: In bzr.dev, Martin picks the latest revision from
        John's bzr.meinel, colloquially named "the telepathic-ui patch".
        John's branch also contains much work on fix-world-hunger, but
        it's not yet ready for merging. "bzr pick ../bzr.meinel" applies
        just telepathic-ui and adds this revision and all its merges to
        Martin's the picked-ancestry.
      * Pick merging: I merge bzr.dev into bzr.ddaa. Before that, my
        branch does not contain any of the work in progress from John.
        Merging Martin's pick adds telepathic-ui and all its merges to
        my picked-ancestry.
      * Pick flushing: Aaron had merged John's fix-world-hunger work,
        and now merge Martin's branch. The telepathic-ui revisions have
        parents in Aaron's ancestry, so they are removed from the
        picked-ancestry list and turned into a plain merge.

This is purposefully vague for the sake of readability. I could
translate these use cases into a much more correct and obscure language.

There are some important properties to the picked-ancestry list:

      * Picked-ancestry is a property of a revision.
      * Picked-ancestry is a DAG of unique revisions. It does not have
        to be fully connected.
      * Picked-ancestry SHOULD not contain any revision that is present
        in the normal ancestry (it must be distinct).
      * Picked-ancestry SHOULD not contain any revision whose all
        parents are present in the normal ancestry (it must be
        disconnected).
      * A .bzr/pending-picks must be maintained in the working tree in
        parallel to .bzr/pending-merges.

Now, the distinct and disconnected properties cannot be reliably
enforced in the presence of ghost revisions. I think that is a
acceptable and that's why I said "SHOULD", meaning "must be enforced
with best effort".

One downside of building a stbzr on top of this logic would be the
creation of many temporary revisions that would clutter the store and
the ancestry. There could be way to control the clutter using
changeset-based communication, but that would hamper smart merging.
Trying to avoid ancestry clutter up front would be premature
optimization.

If you have real world use case that you do not think would be addressed
adequately by this model, please share it with me.
-- 
                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060108/da512cdf/attachment.pgp