Cherrypicking workflows with bzr
Martin Pool
mbp at sourcefrog.net
Mon Jan 23 11:11:29 GMT 2006
On 23 Jan 2006, Jan Hudec <bulb at ucw.cz> wrote:
> On Mon, Jan 23, 2006 at 09:55:19 +1100, Martin Pool wrote:
> > On 19 Jan 2006, John A Meinel <john at arbash-meinel.com> wrote:
> > Another approach is to handle rejected and cherry-picked changes at the
> > weave level. SCCS has something like this; I'd previously avoided it
> > because it seems to cause them considerable complexity but it's probably
> > time to add it.
>
> I believe it's the only way to actually handle cherry-picking. The
> picked ancestors need to be recorded in the weave index just as
> ancestors are recorded there (though both are/can be recorded in the
> revision description as well).
I think this is a good way to go. If we don't do anti-cherrypicks
(i.e. revisions that cause previous revisions to be excluded from the
weave) then it should be pretty simple. Anti-cherrypicks are exciting
but have more complex merge cases.
> 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.
--
Martin
-------------- 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/1be32a11/attachment.pgp
More information about the bazaar
mailing list