In article <BANLkTi=qjoi=2bbbbv-zdt8hx3jqa+p...@mail.gmail.com>, Nick Coghlan <ncogh...@gmail.com> wrote: > On Sun, Jun 12, 2011 at 9:59 PM, "Martin v. Löwis" <mar...@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, n...@acm.org _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
