[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: MODIFIED: libsvn_fs ...

From: Karl Fogel <kfogel_at_collab.net>
Date: 2001-05-10 17:33:31 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.