> On Sat, 2004-10-09 at 20:48, Philip Martin wrote:
> > On the 1.0.x branch r10357 uses a non-public symbol from libsvn_subr,
> > namely svn_config__enumerate_sections, and that symbol is not present
> > on the 1.1.x branch. If an third-party application did this we would
> > claim that it was breaking the rules and could not expect such a
> > symbol to be present in 1.1.x. Is mod_authz_svn allowed to get away
> > with it because it is part of Subversion? If so we need to explain to
> > distributers that they need to ensure that the 1.1.x libraries
> > conflict with the 1.0.x modules.
>
> The logic we applied (at my urging) is that we should feel free to use
> internal symbols between libraries when necessary, because we have no
> reason to expect that users won't have a matched set of libraries and no
> reason to want to make that work. We didn't consider the logistical
> issue that people might upgrade the libraries without upgrading the
> httpd modules. (Or downgrade them, within a particular x.y line.)
>
> I tend to believe that if someone misses the httpd modules in an upgrade
> or downgrade, it was probably by mistake, and it's almost better that we
> catch the mistake than not (though an obscure linking error is not the
> best way to do so). But perhaps we should consider the httpd modules to
> be like applications, and make them follow the strict rules as if they
> were external programs.
Packagers have started to package mod_dav_svn as 'the Apache extension which
turns your Apache into a Subversion server'. Not as integral part of
Subversion packages, but more or less as a separate option.
In IRC I saw people upgrade to svn 1.1 and after discovering the perf hit
explicitly downgrading just mod_dav_svn. Obviously they don't think of it
as intergral part of Subversion. Which seems logical the way it is
currently being packaged.
> Another reason not to have this class of Subversion-private (but not
> library-private) symbols is that it means we can't use platform-specific
> mechanisms for protecting the library symbol namespace. So perhaps we
> should wean ourselves of the practice, although it does give us a lot of
> latitude at times.
Might help to prevent future problems, although we'd be making things hard
on ourselves...
bye,
Erik.
--
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 10 19:27:48 2004