removed support for long

Sune Foldager cryo at cyanite.org
Mon May 21 06:38:59 CDT 2012


On 2012-05-18 11:23, Matt Mackall wrote:
>On Fri, 2012-05-18 at 15:16 +0200, Sune Foldager wrote:
>> In the changeset
>>
>> changeset:   16376:d3908c911d5e
>> user:        Matt Mackall <mpm at selenic.com>
>> date:        Sun Apr 08 12:38:07 2012 -0500
>> summary:     context: internalize lookup logic
>>
>> There is, apart from the internalization, this change:
>>
>> -        if isinstance(changeid, (long, int)):
>> +
>> +        if isinstance(changeid, int):
>>
>> (in changectx.__init__ which is called from repo.__getitem__)
>>
>> So you can no longer pass in longs (and thus also not numbers above
>> 2G), even though it would work at the next stage, in revlog.node. Is
>> there a particular reason for this change?
>
>No, not really. Just an oversight of the rewrite.
>
>But I also can't really see any reason why we should ever use longs as
>revision references. You definitely won't ever be able to use Mercurial
>with 2 billion commits on a 32-bit machine. I suspect the upper limit is
>around 16 million.

Right, but there is also no reason that a long (which may contain 100, say), shouldn't work. In general I think we should avoid testing for exact types like that, and when we have to, should try to make it work "broadly".

>> I ask because hgtk (the old client) uses repo[long(rev)] (for reasons unknown to me), and I am trying to get it working against hg stable tip.
>
>That's silly, but I suppose we can accommodate it.

Well... I don't know the code and reasons well enough to know if it's silly, but thanks. I'll make a patch to change it back to (int, long).

-Sune


More information about the Mercurial-devel mailing list