So PEP 385 proposes to clean up the old branches we still have lying around in SVN. This list of branch: action items is what I've come up with to do this cleanup. Legend first: - keep-clone means we'll keep that branch in a separate clone - keep-named means we'll keep that branch as a named branch in one of the clones - strip means we won't keep that branch - streamed-merge means that it got merged by committing several new revisions to the other branch - merged-r* means the branch got merged in the named revision - merges? means I haven't checked/found out yet whether that branch was ever merged - ? means that your input would be even more helpful than for the other items - some items have no action yet, feel free to treat that as just '?' The actual List: py3k: keep-clone default: keep-clone tk_and_idle_maintenance: keep-clone release26-maint: keep-named release30-maint: keep-named pep-0383: keep-clone py3k-short-float-repr: strip streamed-merge multiprocessing-autoconf: keep-clone? release25-maint: keep-named io-c: keep-clone? py3k-issue1717: keep-clone tlee-ast-optimize: keep-clone release24-maint: keep-named empty: keep-clone? py3k-urllib: keep-clone tnelson-trunk-bsddb-47-upgrade: strip benjaminp-testing: strip py3k-importlib: keep-clone release23-maint: keep-named py3k-importhook: keep-clone ctypes-branch: strip decimal-branch: merged-r58143 bcannon-objcap: keep-clone? p3yk_no_args_on_exc: strip amk-mailbox: keep-clone? twouters-dictviews-backport: keep-clone? bcannon-sandboxing: keep-clone? release22-maint: keep-named theller_modulefinder: strip hoxworth-stdlib_logging-soc: strip partial tim-exc_sanity: merged-r46426 IDLE-syntax-branch: merged-r41480 strip-later ast-objects: strip ast-arena: merged-r41739 jim-doctest: strip ast-branch: merged-r39758 release23-branch: merges? jim-modulator: strip release21-maint: keep-named indexing-cleanup-branch: strip r23c1-branch: merged-r33637 r23b2-branch: merges? anthony-parser-branch: merged-r35460 r23b1-branch: merged-r32490 idlefork-merge-branch: strip getargs_mask_mods: strip cache-attr-branch: strip folding-reimpl-branch: strip streamed-merge r23a2-branch: merges? bsddb-bsddb3-schizo-branch: merged-r31008 r23a1-branch: merged-r30482 py-cvs-vendor-branch: strip DS_RPC_BRANCH: strip streamed-merge SourceForge: strip release22-branch: merged-r24921 r22rc1-branch: strip r22b2-branch: merges? merged-r24426 r22b1-branch: merges? r22a4-branch: merges? r22a3-branch: merges? r22a2-branch: merged-r22674 descr-branch: merged-r22139 release20-maint: keep-named gen-branch: merged-r21181 iter-branch: merged-r20492 r161-branch: merges? cnri-16-start: strip universal-33: merges? None: strip avendor: strip Distutils_0_1_3-branch: strip partial release152p1-patches: merges? string_methods: merged-r13927 PYIDE: strip OSAM: strip PYTHONSCRIPT: strip BBPY: strip jar: merges? alpha100: strip streamed-merge unlabeled-2.36.4: strip partial unlabeled-2.1.4: strip partial unlabeled-2.25.4: strip partial fix-test-ftplib: merged-r66673 trunk-math: py3k-grandrenaming: okkoto-sizeof py3k-ctypes-pep3118: merged-r62597 trunk-bytearray: merged-r61936 libffi3-branch: merged-r61234 alex-py3k: strip cpy_merge: strip py3k-pep3137: merged-r58888 ../ctypes-branch: strip pep302_phase2: strip py3k-buffer: merged-r57181 p3yk-noslice py3k-struni p3yk: rename int_unification unlabeled-1.1.1: strip unlabeled-1.5.4: strip unlabeled-1.1.2: strip unlabeled-2.9.2: strip unlabeled-2.9.4: strip unlabeled-1.5.2: strip unlabeled-2.1.2: strip unlabeled-2.36.2: strip unlabeled-2.108.2: strip unlabeled-2.10.2: strip unlabeled-2.54.2: strip unlabeled-1.3.2: strip unlabeled-1.23.4: strip unlabeled-2.25.2: strip unlabeled-1.2.2: strip unlabeled-1.98.2: strip unlabeled-2.16.2: strip unlabeled-2.3.2: strip unlabeled-1.9.2: strip unlabeled-1.8.2: strip aimacintyre-sf1454481: merged-r46919 tim-current_frames: merged-r50541 bippolito-newstruct: merges? runar-longslice-branch: strip steve-notracing: strip rjones-funccall: merged-r46096 sreifschneider-newnewexcept: merged-r46456 tim-doctest-branch: merged-r36839 blais-bytebuf: strip ../bippolito-newstruct: rename rjones-prealloc: strip sreifschneider-64ints: strip stdlib-cleanup: strip ssize_t: merged-r42382 sqlite-integration: merged-r43514 tim-obmalloc: merged-r43059 Further actions: - implement branch map support in hgsubversion to be able to do named/unnamed/no branch on a branch-by-branch basis - implement splice map support in hgsubversion to be able to convert given merges to hg-native merge data Cheers, Dirkjan
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?
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. 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
On Tue, Aug 4, 2009 at 08:06, "Martin v. Löwis"<martin@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
Dirkjan Ochtman wrote:
On Tue, Aug 4, 2009 at 08:06, "Martin v. Löwis"<martin@v.loewis.de> wrote:
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).
I think I share Martin's confusion here - how can you keep a release tag (e.g. 2.2.2) without also keeping the release branch where that tag was created? Yes, the maintenance branches contain a comparatively small number of commits, but they're still the sources of the maintenance release tags. Or is this a case where Mercurial's DAG allows you to handle those old branches as "abandoned" leaves of the DAG in the history of the affected files, with the tags picking out the relevant versions of the files? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
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.
Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
Comments on some of the branches I've had involvement with... On Mon, Aug 3, 2009 at 11:51 AM, Dirkjan Ochtman<dirkjan@ochtman.nl> wrote:
py3k-short-float-repr: strip streamed-merge
Sounds fine.
py3k-issue1717: keep-clone
I don't think there's any need to keep this branch; its contents were all merged (in pieces) to py3k (various revisions with numbers in the range 69188--69225). So I think 'strip streamed-merge' is appropriate here, if I'm understanding your terminology.
trunk-math:
I think this one can go down as 'strip', too; there's nothing there of interest that isn't already in trunk and py3k. It was merged to trunk in r62380. -- Mark
On Mon, Aug 03, 2009 at 12:51:36PM +0200, Dirkjan Ochtman wrote:
amk-mailbox: keep-clone?
strip -- this branch was for working on a fix for http://bugs.python.org/issue1599254, but the actual work in the branch is available as the patches attached to that item. --amk
participants (8)
-
"Martin v. Löwis" -
A.M. Kuchling -
Amaury Forgeot d'Arc -
Brett Cannon -
Dirkjan Ochtman -
Mark Dickinson -
Nick Coghlan -
Robert Schuppenies