Re: CVS update: MODIFIED: libsvn_fs ...

On Wed, May 09, 2001 at 09:22:57PM -0000, kfogel@tigris.org wrote:
>...
> +++ strings-table.c 2001/05/09 21:22:57 1.3
> @@ -45,27 +45,110 @@
>
> struct string_baton
> {
> + svn_fs_t *fs; /* Which filesystem should we look in? */
> const char *key; /* Which string in the `strings' table? */
> u_int32_t offset; /* Where are we in the string? */
> - svn_boolean_t append; /* True iff we should append to the string. */
> + trail_t *trail; /* The database trail to work in. */
> };

More on that offset in a bit...

>...
> +svn_error_t *
> +svn_fs__string_size (apr_size_t *size,
> + svn_fs_t *fs,
> + const char *key,
> + trail_t *trail)
> +{
>...
> + /* kff todo: how can we know this cast is safe? */
> + *size = (apr_size_t) result.size;

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.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org