[Python-Dev] Backport troubles with mercurial

["Martin v. Löwis"]

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