On Thu, 30 Dec 2010 14:42:48 +0900, "Stephen J. Turnbull" <stephen@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