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.
- application/pgp-signature attachment: stored
Received on Thu Jun 14 16:59:56 2007