[Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Brett Cannon]

On Thu, Jul 1, 2010 at 15:07, Barry Warsaw <barry at python.org> wrote:
> On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:
>
>>On 1 July 2010 20:58, Brett Cannon <brett at python.org> wrote:
>>> Here is a *really* quick-and-dirty approach for non-committers to
>>> create a patch they can submit. This is not extensively tested so
>>> some other Hg expert should back me up on this before telling anyone
>>> that this is the simplest way. I am also not saying this is how we
>>> will want people to contribute in the long run, but this does work
>>> and matches how svn does things well enough that people shouldn't get
>>> thrown by the details.
>>>
>>> 1. Contributor clones the repo
>>> 2. Contributor makes changes, committing as they go
>>> 3. Contributor runs ``hg outgoing --patch --git > patch.diff``
>>> 4. Committer runs ``hg patch --no-commit patch.diff``
>>> 5. Committer does the usual review->commit thing
>>>
>>> Basically this creates git-style diffs that one can shuttle around. I
>>> think you can also use ``patch -p1`` or git-apply to apply the patch
>>> generated by Mercurial.
>>
>>I'd suggest the patchbomb extension (distributed with Mercurial)
>>
>>hg email --outgoing --to dest at somewhere sends a series of patches to
>>the given email address. This is what the Mercurial developers use
>>(with the to address being the mercurial-dev list). Or maybe better,
>>hg email --outgoing --bundle which sends a binary bundle of all
>>outgoing changesets. You can use --to to send the email to something
>>like roundup (will Roundup extract an attachment from an email and add
>>it to the issue as a file? That would be particularly neat...)
>
> Wouldn't it be cool if we could hook this up to Rietveld?

Don't see why not; it already has Hg support, IIRC.

>
> Other than that, while I sometimes review patches in email, I do not think
> patches in a tracker are the best way to manage these.  A dvcs's biggest
> strength is in branches, so we should use those as much as possible.

As I said, quick-and-dirty. It will take discussion to decide what we
want to ask non-committers to do, weighing cost of complexity of the
approach for people new to DVCS in general and Hg in particular,
resource access such as a publicly accessible place to push repos,
what data format we prefer, etc. I just wanted to give David something
to go to PyOhio with that I know will be simple to explain and will
always work.