[Python-Dev] Hg: inter-branch workflow
R. David Murray
rdmurray at bitdance.com
Thu Mar 17 14:45:49 CET 2011
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
More information about the Python-Dev
mailing list