[Python-Dev] crosses branches?

Sjoerd Mullender sjoerd at acm.org
Tue Mar 22 15:39:55 CET 2011


On 2011-03-22 15:11, skip at pobox.com wrote:
> 
>     Sjoerd> Since you have a local change, you cannot use hg pull -u (or
>     Sjoerd> rather, hg update).  Hg wouldn't know where to update to since
>     Sjoerd> there are 2 heads in the branch you're on: the new head from the
>     Sjoerd> server and your own head with your change.
> 
> I see lots of heads, but that never prevented an update before.  How do I
> tell which two heads are key to this case?  For completeness, here's the
> output of hg heads in my 2.5 repository.  I only see one labelled "2.5".
> What is the other head to which you referred?

Two heads in the same branch.
Are you sure the hg pull part worked?  When I update I see there are
changes on the 2.5 branch which I would expect to see in your list.
It probably never happened before because nobody committed a change to
the 2.5 branch since you made your change.

So, try hg pull and the look at the heads again.

>     changeset:   68827:3114f26d5d54
>     tag:         tip
>     user:        Victor Stinner <victor.stinner at haypocalc.com>
>     date:        Tue Mar 22 10:46:35 2011 +0100
>     summary:     Issue #11630, issue #3080: Fix refleak introduced by
>     ef2b6305d395
> 
>     changeset:   68804:f316e6d6271a
>     branch:      2.7
>     parent:      68801:6b2edc385ffe
>     parent:      68803:b99c94261225
>     user:        Martin v. L?wis <martin at v.loewis.de>
>     date:        Mon Mar 21 10:32:02 2011 +0100
>     summary:     null merge
> 
>     changeset:   68309:c3caaf979b9e
>     branch:      2.5
>     parent:      68263:7790ad8332ba
>     user:        Skip Montanaro <skip at pobox.com>
>     date:        Sun Mar 06 21:31:25 2011 -0600
>     summary:     manually expand the defunct HeadURL subversion keyword
> 
>     changeset:   68249:4cd9f5e89061
>     branch:      3.0
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 15:09:43 2011 +0100
>     summary:     Close 3.0 branch.
> 
>     changeset:   68241:b77918288f7d
>     branch:      legacy-trunk
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:57:44 2011 +0100
>     summary:     Close legacy-trunk branch.
> 
>     changeset:   68239:ceec209b26d4
>     branch:      2.4
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:56:41 2011 +0100
>     summary:     Close 2.4 branch.
> 
>     changeset:   68237:364638d6434d
>     branch:      2.3
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:55:46 2011 +0100
>     summary:     Close 2.3 branch.
> 
>     changeset:   68235:61b0263d6881
>     branch:      2.2
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:55:23 2011 +0100
>     summary:     Close 2.2 branch.
> 
>     changeset:   68233:e849d484029f
>     branch:      2.1
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:54:46 2011 +0100
>     summary:     Close 2.1 branch.
> 
>     changeset:   68231:5fd74354d73b
>     branch:      2.0
>     user:        Georg Brandl <georg at python.org>
>     date:        Sat Mar 05 14:54:19 2011 +0100
>     summary:     Close 2.0 branch.
> 
>     Sjoerd> There are two possibilities: hg merge + hg commit to merge your
>     Sjoerd> change with the change from the server, or hg rebase (after you
>     Sjoerd> enable the extension and with extra arguments to specify source
>     Sjoerd> and destination revisions).  This would take your change and
>     Sjoerd> graft if on top of the head from the server.
> 
> Looking here at the Common Cases section:
> 
>     http://mercurial.selenic.com/wiki/RebaseProject
> 
> I can see how I have now apparently got this situation:
> 
>      C1 --> C2 --> S1
>             \
>              \ --> ... Cn
> 
> (where S1 is my local change and C? are the central changesets)
> 
> Rebase will do this, right?
> 
>      C1 --> C2 --> ... --> Cn --> S1
> 
> Am I going to have to rebase then every time I re-pull that repository and
> incorporate new upstream changes?  Wouldn't I rather want the chain of
> revisions to look like this after the rebase step?
> 
>      C1 --> C2 --> S1 --> ... --> Cn
> 
> Skip
> 


-- 
Sjoerd Mullender

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 371 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110322/551c5ff4/attachment.pgp>


More information about the Python-Dev mailing list