[Python-Dev] Hg: inter-branch workflow

[R. David Murray]

On Thu, 17 Mar 2011 00:20:26 +0100, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > I think devguide's suggested interbranch workflow introduces too
> > much complexity for too little payoff.
> > 
> > If I need to make a fix to 3.2, I can't just fix it.  I would need
> > to also merge the changeset into 3.3 and then revert it, and then
> > commit both.  There is not much payoff to this style.  It brings
> > back the ghost of svnmerge but it much more restrictive:
> 
> Well, you might not have liked svnmerge, but most other devs preferred
> using it instead of porting patches by hand.
> I think the same argument goes for "hg merge".

+10.  And I've done quite a few commits here at the sprints.  I'd *really*
hate to have had to patch each branch by hand.  If I'd had to do that
I'm sure I wouldn't have bothered with 3.1.  As it is, once I applied
the patch once to 3.1, doing the merges was a piece of cake.  Patching
2.7, on the other hand, is a pain.

Dealing with a null merge when someone else has committed between the
time I started the merge dance (I always pull just before I start that)
and the time I push is not that hard either.  It pretty much amounts to
having to do an additional set of merges.  (In my case I do a strip and
restart my merge dance, but I'm not sure I should recommend that since
altering history is considered dangerous :)

Even this week, with all the commit activity surrounding the sprints,
I have only had to deal with a push race twice out of 16 patches.
I expect to hit it only very rarely in normal development work.

Alternatively, Ezio at least follows the policy of doing a pull
-u/commit/push in the first branch, and then doing pull -u/merge/push
in the next branch.  You are even less likely to hit a push race by
following that technique, since the time between the pull -u and the
push is minimized.

--
R. David Murray                                      www.bitdance.com