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

Re: Cannot determine fs type from svn_fs_t

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-06-14 17:09:29 CEST

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.


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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.