On Thu, 14 Apr 2005, Philip Martin wrote:
> kfogel@collab.net writes:
>
> > "Peter N. Lundblad" <peter@famlundblad.se> writes:
> >> Short summary: I'm crazy.
> >>
> >> Longer: I want to add an API to 1.2 that does nothing. That's the
> >> svn_ra_initialize I mentioned in the thread about the fSFS fix. We will
> >> need it in 1.3 to properly support calling svn_fs_initialize from the
> >> client. Would it be accepted into 1.2?
> >
> > Maybe I need the _really_ long version...
> >
> > What's the purpose of putting it into 1.2, when we are allowed to add
> > it in 1.3 anyway?
>
> 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 sure why the patch doesn't implement svn_ra_initialize, just a
> lack of time perhaps? If the --enable-dso problem is considered to be
> sufficiently important to block the release then we have to implement
> something, and it may as well be 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.
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 14 07:47:21 2005