On Mon, Aug 3, 2009 at 23:06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
> empty: keep-clone?

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).

> amk-mailbox: keep-clone?
> twouters-dictviews-backport: keep-clone?
> bcannon-sandboxing: keep-clone?
> bippolito-newstruct: merges?

keep-clone bcannon-objcap, strip bcannon-sandboxing.


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.

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.

Yeah, I thought I brought this up and people liked the idea of keeping some user directory on hg.python.org. I am fine with code.python.org as well. But having some place would be really handy (although having bitbucket and Google Code makes this not quite as important).

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.

> 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.