[Python-Dev] Hg: inter-branch workflow

[R. David Murray]

On Thu, 17 Mar 2011 13:35:50 +0100, Jesus Cea <jcea at jcea.es> wrote:
> On 17/03/11 06:14, R. David Murray wrote:
> > Clearly, this procedure is not for everyone
> 
> Clearly not :).
> 
> So you do a "hg strip" and start over again.
> 
> The problem with this is that your patch will be applied on top of the
> incoming changeset, and your merge will merge that patch too, if the
> original pusher haven't done it yet.

Not if the cpython repo is in a fully merged stated.  And if it
isn't, I will wait until it is.  (The update notifications on the
IRC channel help with monitoring this.)

> Tonight I was thinking about doing a merge inside the branch, to solve
> the "+1 branch". Something like transforming:
> 
> branch 3.2 -----My patch----incoming patch---
> branch 3.x ----------------------------------
> 
> to
> 
>                     +--------------------------+
>                     |                          |
>                     |                          v
> branch 3.2 -----My patch----incoming patch---merge---
>                     |
>                     V
> branch 3.x --------merge------------------------
> 
> So I merge my patch to the other branches, preserving history and
> keeping only a single head in the 3.2 branch, that the other developer
> must merge to 3.x.

I cannot at the moment wrap my head around this, and I really have no
desire to do so.  I will keep things as simple as I can for myself,
even if that means I do a little more work (redoing my merge dance on a
push race) or have to wait until the repo is sane again.  (Or, perhaps,
make the repo sane, if the committer who left it in a weird state doesn't
seem to be fixing it; and *then* apply my patch.)

If you leave an unmerged changeset in 3.2, I would consider that to be
leaving the repo in a weird state.  I want to see something like this
after I do a pull and before I do a push:

>hg branches
default                    68637:2b3fb2398f45
2.7                        68630:d8eaeee1c063
3.2                        68636:21fe6d393242 (inactive)
3.1                        68625:d9c3cfd36b58 (inactive)
2.6                        68377:d6626c9fc28d (inactive)
2.5                        68263:7790ad8332ba (inactive)

That is, only 2.7 and 3.2 are active.  This is what is recommended by
the devguide, to my understanding.

--
R. David Murray                                      www.bitdance.com