Hi,
If someone has a cpython clone with a clean changeset that fixes a bug or adds a feature, is there any reason not to pull it and push it to the main repo? It would save getting and applying the patch manually.
Regards
Le vendredi 10 juin 2011 à 19:57 +0200, Éric Araujo a écrit :
Hi,
If someone has a cpython clone with a clean changeset that fixes a bug or adds a feature, is there any reason not to pull it and push it to the main repo? It would save getting and applying the patch manually.
You usually want to add a Misc/NEWS message or an ACKS entry, or make a cosmetic change to the patch. (in other words, "there's no such thing as a clean changeset" :-))
Regards
Antoine.
On Sat, Jun 11, 2011 at 4:00 AM, Antoine Pitrou solipsis@pitrou.net wrote:
Le vendredi 10 juin 2011 à 19:57 +0200, Éric Araujo a écrit :
Hi,
If someone has a cpython clone with a clean changeset that fixes a bug or adds a feature, is there any reason not to pull it and push it to the main repo? It would save getting and applying the patch manually.
You usually want to add a Misc/NEWS message or an ACKS entry, or make a cosmetic change to the patch. (in other words, "there's no such thing as a clean changeset" :-))
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.
Cheers, Nick.
On Sun, Jun 12, 2011 at 9:59 PM, "Martin v. Löwis" martin@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's also possible that we should be encouraging greater use of Mercurial Queues [1] and making them an official part of our development process. After all, their stated purpose is to allow changes to be developed incrementally, but only landed in the official history as a single consolidated changeset. Since that's the behaviour we want, we should probably consider using the tool that is designed to provide it.
[1] http://mercurial.selenic.com/wiki/MqExtension
Cheers, Nick.
On Sun, Jun 12, 2011 at 11:03 PM, Nick Coghlan ncoghlan@gmail.com wrote:
Arguably better link: http://mercurial.selenic.com/wiki/MqTutorial
Cheers, Nick.
On Mon, Jun 13, 2011 at 12:01 AM, "Martin v. Löwis" martin@v.loewis.de wrote:
It's also possible that we should be encouraging greater use of Mercurial Queues [1] and making them an official part of our development process.
Can you publish/push a patch queue to a remote repository?
bitbucket certainly lets you maintain a patch as a queue rather than as a separate clone. I ran across it in the context of the Py3k port of the PEP 380 patch: https://bitbucket.org/rndblnch/cpython-pep380/overview
I don't have the personal experience to say how easy patch queues are to share in general (if nothing else, they're designed to be easy to export and import as ordinary patches for distribution that way).
Cheers, Nick.
In article BANLkTi=qjoi=2bBbBv-zdT8hx3Jqa+PisQ@mail.gmail.com, Nick Coghlan ncoghlan@gmail.com wrote:
On Sun, Jun 12, 2011 at 9:59 PM, "Martin v. Löwis" martin@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.
2011/6/12 Ned Deily nad@acm.org:
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.
The problem with this method is that spelling can't be fixed and messages can't be reformatted or expanded.
Another method would be to write a extension for Mercurial which is "smart" about the format of Misc/NEWS and could do the resolution automatically.
Le 12/06/2011 20:01, Benjamin Peterson a écrit :
Another method would be to write a extension for Mercurial which is "smart" about the format of Misc/NEWS and could do the resolution automatically.
Even easier than an extension: a merge tool, i.e. a script that knows how to parse the file and compare three versions of it.
In article 4DF50623.4020707@netwok.org, Éric Araujo merwok@netwok.org wrote:
Le 12/06/2011 20:01, Benjamin Peterson a écrit :
Another method would be to write a extension for Mercurial which is "smart" about the format of Misc/NEWS and could do the resolution automatically.
Even easier than an extension: a merge tool, i.e. a script that knows how to parse the file and compare three versions of it.
Of course a merge tool helps. But merge conflicts do add to the complexity of the process for many people and the current NEWS update policy pretty much ensures there will be conflicts even when the code changes do not cause any conflicts. Why not lower the barrier?
Another, more complicated way would be to use a hook to store each
commit message as a separate file in a Misc/NEWS.d directory. Then the
separate files could be periodically rolled up into the singe NEWS file.
That would allow for post-push editing by the committer.
participants (6)
-
"Martin v. Löwis" -
Antoine Pitrou -
Benjamin Peterson -
Ned Deily -
Nick Coghlan -
Éric Araujo