[Python-Dev] Backport troubles with mercurial (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Thu Dec 30 19:31:46 CET 2010

Am 30.12.2010 18:54, schrieb Stephen J. Turnbull:

R. David Murray writes:

> I thought Amaury was saying it was harder than svnmerge, not harder > than patching by hand (ie: that it was patching by hand, including > .rej files and the lack of tracking). I also heard Georg say that this > should be fixable, and that he's partly fixed the tracking issue, I don't see why the tracking issue is any different than it would be for svn. If you're actually merging, either a dummy merge (what git calls an "ours merge") or reverting unwanted patches will "block" them, and hg will keep track of the ones that have been merged.

Are you still talking about merges from 3.x to 2.7? Then I don't think what you say is actually true. hg will not be able to track the ones that get merged, and will not be able to block by means of dummy merges.

Perhaps we aren't "actually" merging, I suppose.

If you're actually cherry-picking, then you have to keep a separate database of the patches that have been picked and those that are blocked, but this has been done successfully for years with svnmerge, right?

[Ok. So "cherry-picking" is not a special case of "merging", or "actually merging", I presume]

Wrong. For subversion, merge tracking is built into the tools that we use for merging (i.e. svnmerge). For hg (IIUC), the standard procedure that people use for merging (or "cherry-picking") apparently does not track what has been merged (or "cherry-picked").

> Well, considering that the transition is "soon", the fact that it > is a SMOP is a concern :)

Sure, but in this crowd, I wouldn't waste a good worry on this particular SMOP.

Given how little enthusiasm this crowd has in actually helping the migration, I doubt they show any enthusiasm in writing such tools.

> Well, there will be some workflow change since we're talking about > committing to 3.2 maint before the new trunk instead of vice versa. > But you are right that that is, mostly, a detail.

AFAIK that's not hg-driven, though.

It is. So far, we have always merged from the development branch to the maintenance branch (i.e. "backported"), although there has been opposition from a number of committers to this workflow in recent years.

I personally consider this more appropriate: with backporting, you can defer decision to backport until the original change has been confirmed as correct. With constant forward-porting, you risk breaking your maintenance branch with incorrect changes.

> I'm not as convinced that changes in workflow will be that minimal, > though. I don't have much experience with the dvcses yet, but what > experience I have had leads me to think that understanding the DAG is > a non-trivial and necessary mental leap and does affect the workflow. But using the adapted workflow simply requires learning new names for old operations. Annoying, but it will make a fair number of core devs quite happy.

I think the new workflow will simply result in (even) less care for the maintenance branches than currently. Some people just refuse to patch multiple branches, and will continue to do so. While it was previously possible to backport, it won't be that easy anymore in the future, so it just won't be done.

This actually reduces workload, but also reduces quality.

Regards, Martin

More information about the Python-Dev mailing list