[Python-Dev] Backport troubles with mercurial
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.
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.
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