On 06/14/2012 11:46 PM, Julian Foad wrote:
> Stefan Fuhrmann wrote:
>
>> Yesterday, I discovered an inconsistency in our log API.
>> svn_revnum_t is a long while the "limit" parameter is
>> an int.
> It is not semantically necessary to be able to request an arbitrarily large batch of log messages -- in other words, for the "limit" parameter to be the same as, or as big as, svn_revnum_t.
On some systems, limit is 32 bits while svn_revnum_t is 64 bits.
>> Since we have a practical limit of 2^31 on our revision
>> numbers
> Just curious: can you easily point to the source(s) of this practical limit? I'm not particularly surprised, but I wasn't aware of it.
E.g. subversion/libsvn_repos/log.c: do_logs() will count the
revisions sent as int and compare that to limit (if > 0).
Also, the apr_array_t has an int element counter. We probably
use that in various places as well.
>> and because int is (at least) 32 bits on all our
>> targets, switching the limit parameter to long is a pretty
>> much a mere formality.
>>
>> The fix ripples through all ra layers and such blowing
>> the patch up to more then 700 lines. So, I think it is
>> simply not worth it.
> So I agree that it's not worth changing, for both your reason and mine.
Once we have revprop packing, it should be feasible to create
a minimal repository with >2G revisions (~100GB disc space
when using ntfs compression) and see what happens ...
-- Stefan^2.
Received on 2012-06-15 12:27:35 CEST