How to pull/merge selective changesets

[Bruce Frederiksen]

Sorry it's taken some time to respond to this, I've been quite busy and
wanted to work up some test scenerios to check out how this all works (which
I've attached to this email)...

On Fri, Aug 21, 2009 at 3:11 AM, Stuart W. Marks <smarks at smarks.org> wrote:

> Bruce Frederiksen wrote:
>
>> Then I guess as you add more releases, you could play it by ear in terms
>> of creating new named branches to represent the various possibilities if and
>> when they become necessary.  Having multiple named branches would mean
>> multiple merges, but I guess these could be delayed and done as needed.  For
>> example, [...]
>>
>
> I'm not sure named branches would actually be effective for this. The
> problem is when to create the 'common' branch. Continuing the example,
> suppose development in the dev repo proceeds normally on the 'default'
> branch. Then you release, and you clone a release_2 repo for bugfixing, and
> continue development in the dev repo. Oh wait: before cloning you need to
> have created the default branch. So what do you do? Create a dummy changeset
> and mark it as 'common' and then commit it? But that doesn't seem right,
> since most of the development would have been on the 'default' branch up
> until the point of release. You'd really want to develop on 'common' all the
> time... but this isn't right either, since changesets added to dev after
> cloning aren't common at all.


It seems that the concern here is based on not being able to create the
named branch after the clone.  But my testing shows that this is, indeed,
possible.  It is only necessary to use the -f option on the first push (the
one that creates the named branch).   (see below).

So I don't think you really want to used named branches for this.
>
> What we do is to create a tag before making the clones for parallel lines
> of development. Replaying the above scenario, when you make a release, add a
> 'release_2' tag and then clone the release_2 repo. After this point, the
> changes in release_2 and dev will diverge, but you know they both contain
> the release_2 tag as a common ancestor. To put the same fix in both, update
> to the release_2 tag, commit the change, merge. Then pull -r the change into
> the other repo and merge there. Repeat the process for release_3.


I agree, I would certainly want to tag the release.  I guess the difference
between the tagged approach and the named branch approach is that with the
named branch approach, you are always working from the last common
changeset, rather than the initial tagged changeset.  This would mean
potentially fewer merge conflicts.

I've attached the output of a little test scenerio that I worked up.  It
turns out that this scenerio would produce a merge conflict on the second
common change using tags, but not using the named branches (as is shown in
the example).  This also shows creating the named branch after the clone.  I
would be interested to know whether this addresses your concerns about using
named branches, or if there are other concerns that I am still unaware of.

Thank you again for all of your help!

-Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090828/5b57137f/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: script.out
Type: application/octet-stream
Size: 3623 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20090828/5b57137f/attachment.obj