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

[Jan Hudec]

On Sun, Jan 08, 2006 at 17:43:28 +0100, David Allouche wrote:
> 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.

Well, it was a brain-storming. Yes, it can be simplified.

> 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.

All equivalent functionality of quilt/stgit/mq can be built without it.
The logic that I want to sort out is what it takes to allow merging the
stacks. Ie. when I pull a branch, use stack operations on revisions
already there, branch from the middle of the new stack and then attempt
to merge back to the original branch. And someone does similar thing and
tries to merge back too. It might work with just picked-ancestry, but
needs to be checked.

> 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.

Well, It would need picked-ancestors for the moved down patch and
equivalent-revisions for the moved up patch. Consdier revision A and
revision B based on it. You reorder it, so you get B2[picks=B] and
A2[parent=B2, equals=B]. That is so that if you have D[parent=A2] and
another branch has C[parent=B], you can merge from that branch, taking
A2 as base.

Thinking of it again, if A2[parent=B2,B], then this case would merge
properly too. The question is whether it would suffice for other
operations like revision spliting.

> 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.

Yes, that's clear and makes sense. And should probably work, though the
details of weave-merge (3-way merge won't be able to deal with this)
will still be a bit tricky.

> 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.

Yes, many revisions will be created this way. For common stbzr
operation, where only the final stack should be published, they could be
pruned. If you make a new version of already published stack, they would
of course stay.

> If you have real world use case that you do not think would be addressed
> adequately by this model, please share it with me.

Well, they probably are addressed adequately. Though I am not sure how
the partial cherry-pick (I only pick some of the changes, because the
other parts fix code I didn't merge yet, or are screwed or whatever)
will work out. Maybe it will, but I don't see it.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060113/bb3e2607/attachment.pgp