question about merging
david at allouche.net
Fri Dec 1 21:00:14 GMT 2006
Nicholas Allen wrote:
> Imagine a scenario where you have a trunk and a bug fix branch. The bug
> fix branch is for a previous release and is where you checkin stable
> code. The trunk is used for mainline development and contains new
> unstable code since the bug fix branch was created. Suppose I create a
> branch off trunk to implement a small feature. Then it is decided that
> this feature should really go into the bug fix branch as it is small and
> also fixes some kind of bug. If the branch is merged into the bug fix
> branch all the new code that existed on the trunk will also get merged
> but this is not desired. Instead you only want to merge the changes made
> in that branch and not any that were made on the trunk as these changes
> may be unstable.
> How would you do something like this in bzr? Would you specify a range
> of revisions to merge?
Yes. Actually, I read the -r N..M syntax as "the delta from N to M".
More on this below.
> I guess this is just cherry picking but bzr does
> not keep track of cherry picked revisions yet does it?
Note that in the N..M syntax, the cherrypicked revisions would actually
I do find this a bit confusing that when specifying a delta as a range
of revisions it is effectively a left-open range.
> There's no way to merge the changes made in the branch itself as a whole
> is there without using cherry picking?
What you describe is pretty much the whole purpose (in terms of ancestry
graph, the surrounding story may vary) of cherrypicking in the sense of
"this revision, but only up to that ancestor".
Note this interesting page from the Monotone website
It describes a pattern to limit the need for cherrypicking.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061201/26fc6e75/attachment.pgp
More information about the bazaar