Daniel Rall wrote:
> On Wed, 13 Jun 2007, Blair Zajac wrote:
>
>> Daniel Rall wrote:
>>> On Wed, 13 Jun 2007, Blair Zajac wrote:
> ...
>>>> Is there any reason not to save the filesystem type in svn_fs_t and
>>>> add a call to get it? Would this break binary compatibility? Is
>>>> there a good reason not to do this? Where would be the best place
>>>> to make this change?
>>> 'struct svn_fs_t' in subversion/libsvn_fs/fs-loader.h is an opaque
>>> data structure which should really only be allocated by svn_fs_new()
>>> (publicly deprecated, but used internally), svn_fs_open(), or
>>> svn_fs_create().
>>>
>>> Adding a new 'type' field to the structure's definition to cache the
>>> FS type will speed up any repeated calls to the svn_fs_type() API;
>>> sounds fine to me. The majority of the memory used by this would
>>> likely be memory sticking around uncleared in a pool anyhow.
>> What about 1.4.x clients using 1.5.x shared libraries? This shouldn't
>> be a problem?
>
> Because svn_fs_t is an opaque data structure, it shouldn't be a
> problem so long as the 1.4.x client allocates the svn_fs_t structure,
> directly or indirectly, via svn_fs_new() (which will create the 1.5.x
> version with the new field).
>
> If the 1.4.x client is performing its own allocation of an svn_fs_t,
> I'm not sure what happens. But, it shouldn't be doing this anyways.
Thanks Daniel.
What should we call this new function, since svn_fs_type is already
taken? svn_fs_backend_type? I wouldn't want to use svn_fs_fs_type
since that sounds like an fsfs related function.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 14 17:09:46 2007