This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ezio.melotti
Recipients chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan, ned.deily, pitrou, python-dev, sandro.tosi, terry.reedy, tshepang
Date 2013-03-14.03:05:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1363230338.68.0.782946044854.issue14468@psf.upfronthosting.co.za>
In-reply-to
Content
> Question: commit to 3.2, merge forward without change, push, and message is '... new
> remote head in 3.2'. Is 3.2 really the only branch with a head conflict?

I don't remember the details of the error message, but you can use "hg heads" to verify that.  In general this shouldn't happen, because if someone committed something on 3.2, he should have also merged and pushed it on 3.3/default[0].  It could happen if you forget to update your 3.2 clone but you have updated 3.3 and default clones.

> Or would one appear in 3.3 as soon as 3.2 heads are merged and merge
> is merged forward to 3.3?

Heads on a branch don't appear magically.  The only two ways to create another head on a branch are:
  1) make a commit on a branch that is not updated;
  2) pull a changeset after you made a commit;

If the branch is updated, a new commit will replace the previous head, which will be its parent.

To answer your question, assume you have one head on default, one head on 3.3, and two heads on 3.2.
The first thing you have to do is merge the heads of 3.2, so that you end up with one head per branch.  This created a new changesets on 3.2, but 3.3 and default are unaffected.
This new changeset -- like all the other changesets on 3.2 -- must be merged with 3.3/default, so you merge branches as you would do with any other changeset you committed on 3.2.

In the worst case scenario, you just made commits on all the four branches, and someone else did the same and pushed before you.  Your push fails because it creates new heads.
You pull the new changesets and end up with 2 heads for each branch.
To solve this you have to do:
 1) 2.7$ hg merge (merge heads on 2.7);
 2) 3.2$ hg merge (merge heads on 3.2);
 3) 3.3$ hg merge (merge heads on 3.3);
 4) 3.x$ hg merge (merge heads on default);
 5) 3.3$ hg merge 3.2 (merge 3.2 with 3.3);
 6) 3.x$ hg merge 3.3 (merge 3.3 with default);

I'm not sure this answers your questions -- I tried to explain it using different approaches, but the end result wasn't much clearer, so I discarded them.  The concepts themselves are not particularly complicated or difficult to understand, however they are not really easy to explain either :)
Using "hg glog" or http://hg.python.org/cpython/graph/ (or the one integrated in TortoiseHG) should help.

[0] note that this is not currently enforced. #15917 has a patch to fix this.
History
Date User Action Args
2013-03-14 03:05:38ezio.melottisetrecipients: + ezio.melotti, terry.reedy, ncoghlan, pitrou, ned.deily, eric.araujo, sandro.tosi, chris.jerdonek, tshepang, python-dev
2013-03-14 03:05:38ezio.melottisetmessageid: <1363230338.68.0.782946044854.issue14468@psf.upfronthosting.co.za>
2013-03-14 03:05:38ezio.melottilinkissue14468 messages
2013-03-14 03:05:38ezio.melotticreate