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