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.
