I think, there is something wrong with state of hg.python.org at the moment.
On a fresh clone from hg.python.org
$hg clone ssh://hg@hg.python.org/cpython cpython
If I do, hg branches, the 3.2 is shown as inactive. Did something change recently?
(env27)bash-3.2$ hg branches default 74263:8f7c4b16c8d7 2.7 74256:789d59773801 3.2 74262:b8f978aa2614 (inactive) 3.1 74253:fb5707168351 (inactive) 2.6 73245:62fa61f2ee7d (inactive) 2.5 73244:b48e1b48e670 (closed) 3.0 68249:4cd9f5e89061 (closed) legacy-trunk 68241:b77918288f7d (closed) 2.4 68239:ceec209b26d4 (closed) 2.3 68237:364638d6434d (closed) 2.2 68235:61b0263d6881 (closed) 2.1 68233:e849d484029f (closed) 2.0 68231:5fd74354d73b (closed)
The problem is when I clone cpython to 3.2, update 3.2, make changes, commit , it creates a new head when I try to commit, it asks me to merge
Workflow (which is supposed to work seamlessly and had been working till my last commit a week ago).
$hg clone cpython 3.2 $cd 3.2 $hg update 3.2 $hg branch 3.2 $#make changes $hg commit # gives a msg saying one head created. Which is wrong. $hg push ... searching for changes abort: push creates new remote heads! (did you forget to merge? use push -f to force)
Was there any wrong merge? Or am I doing something wrong?
-- Senthil
2012/1/4 Senthil Kumaran <senthil@uthcode.com>:
I think, there is something wrong with state of hg.python.org at the moment.
On a fresh clone from hg.python.org
$hg clone ssh://hg@hg.python.org/cpython cpython
If I do, hg branches, the 3.2 is shown as inactive. Did something change recently?
It just means you need to merge changes from upstream in the same branch with your changes.
-- Regards, Benjamin
Senthil Kumaran wrote:
I think, there is something wrong with state of hg.python.org at the moment.
On a fresh clone from hg.python.org
$hg clone ssh://hg@hg.python.org/cpython cpython
If I do, hg branches, the 3.2 is shown as inactive. Did something change recently?
From hg help glossary:
If a named branch has no topological heads, it is considered to be
inactive.So AFAICS, this just means that 3.2 has been merged to default (which always should be the case).
(snip)
searching for changes abort: push creates new remote heads! (did you forget to merge? use push -f to force)
Was there any wrong merge? Or am I doing something wrong?
I think you should merge to default before pushing. That's at least what I always do. If the change shouldn't be made to 3.3 for some reason, you should do a "null merge".
Please note that I'm not a hg expert, rather a hg disliker :)
Petri
On Wed, Jan 4, 2012 at 4:39 PM, Petri Lehtinen <petri@digip.org> wrote:
Senthil Kumaran wrote:
I think, there is something wrong with state of hg.python.org at the moment.
On a fresh clone from hg.python.org
$hg clone ssh://hg@hg.python.org/cpython cpython
If I do, hg branches, the 3.2 is shown as inactive. Did something change recently?
From hg help glossary:
If a named branch has no topological heads, it is considered to be inactive.
So AFAICS, this just means that 3.2 has been merged to default (which always should be the case).
(snip)
searching for changes abort: push creates new remote heads! (did you forget to merge? use push -f to force)
Was there any wrong merge? Or am I doing something wrong?
I think you should merge to default before pushing. That's at least what I always do. If the change shouldn't be made to 3.3 for some reason, you should do a "null merge".
Petri has it right here. The default state for hg.python.org/cpython is to have only two active heads: default and 2.7.
3.2 should be inactive, because all 3.2 changes should either be merged into default, or else explicitly flagged as inapplicable to default (by merging, reverting and then committing).
I'm not sure why you're regularly making fresh clones rather than using "hg pull -u" to update an existing clone (which is a *lot* faster).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Jan 4, 2012 at 2:39 PM, Petri Lehtinen <petri@digip.org> wrote:
From hg help glossary:
If a named branch has no topological heads, it is considered to be inactive.
So AFAICS, this just means that 3.2 has been merged to default (which always should be the case).
Got it. I got confused when I saw 2.7 as an active one. (And yeah, since 2.7 is not merged to default, it is an active one.)
(snip)
searching for changes abort: push creates new remote heads! (did you forget to merge? use push -f to force)
Was there any wrong merge? Or am I doing something wrong?
I think you should merge to default before pushing. That's at least what I always do.
Yeah, the trouble was, when pushing from local 3.2 to local default, it was aborting asking me to merge. Which was odd, because I had just done the cloning of (local) default to (local)3.2 and I was in the correct branch as well.
Ned Deily on IRC suggested that I do the reverse, that is, pull the changes to default (from local 3.2) and then do the merge, commit, push. It seem to have worked. But I could not figure out, why the first push did not work. I shall try again and see why it occurred.
Thanks, Senthil
participants (4)
-
Benjamin Peterson -
Nick Coghlan -
Petri Lehtinen -
Senthil Kumaran