[Python-Dev] Mercurial migration: progress report (PEP 385)

Georg Brandl g.brandl at gmx.net
Sun Jul 5 13:17:31 CEST 2009


Martin v. Löwis schrieb:
>> It will handle it, for sure, but I think it would all go easier if we
>> could work with stricter subset branches (and leave the effective
>> cherrypicking for the occasional problem).
> 
> So I think the PEP should propose a workflow (or: merge flow) if you
> think we would be better off with a different one.
> 
> In proposing such a workflow, consider these requirements:
> - we current have four active "maintenance" branches (i.e. where
>   the entire code basis evolves): trunk, 3k, 2.6, and 3.1 (3.0
>   also until this morning).

It seems that there is a consensus to separate the 2.x and 3.x repos,
and that also makes sense to me.

Using named branches for the maintenance branches should be possible,
but I'm not opposed to using cloned branches either.  What I really
want to see is the common-subset approach for maintenance branches.

Changesets still have to be transplanted from 2.x to 3.x or the other
way round.

> - in addition, we have two security branches currently: 2.4 and
>   2.5, although 2.4 will be closed soon.
> - our committers consistently refuse to merge changes across
>   branches themselves, and likely continue to do so unless there
>   is some feature of hg that I missed (e.g. one were merging
>   would happen without any user specifically asking for it)

If the checkin is done in the proper (the maint) branch, at least merging
of that change is automatic whenever someone does a hg merge.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



More information about the Python-Dev mailing list