[Python-Dev] hg conversion: tags
tseaver at palladion.com
Wed Sep 29 14:32:24 CEST 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 09/29/2010 08:16 AM, Nick Coghlan wrote:
> On Wed, Sep 29, 2010 at 6:29 PM, M.-A. Lemburg <mal at egenix.com> 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 ?
> 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
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.
>> 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,
> 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.
+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 Seaver +1 540-429-0999 tseaver at 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/
-----END PGP SIGNATURE-----
More information about the Python-Dev