You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2005/04/13 20:54:53 UTC
[PATCH] Add svn_ra_initialize
Hi,
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?
Regards,
//Peter
Re: [PATCH] Add svn_ra_initialize
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Peter N. Lundblad wrote:
>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.
>
>
+1
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add svn_ra_initialize
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 14 Apr 2005, Greg Hudson wrote:
> 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().
>
Good point. We'll have to live with the "should call" thing then. I'll
withdraw it from STATUS.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add svn_ra_initialize
Posted by Greg Hudson <gh...@MIT.EDU>.
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
Re: [PATCH] Add svn_ra_initialize
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 14 Apr 2005, Philip Martin wrote:
> kfogel@collab.net writes:
>
> > "Peter N. Lundblad" <pe...@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
Re: [PATCH] Add svn_ra_initialize
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> "Peter N. Lundblad" <pe...@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.
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.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add svn_ra_initialize
Posted by kf...@collab.net.
"Peter N. Lundblad" <pe...@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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org