Greg Stein <gstein@lyra.org> writes:
> What we need to do is create svn_fs_filesize_t. Ideally, it would be the
> same as apr_off_t.
>
> If we stick to apr_size_t, then our files are limited to 2 or 4 gig,
> depending on where the bugs are :-). I don't believe that we necessarily
> want to be so limiting. Note that even if Berkeley has a max record size of
> 4 gig, I think we want the "core" of svn_fs to understand larger files and
> punt IFF we attempt to cram them into Berkeley DB.
>
> We can certainly define svn_fs_filesize_t as apr_size_t for now, if that
> makes (current) sense. But having the defined type means that we can tweak
> it later on to "up" the file size maximum.
>
> The "offset" field would be svn_fs_filesize_t, or for the purists, yet
> another type called svn_fs_fileoffset_t.
>
> A number of parameter types (beyond just svn_fs__string_size) will change as
> a result of propagating this new type.
This would mean changes in a lot of code, not just in strings-table.c.
It might be worth it later, but I think we should put it off for now;
no one actually has a 5-gig file they want to check in yet, nor will
they until Subversion is known to work on smaller files. :-)
The principle of avoiding arbitrary limits is great, but not
all-powerful. The benefit/cost ratio for this change isn't very high
(yet), imho.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:30 2006