On Thu, 30 Dec 2010 14:42:48 +0900, "Stephen J. Turnbull" <step...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
