Cherrypicking workflows with bzr

[Jan Hudec]

On Mon, Jan 23, 2006 at 22:11:29 +1100, Martin Pool wrote:
> On 23 Jan 2006, Jan Hudec <bulb at ucw.cz> wrote:
> > On Mon, Jan 23, 2006 at 09:55:19 +1100, Martin Pool wrote:
> [...]
> > I think it sounds reasonable this way.
> > 
> > I would add another complex case:
> > 
> > It might happen that a foo branch has a revision, let's call it quux,
> > that a bar branch needs to pick. However there is a hunk in it that is
> > related to foo-specific changes, so the revision in bar that picks quux
> > (let's call it quuxbar) reverts that hunk. Now when foo later merges
> > bar, that hunk should NOT be reverted.
> > 
> > That would mean that instead of recording that quuxbar includes quux
> > (without ancestry) and removes that hunk again, to record that quuxbar
> > includes particular hunks from quux.
> 
> Ideally, the author of foo would have put those in two separate
> revisions in the first place, and then we could have just picked one but
> not the other.  Of course it does often happen this way.
> 
> It seems we would need to track each individual change hunk (or line)
> individually - so you could in principle merge them individually, and
> perhaps it is just UI that we normally merge everything in a revision.
> 
> Another approach would be to go back and split the original revision
> into two sub-revisions, representing the parts we want and the parts we
> do not want.
> 
> Of course you would want to distinguish this from a genuine intention to
> modify or revert the merged-in text.
> 
> It's an interesting idea.

Well, the intention to revert can be represented by merging it all and
reverting in another revision.

I actually like the idea of splitting the revision. However if I split
the revision in my branch, the other branch will still contain the
unsplit one. And proper merging has to be implemented, which is rather
complex and needs some modifications of the core logic.

By the way the UI could auto-split the revision to the part I picked and
the rest (by doing some kind of interdiff), which would then do the
right thing when merged back. But again, 'reincarnating' revisions (see
the 'Cherry picking, patch reordering and 2-dimensional versioning'
thread) would be quite complicated stuff.

-- 
						 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/20060123/9b2461f6/attachment.pgp