[python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

[Jesus Cea]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/02/11 17:03, Barry Warsaw wrote:
> Given that this workflow is a social one, encouraged but not imposed by the
> technology, how will we respond when things are done The Wrong Way?  What are
> the effects if someone forgets and commits a patch to trunk first?  Have we
> hosed the branches or is it just a PITA to recover?

The obvious approach would be to use "transplant" to copy the patch to
the "old" clone. If the patch in both places is the same, mercurial
recognize the fact. If they are not, you have a false conflict, to be
resolved in the merge (usually you do this just now, that you have the
details fresh in mind, and if you don't do, somebody has to do it).

Other option is to export the patch from the "new" clone, backout the
patch ("hg backout" command), apply the patch to the "old" clone and
then do a regular merge.

As said, this is a social problem. For instance, if I write a patch to
"new" and do not backport, somebody else can do it "eventually". This is
practical, but you can "forget" or decide you don't want to spend your
time maintaining, let's say, 2.7.*.

But using "up-porting", when somebody does a merge from "old" to "new",
the operation brings all patches from "old". If the patches doesn't
apply cleanly (mercurial merge machinery is clever, but not everything
can be done automatically), the guy doing a merge is going to curse badly.

Ideally, every changeset committed to "old" should be "merged"
inmediatelly to "new", by the patch maker. I don't consider an issue to
be "closed" until this is done.

Not sure if this should be a real rule, but if "old" and "new" reside in
the same repository (for instance, named branches), you can check this
in the push "hook" living in the server. That is, the hook check that
the changesets you are pushing don't create a new head in "old" (your
patch create a head, but your merge "joins" heads in both "old" and
"new". When you push, you push both changesets at the same time, and the
repository is verified and updated atomically).

- -- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTUxFRJlgi5GaxT1NAQJmpAP/bmdgoK4J4O/hS+DNrC59sVxOU0Y5gH4I
gW7SnU/FDejszMeDJ8fi6/3/v4jcV+Mfy9MOSr4lCmfnmXXXUyHoMBL5UEmDvuGR
LNN3QXEKZeNo5op4UQWa1rRp9qjYL95R/dBiVPgGY6Ia+V406fjdgYFXVn331KhY
0qpf5/teZ4c=
=FYnu
-----END PGP SIGNATURE-----