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

R. David Murray rdmurray at bitdance.com
Thu Dec 30 08:50:46 CET 2010

On Thu, 30 Dec 2010 14:42:48 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

R. David Murray writes:

> We merge bug fixes to 2.7 on a routine basis. It is the rule rather > than the exception, by a long shot. For bugfixes, of course it's routine. I understand that. My point was that the case Amaury fears, where the (new) VCS makes things harder than patching or porting by hand, is likely to be relatively uncommon, sandwiched between the "typo fixed in comment" conflicts (aka "trivial tweaks") and those that require reengineering.

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, but not the patch/merge issue (and that doing so will require a change in the hg core).

Also, while workflow helpers will make a big difference to the non-VCS-geeks (ie, almost all Python developers), properly speaking this isn't really an issue with Mercurial, because all of the methods for this purpose are basically "diff | patch", although the executables are called things like "svn" and "python". They all demand workflow helper scripts to regulate the flow of desired and undesired patches. The difference is that the tool for hg is a SMOP, while that for svn is a SMOEP[1].

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

> So, since we are going to be maintaining 2.7 for a while, this is > a workflow problem that we must solve to make the hg transition > worthwhile. I have no doubt that we will, but I also have no doubt we > need to solve it, not just wave our hands.

Certainly. I think I already said that, no? My point is simply that

Ah, I guess I did miss that, sorry.

while Amaury's expression of his requirements is welcome, and his experimenting with hg is extremely valuable, indeed a necessary part of the transition, everything he describes so far is a known problem that we basically know how to solve. He talks about changes to the workflow, but frankly, I don't see a need for that.[2]

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.

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. I don't feel as though I've made that leap yet. Hopefully Brett will be able to document this in the Python context so that the required leap will be much smaller.

IMO, changes to the workflow will be driven by kaizen, not by some brave new world revolution (Guido inter alia insisted on that) nor by thumb-in-dike disaster recovery (PEP 374 did a pretty good job on that, if I do say so myself).

Well, I hope you are right. I'm looking forward to the new version of the test repository and doing some real world experiments.

I wish I had more time to do real work on this (not to mention email, thank you, David!), but it seems like every time I start

You are welcome; thanks for the feedback. (I sometimes feel like I'm working in a bit of a vacuum, though Barry does chime in occasionally...but I do realize that people are busy; that's why I inherited this job in the first place, after all :)

-- R. David Murray www.bitdance.com

More information about the Python-Dev mailing list