On Thu, 2005-04-14 at 01:52, Peter N. Lundblad wrote:
> > If svn_ra_initialize is present in 1.2 then we can require that it be
> > called before any other "new in 1.2" function. Most of the svn_ra_xxx
> > stuff happens to be new in 1.2, we deprecated the vtable approach.
> Yeah, it is cleaner to have an "you must call this function" than "you
> should call this function, but if you don't, it will hopefully work
> anyway". New functionality can rely on this being called in the future.
I'm not quite sure what the value is here. Old code is going to invoke
new RA functions via libsvn_client anyway, without calling
svn_ra_initialize().
> Yes, lack of time. the solution to the --enable-dso problem IMO is to:
> a) not call svn_fs_initialize in the client (the client isn't
> multi-threaded)
> b) remove the FS listing from the svn --version output
> As I pointed out in another thread, I still think we should add
> svn_fs_initialize in 1.2 (since it is ready). There is no reason to not
> make our servers completely thread-safe if we can. And we can.
Okay, I've recreated the 1.2.x-r14063 branch with:
r14063: Cache uuid in memory
r14066: svn_fs_initialize and serialized_init
r14068: Bugfix for r14066 (release mutex on write-lock failure)
r14079: Bugfix for r14066 (memory leak)
r14121: Bugfix for r14066 (missing comment)
r14124: Bugfix for r14066 (multiple init calls, localization)
r14156: mod_dav_svn initialization calls
part of r14067: Add calls to svn_fs_initialize [only svnserve.c]
On trunk, I suspect much of r14067 will need to have svn_fs_initialize
replaced with svn_ra_initialize, and new inclusions of svn_fs.h replaced
with inclusions of svn_ra.h.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 14 20:31:02 2005