[Python-ideas] Using only patches for pulling changes in hg.python.org

[Daniel Stutzbach]

On Mon, Jul 5, 2010 at 3:11 PM, Brett Cannon <brett at python.org> wrote:

> The switch to hg has never been about tweaking the
> workflow of committers, but that of contributors.
>

I've always thought of it as tweaking the workflow of collaboration.

As an individual contributor and non-committer, the server switch isn't
going to impact my workflow much.  I use a DVCS locally to manage my work
and then I submit a patch on the bug tracker.  After the server switch, I'll
do the same.

A DVCS server will help a lot when I'm collaborating on a patch with others.

As a concrete example, a few months ago I wrote a patch to speed up
math.factorial (issue8692).  Alexander Belopolsky and Mark Dickinson found a
few corner-case flaws, suggested code-cleanup improvements, and some
algorithmic alternatives.  We went back and forth with several variations of
patches before settling on a final patch.

When Python is natively hosted in Mercurial, then the tools can explicitly
track the relationship between all of the experimental patches.  When just
pushing patch files around, it's pretty hard to see that
factorial-precompute-partials.patch is based on factorial-no-recursion.patch
if you haven't been following the issue closely.  It's also hard to examine
the incremental changes between the two, which makes it hard to review an
updated patch after reviewing the original.  All of that would be a lot
easier if I had started my patch as a clone of py3k on bitbucket.

At the end of the process, the final committer can consolidate the changes
into a single patch to keep the core repository clean.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100706/b83c417c/attachment.html>