Barry Warsaw writes: > I hear this complaint [about branches being no help in reviewing] a > lot from hg and git users, so maybe it's just the nature of the > tools. In which case, I'm fine with whatever works better for > Python.
First, let me remind you that PEP 374 was quite clear about one thing. "Read my lips: No new workflows!" But this was practicality over purity, not vice versa. That is, the idea was to minimize change to the workflow until the contributors are used to the new VCS. Clearly, not everybody is, yet. So everything below is referring to the medium to long term. >From experience in XEmacs, which uses hg as the VCS for 3 years now but still has a diff | sendmail review process, I would have to agree that for *most* contributions by *most* users having the patch in the change proposal is more convenient than using a separate branch. However, as Michael points out, you can have your tools generate the patch. For example, it shouldn't be too hard to add a dynamic patch generator to Roundup (although I haven't thought about the UI or the CPU burden). So I don't see why branch-based submissions should be *harder* to use than patch-based submissions (in the long run). OTOH, for larger features, which tend to be composites of smaller features, it's often useful to me to have a series of changesets representing each subfeature. Email6, I'm looking at you!<wink> Also for patches that go through several iterations, I *do* sometimes check the logs and individual diffs if available. In a patch-based workflow, it's not unheard of for a contributor to revert desired changes along with undesired ones, and omit restoring them. This is less likely if the code is being developed *in* a branch, and it's easier to detect if you have the branch available when reviewing. Finally, a patch that goes through several iterations tends to gradually acquire cruft in the form of merge conflict resolution as the contributor's clone is updated to trunk tip. These occasionally are suboptimal because the conflicts themselves are evolving. It's sometimes better to resolve all the conflicts at merge to trunk time, and I've never seen it be worse. I think it's up to the advocates of branch-based review to improve the tools, and I think it's worth it. Now, if only I can find some time... _______________________________________________ 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
