[python-committers] Pulling from contributors repositories

[Ned Deily]

In article <BANLkTi=qjoi=2bBbBv-zdT8hx3Jqa+PisQ at mail.gmail.com>,
 Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sun, Jun 12, 2011 at 9:59 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> >> Until mercurial has better tools to bundle multiple changesets into a
> >> single coherent group of changes, it's still preferable to do the
> >> export/import dance.
> > Why did we migrate to Mercurial, then?
> The merge tools are still better and keeping out-of-tree branches up
> to date is significantly easier. The fact that bringing external
> changes *in* to the tree still requires going through the patch
> process as it did with SVN is just an artefact of our desire to keep
> the history of the central repo relatively clean and python-checkins
> at least somewhat readable.

It seems to me that we are making life overly difficult for ourselves in 
at least one respect: the updating of the NEWS and ACKS files.  Because 
most revisions are modifying one or both of these files, you are almost 
guaranteed to have a merge conflict and often multiple merge conflicts, 
since both files differ from branch to branch.

There are several ways we could eliminate this needless pain.  Probably 
the simplest would be to agree on a simple format for including the NEWS 
and ACK info in the hg commit message and then agree on a process to 
batch update the NEWS and ACK files from the commit messages prior to 
each release.   Commit messages today often duplicate the NEWS file 
entry anyway.  What's missing is a way to identify which section of the 
NEWS file to add the message to and a standard form to identify an ACK.   
I'm sure we could come up with something simple that would be acceptable 
and that would cover merges (i.e. like duplicating the commit message on 
a merge).

For pulling changes from another repo where the commit messages were not 
in the proper format, either a separate change to capture the NEWS could 
be pushed.  Or, prior to pushing a set of related repo patches, one 
could use Mercurial Queues to "edit" the commit messages.  hg 
conveniently maps commit messages to patch header comments.  So you 
should be able to pop each revision as a patch (hg qimport -r tip; hg 
qpop) then edit each patch header/commit message (hg qpush; hg qrefresh 
-e ; hg qfinish) prior to pushing to the main repo.  (That will, of 
course, result in new revision ids and new history and cannot be done 
once the revisions are "in the wild".)

Even if the batch updates were totally manual, I think a couple of hours 
once a release would be a worthy tradeoff if it helped to lower the 
barrier for getting fixes in.

-- 
 Ned Deily,
 nad at acm.org