[Python-Dev] PEP 385: pruning/reorganizing branches (original) (raw)
Brett Cannon brett at python.org
Tue Aug 4 21:28:10 CEST 2009
- Previous message: [Python-Dev] PEP 385: pruning/reorganizing branches
- Next message: [Python-Dev] PEP 385: pruning/reorganizing branches
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Aug 3, 2009 at 23:06, "Martin v. Löwis" <martin at 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. Regards, Martin
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20090804/b0643d44/attachment-0001.htm>
- Previous message: [Python-Dev] PEP 385: pruning/reorganizing branches
- Next message: [Python-Dev] PEP 385: pruning/reorganizing branches
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]