On Tue, 12 Apr 2005, Greg Hudson wrote:
> The FSFS locking fix comes in three logical parts:
>
...
> (3) Add the svn_fs_initialize() API and calls to it. If it is not
> used, libsvn_fs makes a best-effort fallback which (a) leaks a
> little heap memory if the svn libraries are unloaded, and (b)
> could, if one is very unlucky, fail to serialize accesses to the
> write lock.
>
> The third part is proving troublesome; client programs like the "svn"
> command-line client need to invoke it in case they use ra_local, but
> they may not be linked against libsvn_fs if --enable-dso is used. The
> solution will involve adding an svn_ra_initialize() for client
> programs to use, and that will take some time and a little design
> work.
>
For the record, I'm working on svn_ra_initialize. I'm fine with letting it
slip into 1.3 if people think that's a good idea. I still want to add the
API in 1.2, so we can require it for the new RA APIs. The call has the
same signature as fs_initialize:
svn_error_t *svn_ra_initialize (apr_pool_t *pool);
with the same requirements regarding being called single-threadedly and
that the pool shall live as long as the RA library is being used.
Note that we also need to solve the svn_fs_print_modules problem. One
possible solution is to just revert that printing from the svn client and
svnversion. (svnadmin and friends can keep it since they use the FS
libraries directly.)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 22:01:29 2005