[Python-Dev] Hg: inter-branch workflow
Antoine Pitrou
solipsis at pitrou.net
Thu Mar 17 00:20:26 CET 2011
Hello,
> 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".
> (if we look at the tracker, you can see that it is very common for the resolution on different branches to be done at different times)
That's not my experience.
Often, when the resolution on other branches is deferred, it means the
committer has actually forgotten about it.
It doesn't really make sense in practice to defer such resolution: you
want the issue to be fresh in your head when committing patches; you
don't want to have to context-switch everything back into your head,
read the discussion again, try to remember the subtleties, etc. Doing
the different branches at different times makes you lose more of your
time, cumulated, and also increases the risk of doing something wrong.
> As far as I can tell the only benefits to the cross-linking are that it reduces the chance that a patch will be applied to an older branch but not forward ported.
Well, no. The main benefit is ease of merging, by definition ;)
Regards
Antoine.
More information about the Python-Dev
mailing list