[Python-Dev] PEP 385: pruning/reorganizing branches (original) (raw)

Dirkjan Ochtman dirkjan at ochtman.nl
Tue Aug 4 08:33:49 CEST 2009

On Tue, Aug 4, 2009 at 08:06, "Martin v. Löwis"<martin at v.loewis.de> wrote:

I use that as a branch to tell build slaves to clean out their current checkouts. So keep-clone sounds right, assuming it is possible to target buildslaves at either clones or branches (which, IIUC, would be necessary anyway, since we are using a mix of branches and clones).

Yes, that should be straightforward.

amk-mailbox: keep-clone? twouters-dictviews-backport: keep-clone? bcannon-sandboxing: keep-clone? bippolito-newstruct: merges? You'll probably need to explicitly ping the specific owners (Andrew Kuchling, Thomas Wouters, Brett Cannon, Bob Ippolito) to understand the fate of these branches.

Will do.

This also raises the question how developers should publish their "own" branches. For the bzr setup, there was apparently a proposal to use directories for that, i.e. giving each developer a directory on code.python.org to publish branches.

User repositories has apparently worked well for Mozilla, so yeah, it's worth discussing.

Not doing that, but keeping owner information encoded in the clone name, would be fine as well.

release23-branch: merges? r23b2-branch: merges? r22rc1-branch: strip r22b1-branch: merges? r22a4-branch: merges? r22a3-branch: merges? r161-branch: merges? It seems we had been creating CVS branches for every release around that time; I don't remember the details. Each such branch should end up in a tag. For example, release23-branch should (and does) ultimately lead to tags/r23. cvs2svn wasn't able to recognize this correctly (as CVS branches apply to each file individually), so it created the r23 tag out of various copies that were current when the tag was made. I don't know what your plan is wrt. release tags, i.e. whether you want to keep them all. If you are stripping out some of the branches, but plan to keep the release tags, I wonder what the tags look like.

The plan was to keep all maintenance branches and all release tags but not all release branches (since they seem to contain few commits anyway).

release22-branch: merged-r24921 Not really. Jack Jansen merged some changes that got first applied to the 2.2

r22b2-branch: merges? merged-r24426 r22b2-branch: merges? merged-r24426 release20-maint: keep-named See above. So you do plan to keep all past releases? release152p1-patches: merges? Probably merged. I don't recall whether 1.5.2p1 really happened; in r14966, Fred claims that he merged all changes from 1.5.2p2 (!). "Hopefully I got all this right!" I surely hope the same - I doubt anybody would go back and check whether anything is missing.

Thanks for the thorough review,

Dirkjan

More information about the Python-Dev mailing list