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

["Martin v. Löwis"]

Am 03.02.2011 00:16, schrieb Barry Warsaw:
> On Feb 03, 2011, at 08:54 AM, Nick Coghlan wrote:
> 
>> I suspect this problem with the preferred DVCS workflow is going to
>> cut fairly heavily into the number of bug fixes applied to the
>> maintenance branches.
> 
> I'd be really surprised if it *has* to be that way.  Just how painful is it in
> Mercurial to apply to newest branch first and back port?

IIUC, you lose tracking if you let patches flow in the opposite
direction (i.e. in the way it is currently).

With the new workflow, you can do "hg pull release32-maint" any time
in the trunk, and it will integrate all pending patches. You don't
have to specify any revision number there; it will just pick all
missing changes from the maintenance branch and integrate them into
the trunk.

If you let patches flow in the other direction, I understand you
lose all support from hg wrt. history tracking. There may be ways
to still do this through Mercurial commands (instead of generating
a patch and manually applying it), but the backported patch will
be different from the patch in the trunk, since it will have different
parent versions (IIUC, the command is called "transplant").

I don't know whether hg keeps track of what patches have been
transplanted, but I doubt it.

In any case, this discussion reiterates my point that this
project (Mercurial migration) really needs a project lead,
who then will also pronounce on usage policies. Otherwise,
it's doomed to fail.

Regards,
Martin