[Python-Dev] Backport troubles with mercurial

[R. David Murray]

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