BCP for patch submittal

[Patrick Mézard]

Micah Cowan a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> I would like to provide a small how-to for people to understand how to
> pull down our Mercurial repository, do some development, and submit a
> patch for their changes, but it's not entirely clear to me the best way
> to do this for changes that involved more than one (local) commit, but
> are not large enough to make patch submittal cumbersome.
> 
> Except for cumbersomely large changes (in which case, patches or even
> compressed-changeset submittal may not be the way to go), I'd prefer
> that patches be sent to a mailing list set up for that purpose, and that
> they be human-readable (IOW, not bundles).

The patchbomb extension was updated a couple of month ago to do exactly 
what you describe, see 
http://www.selenic.com/mercurial/wiki/index.cgi/PatchbombExtension and 
--outgoing.

> I could recommend that people do their work, and when they're done, use
> "hg export tip", but of course this doesn't cover multi-commit changes
> against the core repo. I could recommend that they first create a local
> tag after cloning the core repo, and then do an "hg export tag:tip",
> which would be an improvement, but would also clutter the patch with any
> changes that happened in the trunk in the meantime, that they pulled
> down before preparing patches.

I do not really understand the last sentence. I you expect developers to 
merge their changes with upstream while developing, I am not sure this 
is compatible with an email base submission process (at least without 
MQ), you do not want to see merge changesets in submissions. So, I 
suppose that submissions are made of linear sequence of changesets. In 
this case, selecting the ones belonging to you and the others is 
trivial, and export will do the job nicely. But it will be someone else 
job to merge the submissions back in upstream (either by importing them 
with --exact and merging, or rebasing them on tip)

Now, if the patch submission process is part of a review process and the 
submitter may be asked to change things in its patch, I do not really 
see how you would avoid using MQ.

--
Patrick Mézard