Hi all, I've recently been working on the conversion more (since my thesis got finished). I finally wrote the script that splits the release branches from the feature branches, so that we can include the former in the main repository and keep the latter in separate clones as needed. Next, I wanted to look into tags. There's a big list of tags (see below), and I wonder if I should clean that up or if we should leave it as-is. For example, it might be interesting to bring old release tags in line with newer tags (so Release_1_0 would become r10), or maybe use clean tags similar to what we do with hg itself (r266 would become just 2.6.6), or just remove some tags. Is this a good idea at all, or should we just leave everything the way it is now? Cheers, Dirkjan r32a2 r266 r266rc2 r266rc1 r32a1 r27 r27rc2 r27rc1 r27b2 r27b1 r312 r265 r265rc2 r312rc1 r27a4 r265rc1 r27a3 r255 r255c2 r255c1 r27a2 r27a1 r311 r264 r264rc2 r264rc1 r263 r263rc1 r311rc1 r31 r31rc2 r31rc1 r31b1 r262 r262c1 r31a2 r31a1 r301 r254 r253 r246 r253c1 r246c1 r261 r30 r30rc3 r30rc2 r26 r26rc2 r30rc1 r26rc1 r30b3 r26b3 r26b2 r30b2 r26b1 r30b1 r26a3 r30a5 r26a2 r30a4 r237 r245 r237c1 r245c1 r30a3 r26a1 r252 r252c1 r251c1 r30a2 r30a1 py3k-before-rstdocs py26-before-rstdocs r251 r236 r236c1 r244 r244c1 r25 r25c2 r25c1 r25b3 r25b2 r25b1 r25a2 r25a1 r25a0 r243 r25a0/trunk r243c1 before-ast-merge-to-head mrg_to_ast-branch_15OCT05 IDLE-syntax-root r242 r242c1 email_Release_2_5_6 r241 r241c2 r241c1 r235 r235c1 merged_from_MAIN_07JAN05 mrg_to_ast-branch_05JAN05 pre-sf-818006 bsddb_version_4_3_0 release24-fork r24 r24c1 r24b2 r24b1 r24a3 tim-doctest-closed r24a2 tim-doctest-merge-24a2 r24a1 pre-sf-1149508 r234 email_Release_2_5_5 r234c1 start-sf-965425 before-ast-merge-from-head bsddb_version_4_2_4 r233 r233c1 r232 r232c1 r231 pybsddb_after_bsddb42_01 pybsddb_before_bsddb42 r23-mac r23 release23-fork r23c2 r23rc1-fork r23c1 bsddb_version_4_1_6 r23b2 r23b2-fork anthony-parser-branchpoint IDLELIB_CREATED r09b1 r223 email_Release_2_5_3 r223c1 email_Release_2_5_2 r23b1-mac r23b1 r23b1-fork COPY_TO_PYTHON mrg_to_ast-branch_24APR03 email_Release_2_5_1 cache-attr-fork email_Release_2_5 r09a2nt email_Release_2_5b1 r23a2 r23a2-fork r09a2 LAST_OLD_IDLE r09a1 r23a1 r23a1-fork r09a0 before-bgen-pep252 r222-mac r222 email_Release_2_4_3 email_Release_2_4_2 Distutils-1_0_3 r222b1 email_Release_2_4_1 email_Release_2_4 py-cvs-2002_09_13-merged py-cvs-2002_09_13 MERGED_FROM_DS_RPC_13SEP02 MERGED_TO_MAIN_13SEP02 PRE_DS_RPC_MERGE email_Release_2_3_1 email_Release_2_3 BEFORE_RESTART email_Release_2_2 email_Release_2_1 final_classic_builds email_Release_2_0_5 Release_2_0_4 TAG_pre_teyc_gvr_rpc_patch r221 r213 r22p1 r221c2 r221c1 r1_95_2 r212 r212c1 release22-mac release22-macmerge release22 release22-fork r22c1-mac r22c1-macmergefromtrunk r22c1 r22rc1-fork final_CW6_projects universal_headers_332 v0_10 r22b2-mac r22b2 r22b2-fork v0_09 r22b1-mac v0_08 v0_07 v0_06 r22b1 r22b1-fork r22b1-docs-prep r22a4 r22a4-fork r22a3 r22a3-fork r22a3-docs-prep r22a2 r22a2-docs-prep r22a2-fork before-carbon-package after-descr-branch-merge date2001-08-01 date2001-07-30 date2001-07-28 IDLEFORK_081_RELEASE date2001-07-21 r211 r22a1 date2001-07-17b date2001-07-17a date2001-07-16 date2001-07-15 py-cvs-2001_07_13-merged py-cvs-2001_07_13 py-cvs-rel2_1-merged date2001-07-13 r211c1 py-cvs-rel2_1 py-cvs-2000_03_09 descr-fork date2001-07-06 base-VP-idle r201 r201c1 merged-with-main-repository after-call-reorg before-call-reorg mac210 Distutils-1_0_2 release21 r21c2 r21c1 mac210b2 r21b2 mac210b1a mac210b1 r21b1 mac210a3 r161 mac210a1 r21a2 r21a1 pre_amk last_cw_pro_53 mac200 release20 Distutils-1_0_1 r20c1 Distutils-1_0 Distutils-0_9_4 r20b2 Distutils-0_9_3 r20b11 mac200b1 r20b1 release16 Distutils-0_9_2 last_68k_projects cw_pro_5 Distutils-0_9_1 arelease r16b1 r16b1-win Distutils-0_9 Distutils-0_8_2 Distutils-0_8_1 Distutils-0_8 r16a2 Distutils-0_1_5 pre_GUSI2 Distutils-0_1_4 Distutils-0_1_3-branch r16a1 release152p2 release152p1-branch-tag pre-unicode idle05 pre_0_2_breakage Distutils-0_1_3 Distutils-0_1_2 Distutils-0_1_1 Distutils-0_1 mx_builder-alpha2 release152p1 pre-string-meths Release_1_0 release152 r152 mac152c1 r152c1 r06 release152b2 r152b2 mac152b1 release152b1 idle-r02 r152b1 Release_0_1 r01 r152a2 Public_Release_20-Aug-1998 PYIDE_APR98 PYTHONSCRIPT_0_5b1 OSAM_APR98 BBPY_0_2_3 release152a1 r152a1 release151p1 mac151 r151 Public_Release_27-Mar-1998 Public_13-Mar-1998 Public_11-Mar-1998 release15 r15b2 r15b1 r15a4 r15a4near r15a3 r15a2 r15a1 lastoldnames lastoldname release14 Python1_4final r14beta3 Beta_20-Aug-1996 r14beta2 Beta_09-Aug-1996 Beta_05-Jul-1996 r14beta1 cwisync1 cnrisync2 chameleon-1 cnrisync release13 r13beta1 Public_05-Jul-1995 release12 proof3 r12beta4 Python_1_2_release Beta_20-Mar-1995 proof2 Beta_15-Mar-1995-#2 Beta_15-Mar-1995 Beta_14-Mar-1995-#3 Beta_14-Mar-1995-#2 Beta_14-Mar-1995 proof1 r12beta3 r12beta2 r12beta1 release111 release11 mhammond mac102 release102 release101 release100 last099 release099 release098 pre_jh
Removing tags sounds fine with me. Renaming them not so; I fail to see the point.
before-ast-merge-to-head mrg_to_ast-branch_15OCT05
These could go, IMO. Anything that's there for merge maintenance can go, IMO.
IDLE-syntax-root
This one can go as well. In general, I propose to remove all tags which aren't copies of trunk or some branch (i.e. tagging only a part of the Python source tree). I suppose hg can't represent that adequately, anyway (they often come from CVS, and even CVS can only barely represent tags that cover only one or a few files). Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/26/2010 07:40 AM, "Martin v. Löwis" wrote:
One point is to remove inconsistencies tied to CVS-era restrictions: the tags which correspond to (define) actual numbered releases have goofy names due to CVSism ('r266' is a ridiculously hard-to-figure-out alternative to '2.6.6'). Given that nobody will be able to update checkouts in place anyway, I think taking this opportunity to use "real" version IDs for tags would be a much better than sticking with the old cruft. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyfXj4ACgkQ+gerLs4ltQ6fZQCeJIQzz4CO9D/Jc1ryeO9zhiUA /EcAn3IkPDOpJetd9kC6/gqpNqN8JHkC =0roB -----END PGP SIGNATURE-----
Please understand that this will also delay the introduction of Mercurial. Not only will the tag names have to be changed, but also all software doing automatic processing of tag names will have to be updated (in addition to being ported to Mercurial, which is necessary either way). But then, if somebody volunteers to make these changes, I'm -0 to the renaming (I slightly prefer calling even future release tags rXYZ). Regards, Martin
On 9/26/2010 12:54 PM, "Martin v. Löwis" wrote:
But then, if somebody volunteers to make these changes, I'm -0 to the renaming (I slightly prefer calling even future release tags rXYZ).
Except that r311 could be either 3.1.1 or 3.11 (should be ever get that far ;-). -- Terry Jan Reedy
Am 26.09.2010 12:55, schrieb Dirkjan Ochtman:
I'd remove as many tags as makes sense, only keeping the release tags. Most others were made to quickly go back to a version before some change happened; however nobody would want to go back there anymore now. Just like my *-before-rstdocs tags, which I guess nobody ever used. As for how to call the releases, while I'd prefer a bit less cryptic names, keeping the rXYZ convention is fine with me. 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.
On Sep 27, 2010, at 04:52 PM, Georg Brandl wrote:
We're still going to keep the Subversion repository in read-only even after the conversion. Will the mapping between svn and hg revision numbers be preserved somehow? If so, then I say in hg, nuke the tags we don't care about and sanitize the release tags to something that obvious and can't collide (e.g. r311 is 3.1.1 or 3.11? - yes despite Guido's Rule of Version Numbering). I'd personally be fine using the hexversion or even "3.1.1" as the tag name. Since we're going to live with the converted repository until the Next Big Thing In Version Control <wink>, let's take the opportunity now to clean things up and make them nice. I do think we should keep a mapping from new to old though. If that's not possible within the hg repository, can we at least generate a text file or some such and commit that? -Barry
On Mon, Sep 27, 2010 at 17:28, Barry Warsaw <barry@python.org> wrote:
I'm planning an extension so that at least the web interface will take r432432 and give you the corresponding hg changeset (if available!). Those who want it will also be able to install it in their local clones. Cheers, Dirkjan
Okay, so let's summarize this thread so far: Martin is in favor of removing some tags (certainly partial ones), but is -0 on renaming them. Tres is in favor of renaming release tags. Georg advocates removing non-release tags, and doesn't care much about renaming. Barry would like to clean up release tag names (either dotted or hexversion). Alexander is +1 on renaming tags on the premise that "r311" tags conflict with "r42543" SVN rev notation. Antoine is in favor of renaming tags on the premise that using hg log -rr311 is awkward in comparison to -r3.1.1. So it seems like most people here like the idea of renaming the tags. Martin and Georg would also like to get rid of some of the non-release tags, but it's unclear if we should get rid of all non-release tags or just the partial ones. Below is a grouped list. Based on that list, I propose the following scheme: - keep all "normal" release tags, renamed along these lines: r27 -> 2.7 r266 -> 2.6.6 r27rc2 -> 2.7rc2 r262c1 -> 2.6.2rc1 (rc and c should be normalized into the same thing, don't care which one) r30b3 -> 3.0b3 release22 -> 2.2 - keep Mac release tags that don't have the top-level Mac dir, renamed along these lines: r23b1-mac -> 2.3b1-mac - get rid of "special" release tags and Mac release tags with top-level Mac dir - get rid of email and distutils tags - get rid of all other tags Does that make sense? Cheers, Dirkjan ========================================== "Normal" release tags: r32a2 r266 r266rc2 r266rc1 r32a1 r27 r27rc2 r27rc1 r27b2 r27b1 r312 r265 r265rc2 r312rc1 r27a4 r265rc1 r27a3 r255 r255c2 r255c1 r27a2 r27a1 r311 r264 r264rc2 r264rc1 r263 r263rc1 r311rc1 r31 r31rc2 r31rc1 r31b1 r262 r262c1 r31a2 r31a1 r301 r254 r253 r246 r253c1 r246c1 r261 r30 r30rc3 r30rc2 r26 r26rc2 r30rc1 r26rc1 r30b3 r26b3 r26b2 r30b2 r26b1 r30b1 r26a3 r30a5 r26a2 r30a4 r237 r245 r237c1 r245c1 r30a3 r26a1 r252 r252c1 r251c1 r30a2 r30a1 r251 r236 r236c1 r244 r244c1 r25 r25c2 r25c1 r25b3 r25b2 r25b1 r25a2 r25a1 r25a0 r243 r243c1 r242 r242c1 r241 r241c2 r241c1 r235 r235c1 r24 r24c1 r24b2 r24b1 r24a3 r24a2 r24a1 r234 r234c1 r233 r233c1 r232 r232c1 r231 r23 r23c2 r23c1 r23b2 r09b1 r223 r223c1 r23b1 r23a2 r09a2 r09a1 r23a1 r09a0 r222 r222b1 r221 r213 r22p1 r221c2 r221c1 r212 r212c1 r22c1 r22b2 r22b1 r22a4 r22a3 r22a2 r211 r22a1 r211c1 r201 r201c1 r21c2 r21c1 r21b2 r21b1 r161 r21a2 r21a1 r20c1 r20b2 r20b11 r20b1 r16b1 r16a2 r16a1 r152 r152c1 r06 r152b2 r152b1 r01 r152a2 r152a1 r151 r15b2 r15b1 r15a4 r15a3 r15a2 r15a1 r14beta3 r14beta2 r14beta1 r13beta1 r12beta4 r12beta3 r12beta2 r12beta1 release22 release21 release20 release16 release15 release14 release13 release12 release111 release11 release102 release101 release100 release099 release098 "Special" release tags: release152p1-branch-tag r09a2nt r16b1-win r15a4near r22b1-docs-prep r22a3-docs-prep r22a2-docs-prep r23a1-fork r23rc1-fork r23b2-fork r23b1-fork r23a2-fork r22b2-fork r22rc1-fork r22a2-fork r22b1-fork r22a4-fork r22a3-fork release24-fork release23-fork release22-fork release152p2 (docs only) release152p1 (docs only) release152 (docs only) release152b2 (docs only) release152b1 (docs only) release152a1 (docs only) release151p1 (docs only) Mac releases: r23b1-mac r222-mac r23-mac r22c1-mac r22b2-mac r22b1-mac release22-mac mac102 r22c1-macmergefromtrunk (Mac dir) release22-macmerge (Mac dir) mac152c1 (Mac dir) mac152b1 (Mac dir) mac151 (Mac dir) mac210 (Mac dir) mac210b2 (Mac dir) mac210b1a (Mac dir) mac210b1 (Mac dir) mac210a3 (Mac dir) mac210a1 (Mac dir) mac200 (Mac dir) mac200b1 (Mac dir) distutils tags (distutils only): Distutils-1_0_3 Distutils-1_0_2 Distutils-1_0_1 Distutils-1_0 Distutils-0_9_4 Distutils-0_9_3 Distutils-0_9_2 Distutils-0_9_1 Distutils-0_9 Distutils-0_8_2 Distutils-0_8_1 Distutils-0_8 Distutils-0_1_5 Distutils-0_1_4 Distutils-0_1_3-branch Distutils-0_1_3 Distutils-0_1_2 Distutils-0_1_1 Distutils-0_1 email tags (email only): email_Release_2_5_6 email_Release_2_5_5 email_Release_2_5_3 email_Release_2_5_2 email_Release_2_5_1 email_Release_2_5 email_Release_2_5b1 email_Release_2_4_3 email_Release_2_4_2 email_Release_2_4_1 email_Release_2_4 email_Release_2_3_1 email_Release_2_3 email_Release_2_2 email_Release_2_1 Release_2_0_4 email_Release_2_0_5 Other tags: r25a0/trunk py3k-before-rstdocs py26-before-rstdocs before-ast-merge-to-head mrg_to_ast-branch_15OCT05 IDLE-syntax-root merged_from_MAIN_07JAN05 mrg_to_ast-branch_05JAN05 pre-sf-818006 bsddb_version_4_3_0 tim-doctest-closed tim-doctest-merge-24a2 pre-sf-1149508 start-sf-965425 before-ast-merge-from-head bsddb_version_4_2_4 pybsddb_after_bsddb42_01 pybsddb_before_bsddb42 bsddb_version_4_1_6 anthony-parser-branchpoint IDLELIB_CREATED COPY_TO_PYTHON mrg_to_ast-branch_24APR03 cache-attr-fork LAST_OLD_IDLE before-bgen-pep252 py-cvs-2002_09_13-merged py-cvs-2002_09_13 MERGED_FROM_DS_RPC_13SEP02 MERGED_TO_MAIN_13SEP02 PRE_DS_RPC_MERGE BEFORE_RESTART final_classic_builds TAG_pre_teyc_gvr_rpc_patch final_CW6_projects universal_headers_332 before-carbon-package after-descr-branch-merge date2001-08-01 date2001-07-30 date2001-07-28 IDLEFORK_081_RELEASE date2001-07-21 date2001-07-17b date2001-07-17a date2001-07-16 date2001-07-15 py-cvs-2001_07_13-merged py-cvs-2001_07_13 py-cvs-rel2_1-merged date2001-07-13 py-cvs-rel2_1 py-cvs-2000_03_09 descr-fork date2001-07-06 base-VP-idle merged-with-main-repository after-call-reorg before-call-reorg pre_amk last_cw_pro_53 last_68k_projects cw_pro_5 arelease pre_GUSI2 pre-unicode idle05 pre_0_2_breakage mx_builder-alpha2 pre-string-meths idle-r02 PYIDE_APR98 PYTHONSCRIPT_0_5b1 OSAM_APR98 BBPY_0_2_3 lastoldnames lastoldname cwisync1 cnrisync2 chameleon-1 cnrisync proof3 proof2 proof1 mhammond last099 pre_jh v0_10 (docs only) v0_09 (docs only) v0_08 (docs only) v0_07 (docs only) v0_06 (docs only) Public_Release_20-Aug-1998 (one file only) Public_Release_27-Mar-1998 (one file only) Public_13-Mar-1998 (one file only) Public_11-Mar-1998 (one file only) Beta_20-Aug-1996 (one file only) Beta_09-Aug-1996 (one file only) Beta_05-Jul-1996 (one file only) Beta_15-Mar-1995-#2 (one file only) Beta_15-Mar-1995 (one file only) Beta_14-Mar-1995-#3 (one file only) Beta_14-Mar-1995-#2 (one file only) Beta_14-Mar-1995 (one file only) Beta_20-Mar-1995 (one file only) Public_05-Jul-1995 (one file only) Release_1_0 (one file only) Release_0_1 (one file only) Python_1_2_release (one file only) Python1_4final (one file only) r1_95_2 (partial)
Dirkjan Ochtman wrote:
I'm not sure whether throwing away history in form of such tags is a good idea. I don't know how hg manages this, but can't we preserve the tag information of the tags that you've scheduled to be removed in some place that can easily be pulled in but doesn't affect the main repo size ? Renaming the release tags certainly is a good idea, since we're not stuck with CVS naming requirements anymore. I'd prefix the release tags with "release-" for additional context, though. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 29 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, Sep 29, 2010 at 6:29 PM, M.-A. Lemburg <mal@egenix.com> wrote:
But why bother? The tags are static, so grabbing them from svn instead of hg shouldn't be a big issue. If we had unlimited resources to support the transition my opinion would probably be different, but since we don't, applying the simple rule of culling the non-release tags seems good enough and better than spending too much time trying to figure out which tags are "important" enough to be worth preserving.
So long as we don't start using bare numbers for anything other than releases, I think that would just become redundant typing in fairly short order. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/29/2010 08:16 AM, Nick Coghlan wrote:
I think the key heuristic is which information you want to use directly in Hg, e.g. to diff between tags, or diff a working branch against a tag. Based on how I use tags under SVN, the release tags account for nearly all of such cases. Having to go back to SVN to check out the rare exception seems like a good tradeoff.
+1 for bare release numbers (Dirkjan's proposal). Although I would prefer 'c' over 'rc' in the normalized case, PEP 386 allows 'rc' as an alternative to 'c' precisely because some Python versions used it). I think we need to make the migrated version tags match the corresponding tarball version numbers exactly. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyjMdgACgkQ+gerLs4ltQ4Y1ACfeIK6KtO7RAZyzcSp5ap2/Zn6 bH8AnjQGRFjrI7PaisUcSex3nsFp4AR/ =f8ZR -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/29/2010 08:38 AM, Benjamin Peterson wrote:
2010/9/29 Tres Seaver <tseaver@palladion.com>:
Right. I meant to indicate that we should map any 'rc' in the historical release tarball name onto 'rc' in the new Hg tag. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyjOVsACgkQ+gerLs4ltQ4r9wCfYKYhfPTn/At4zqBuGCqYIwPf uQUAoNPsbKLkSDPflITveyBQ+VE24Tnl =vBUr -----END PGP SIGNATURE-----
Nick Coghlan wrote:
You don't need to spend any extra time on this: just put all the tags that Dirkjan wants to delete into some other place. The separation work has already been done by Dirkjan. Note that the reason for keeping this history around is just that: for historic purposes and possible future research (e.g on copyright issues). It's not meant for development.
That's a Perl argument ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 29 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, Sep 29, 2010 at 9:36 AM, M.-A. Lemburg <mal@egenix.com> wrote:
Can just create a .hgtags_historic that has the full tag list so if someone wants to do historic tag data mining they can just replace the .hgtags to get the historic tags. mm that gives me an idea for a HG plugin to be able to set a tag as historic so it removes it from the .hgtags to .hgtags_historic and some bindings to be able to use historic tags just like normal tags (but ensure it is explicit to look in historic eg --historic)
Most certainly, and this is the plan already: we will keep the subversion repository data "forever". If you want the CVS repository from the day when it was converted to subversion, you can still get it from http://svn.python.org/snapshots/python-cvsroot-final.tar.bz2 (Created 27-Oct-2005 04:34, FWIW, so we are close to 5 years into subversion usage. Given that the "public" usage of the CVS started in 2000, we should start to look into the hg successor around 2013, for a switchover in Oktober 2015 :-). Regards, Martin
"Martin v. Löwis" wrote:
Fair enough.
Good idea :-) I suppose we'll have CVCSes by then - cloud version control systems. Let's reserve cloud number 9 for use by Python (cumulonimbus is too hard to remember) :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 30 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Sep 29, 2010, at 10:15 AM, Dirkjan Ochtman wrote:
+1
Personally, I prefer 'c' to keep things regular.
r30b3 -> 3.0b3 release22 -> 2.2
+1
+0
+0. If distutils-sig needs those tags, keep 'em. Similarly with email-sig, but being more involved with the separate email package releases, I don't think they'll be necessary. We're not going to diff against any earlier release and we have an email6 repository in Bazaar on Launchpad. When we integrate that back into Python, it'll likely be an undiffable change so I see no reason to keep the old tags (we can decide later if we'll want new tags in the main Python repo).
- get rid of all other tags
+1. We'll always have the Subversion repository for the historical record. It'll make future mining a bit more difficult, but not insurmountably so and I'd rather plan for the benefit of future developers than the convenience of future archaeologists. -Barry
Removing tags sounds fine with me. Renaming them not so; I fail to see the point.
before-ast-merge-to-head mrg_to_ast-branch_15OCT05
These could go, IMO. Anything that's there for merge maintenance can go, IMO.
IDLE-syntax-root
This one can go as well. In general, I propose to remove all tags which aren't copies of trunk or some branch (i.e. tagging only a part of the Python source tree). I suppose hg can't represent that adequately, anyway (they often come from CVS, and even CVS can only barely represent tags that cover only one or a few files). Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/26/2010 07:40 AM, "Martin v. Löwis" wrote:
One point is to remove inconsistencies tied to CVS-era restrictions: the tags which correspond to (define) actual numbered releases have goofy names due to CVSism ('r266' is a ridiculously hard-to-figure-out alternative to '2.6.6'). Given that nobody will be able to update checkouts in place anyway, I think taking this opportunity to use "real" version IDs for tags would be a much better than sticking with the old cruft. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyfXj4ACgkQ+gerLs4ltQ6fZQCeJIQzz4CO9D/Jc1ryeO9zhiUA /EcAn3IkPDOpJetd9kC6/gqpNqN8JHkC =0roB -----END PGP SIGNATURE-----
Please understand that this will also delay the introduction of Mercurial. Not only will the tag names have to be changed, but also all software doing automatic processing of tag names will have to be updated (in addition to being ported to Mercurial, which is necessary either way). But then, if somebody volunteers to make these changes, I'm -0 to the renaming (I slightly prefer calling even future release tags rXYZ). Regards, Martin
On 9/26/2010 12:54 PM, "Martin v. Löwis" wrote:
But then, if somebody volunteers to make these changes, I'm -0 to the renaming (I slightly prefer calling even future release tags rXYZ).
Except that r311 could be either 3.1.1 or 3.11 (should be ever get that far ;-). -- Terry Jan Reedy
Am 26.09.2010 12:55, schrieb Dirkjan Ochtman:
I'd remove as many tags as makes sense, only keeping the release tags. Most others were made to quickly go back to a version before some change happened; however nobody would want to go back there anymore now. Just like my *-before-rstdocs tags, which I guess nobody ever used. As for how to call the releases, while I'd prefer a bit less cryptic names, keeping the rXYZ convention is fine with me. 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.
On Sep 27, 2010, at 04:52 PM, Georg Brandl wrote:
We're still going to keep the Subversion repository in read-only even after the conversion. Will the mapping between svn and hg revision numbers be preserved somehow? If so, then I say in hg, nuke the tags we don't care about and sanitize the release tags to something that obvious and can't collide (e.g. r311 is 3.1.1 or 3.11? - yes despite Guido's Rule of Version Numbering). I'd personally be fine using the hexversion or even "3.1.1" as the tag name. Since we're going to live with the converted repository until the Next Big Thing In Version Control <wink>, let's take the opportunity now to clean things up and make them nice. I do think we should keep a mapping from new to old though. If that's not possible within the hg repository, can we at least generate a text file or some such and commit that? -Barry
On Mon, Sep 27, 2010 at 17:28, Barry Warsaw <barry@python.org> wrote:
I'm planning an extension so that at least the web interface will take r432432 and give you the corresponding hg changeset (if available!). Those who want it will also be able to install it in their local clones. Cheers, Dirkjan
Okay, so let's summarize this thread so far: Martin is in favor of removing some tags (certainly partial ones), but is -0 on renaming them. Tres is in favor of renaming release tags. Georg advocates removing non-release tags, and doesn't care much about renaming. Barry would like to clean up release tag names (either dotted or hexversion). Alexander is +1 on renaming tags on the premise that "r311" tags conflict with "r42543" SVN rev notation. Antoine is in favor of renaming tags on the premise that using hg log -rr311 is awkward in comparison to -r3.1.1. So it seems like most people here like the idea of renaming the tags. Martin and Georg would also like to get rid of some of the non-release tags, but it's unclear if we should get rid of all non-release tags or just the partial ones. Below is a grouped list. Based on that list, I propose the following scheme: - keep all "normal" release tags, renamed along these lines: r27 -> 2.7 r266 -> 2.6.6 r27rc2 -> 2.7rc2 r262c1 -> 2.6.2rc1 (rc and c should be normalized into the same thing, don't care which one) r30b3 -> 3.0b3 release22 -> 2.2 - keep Mac release tags that don't have the top-level Mac dir, renamed along these lines: r23b1-mac -> 2.3b1-mac - get rid of "special" release tags and Mac release tags with top-level Mac dir - get rid of email and distutils tags - get rid of all other tags Does that make sense? Cheers, Dirkjan ========================================== "Normal" release tags: r32a2 r266 r266rc2 r266rc1 r32a1 r27 r27rc2 r27rc1 r27b2 r27b1 r312 r265 r265rc2 r312rc1 r27a4 r265rc1 r27a3 r255 r255c2 r255c1 r27a2 r27a1 r311 r264 r264rc2 r264rc1 r263 r263rc1 r311rc1 r31 r31rc2 r31rc1 r31b1 r262 r262c1 r31a2 r31a1 r301 r254 r253 r246 r253c1 r246c1 r261 r30 r30rc3 r30rc2 r26 r26rc2 r30rc1 r26rc1 r30b3 r26b3 r26b2 r30b2 r26b1 r30b1 r26a3 r30a5 r26a2 r30a4 r237 r245 r237c1 r245c1 r30a3 r26a1 r252 r252c1 r251c1 r30a2 r30a1 r251 r236 r236c1 r244 r244c1 r25 r25c2 r25c1 r25b3 r25b2 r25b1 r25a2 r25a1 r25a0 r243 r243c1 r242 r242c1 r241 r241c2 r241c1 r235 r235c1 r24 r24c1 r24b2 r24b1 r24a3 r24a2 r24a1 r234 r234c1 r233 r233c1 r232 r232c1 r231 r23 r23c2 r23c1 r23b2 r09b1 r223 r223c1 r23b1 r23a2 r09a2 r09a1 r23a1 r09a0 r222 r222b1 r221 r213 r22p1 r221c2 r221c1 r212 r212c1 r22c1 r22b2 r22b1 r22a4 r22a3 r22a2 r211 r22a1 r211c1 r201 r201c1 r21c2 r21c1 r21b2 r21b1 r161 r21a2 r21a1 r20c1 r20b2 r20b11 r20b1 r16b1 r16a2 r16a1 r152 r152c1 r06 r152b2 r152b1 r01 r152a2 r152a1 r151 r15b2 r15b1 r15a4 r15a3 r15a2 r15a1 r14beta3 r14beta2 r14beta1 r13beta1 r12beta4 r12beta3 r12beta2 r12beta1 release22 release21 release20 release16 release15 release14 release13 release12 release111 release11 release102 release101 release100 release099 release098 "Special" release tags: release152p1-branch-tag r09a2nt r16b1-win r15a4near r22b1-docs-prep r22a3-docs-prep r22a2-docs-prep r23a1-fork r23rc1-fork r23b2-fork r23b1-fork r23a2-fork r22b2-fork r22rc1-fork r22a2-fork r22b1-fork r22a4-fork r22a3-fork release24-fork release23-fork release22-fork release152p2 (docs only) release152p1 (docs only) release152 (docs only) release152b2 (docs only) release152b1 (docs only) release152a1 (docs only) release151p1 (docs only) Mac releases: r23b1-mac r222-mac r23-mac r22c1-mac r22b2-mac r22b1-mac release22-mac mac102 r22c1-macmergefromtrunk (Mac dir) release22-macmerge (Mac dir) mac152c1 (Mac dir) mac152b1 (Mac dir) mac151 (Mac dir) mac210 (Mac dir) mac210b2 (Mac dir) mac210b1a (Mac dir) mac210b1 (Mac dir) mac210a3 (Mac dir) mac210a1 (Mac dir) mac200 (Mac dir) mac200b1 (Mac dir) distutils tags (distutils only): Distutils-1_0_3 Distutils-1_0_2 Distutils-1_0_1 Distutils-1_0 Distutils-0_9_4 Distutils-0_9_3 Distutils-0_9_2 Distutils-0_9_1 Distutils-0_9 Distutils-0_8_2 Distutils-0_8_1 Distutils-0_8 Distutils-0_1_5 Distutils-0_1_4 Distutils-0_1_3-branch Distutils-0_1_3 Distutils-0_1_2 Distutils-0_1_1 Distutils-0_1 email tags (email only): email_Release_2_5_6 email_Release_2_5_5 email_Release_2_5_3 email_Release_2_5_2 email_Release_2_5_1 email_Release_2_5 email_Release_2_5b1 email_Release_2_4_3 email_Release_2_4_2 email_Release_2_4_1 email_Release_2_4 email_Release_2_3_1 email_Release_2_3 email_Release_2_2 email_Release_2_1 Release_2_0_4 email_Release_2_0_5 Other tags: r25a0/trunk py3k-before-rstdocs py26-before-rstdocs before-ast-merge-to-head mrg_to_ast-branch_15OCT05 IDLE-syntax-root merged_from_MAIN_07JAN05 mrg_to_ast-branch_05JAN05 pre-sf-818006 bsddb_version_4_3_0 tim-doctest-closed tim-doctest-merge-24a2 pre-sf-1149508 start-sf-965425 before-ast-merge-from-head bsddb_version_4_2_4 pybsddb_after_bsddb42_01 pybsddb_before_bsddb42 bsddb_version_4_1_6 anthony-parser-branchpoint IDLELIB_CREATED COPY_TO_PYTHON mrg_to_ast-branch_24APR03 cache-attr-fork LAST_OLD_IDLE before-bgen-pep252 py-cvs-2002_09_13-merged py-cvs-2002_09_13 MERGED_FROM_DS_RPC_13SEP02 MERGED_TO_MAIN_13SEP02 PRE_DS_RPC_MERGE BEFORE_RESTART final_classic_builds TAG_pre_teyc_gvr_rpc_patch final_CW6_projects universal_headers_332 before-carbon-package after-descr-branch-merge date2001-08-01 date2001-07-30 date2001-07-28 IDLEFORK_081_RELEASE date2001-07-21 date2001-07-17b date2001-07-17a date2001-07-16 date2001-07-15 py-cvs-2001_07_13-merged py-cvs-2001_07_13 py-cvs-rel2_1-merged date2001-07-13 py-cvs-rel2_1 py-cvs-2000_03_09 descr-fork date2001-07-06 base-VP-idle merged-with-main-repository after-call-reorg before-call-reorg pre_amk last_cw_pro_53 last_68k_projects cw_pro_5 arelease pre_GUSI2 pre-unicode idle05 pre_0_2_breakage mx_builder-alpha2 pre-string-meths idle-r02 PYIDE_APR98 PYTHONSCRIPT_0_5b1 OSAM_APR98 BBPY_0_2_3 lastoldnames lastoldname cwisync1 cnrisync2 chameleon-1 cnrisync proof3 proof2 proof1 mhammond last099 pre_jh v0_10 (docs only) v0_09 (docs only) v0_08 (docs only) v0_07 (docs only) v0_06 (docs only) Public_Release_20-Aug-1998 (one file only) Public_Release_27-Mar-1998 (one file only) Public_13-Mar-1998 (one file only) Public_11-Mar-1998 (one file only) Beta_20-Aug-1996 (one file only) Beta_09-Aug-1996 (one file only) Beta_05-Jul-1996 (one file only) Beta_15-Mar-1995-#2 (one file only) Beta_15-Mar-1995 (one file only) Beta_14-Mar-1995-#3 (one file only) Beta_14-Mar-1995-#2 (one file only) Beta_14-Mar-1995 (one file only) Beta_20-Mar-1995 (one file only) Public_05-Jul-1995 (one file only) Release_1_0 (one file only) Release_0_1 (one file only) Python_1_2_release (one file only) Python1_4final (one file only) r1_95_2 (partial)
Dirkjan Ochtman wrote:
I'm not sure whether throwing away history in form of such tags is a good idea. I don't know how hg manages this, but can't we preserve the tag information of the tags that you've scheduled to be removed in some place that can easily be pulled in but doesn't affect the main repo size ? Renaming the release tags certainly is a good idea, since we're not stuck with CVS naming requirements anymore. I'd prefix the release tags with "release-" for additional context, though. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 29 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, Sep 29, 2010 at 6:29 PM, M.-A. Lemburg <mal@egenix.com> wrote:
But why bother? The tags are static, so grabbing them from svn instead of hg shouldn't be a big issue. If we had unlimited resources to support the transition my opinion would probably be different, but since we don't, applying the simple rule of culling the non-release tags seems good enough and better than spending too much time trying to figure out which tags are "important" enough to be worth preserving.
So long as we don't start using bare numbers for anything other than releases, I think that would just become redundant typing in fairly short order. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/29/2010 08:16 AM, Nick Coghlan wrote:
I think the key heuristic is which information you want to use directly in Hg, e.g. to diff between tags, or diff a working branch against a tag. Based on how I use tags under SVN, the release tags account for nearly all of such cases. Having to go back to SVN to check out the rare exception seems like a good tradeoff.
+1 for bare release numbers (Dirkjan's proposal). Although I would prefer 'c' over 'rc' in the normalized case, PEP 386 allows 'rc' as an alternative to 'c' precisely because some Python versions used it). I think we need to make the migrated version tags match the corresponding tarball version numbers exactly. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyjMdgACgkQ+gerLs4ltQ4Y1ACfeIK6KtO7RAZyzcSp5ap2/Zn6 bH8AnjQGRFjrI7PaisUcSex3nsFp4AR/ =f8ZR -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/29/2010 08:38 AM, Benjamin Peterson wrote:
2010/9/29 Tres Seaver <tseaver@palladion.com>:
Right. I meant to indicate that we should map any 'rc' in the historical release tarball name onto 'rc' in the new Hg tag. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyjOVsACgkQ+gerLs4ltQ4r9wCfYKYhfPTn/At4zqBuGCqYIwPf uQUAoNPsbKLkSDPflITveyBQ+VE24Tnl =vBUr -----END PGP SIGNATURE-----
Nick Coghlan wrote:
You don't need to spend any extra time on this: just put all the tags that Dirkjan wants to delete into some other place. The separation work has already been done by Dirkjan. Note that the reason for keeping this history around is just that: for historic purposes and possible future research (e.g on copyright issues). It's not meant for development.
That's a Perl argument ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 29 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, Sep 29, 2010 at 9:36 AM, M.-A. Lemburg <mal@egenix.com> wrote:
Can just create a .hgtags_historic that has the full tag list so if someone wants to do historic tag data mining they can just replace the .hgtags to get the historic tags. mm that gives me an idea for a HG plugin to be able to set a tag as historic so it removes it from the .hgtags to .hgtags_historic and some bindings to be able to use historic tags just like normal tags (but ensure it is explicit to look in historic eg --historic)
Most certainly, and this is the plan already: we will keep the subversion repository data "forever". If you want the CVS repository from the day when it was converted to subversion, you can still get it from http://svn.python.org/snapshots/python-cvsroot-final.tar.bz2 (Created 27-Oct-2005 04:34, FWIW, so we are close to 5 years into subversion usage. Given that the "public" usage of the CVS started in 2000, we should start to look into the hg successor around 2013, for a switchover in Oktober 2015 :-). Regards, Martin
"Martin v. Löwis" wrote:
Fair enough.
Good idea :-) I suppose we'll have CVCSes by then - cloud version control systems. Let's reserve cloud number 9 for use by Python (cumulonimbus is too hard to remember) :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 30 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Sep 29, 2010, at 10:15 AM, Dirkjan Ochtman wrote:
+1
Personally, I prefer 'c' to keep things regular.
r30b3 -> 3.0b3 release22 -> 2.2
+1
+0
+0. If distutils-sig needs those tags, keep 'em. Similarly with email-sig, but being more involved with the separate email package releases, I don't think they'll be necessary. We're not going to diff against any earlier release and we have an email6 repository in Bazaar on Launchpad. When we integrate that back into Python, it'll likely be an undiffable change so I see no reason to keep the old tags (we can decide later if we'll want new tags in the main Python repo).
- get rid of all other tags
+1. We'll always have the Subversion repository for the historical record. It'll make future mining a bit more difficult, but not insurmountably so and I'd rather plan for the benefit of future developers than the convenience of future archaeologists. -Barry
participants (13)
-
"Martin v. Löwis" -
Alexander Belopolsky -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Dirkjan Ochtman -
Dj Gilcrease -
Georg Brandl -
M.-A. Lemburg -
Nick Coghlan -
Terry Reedy -
Tres Seaver