Justin Erenkrantz wrote:
> On Feb 19, 2008 5:33 PM, Eric Gillespie <epg_at_google.com> wrote:
>> All the other replies also seem to be nice-to-haves above and
>> beyond what I provided ;->. I don't disagree with any of them,
>> but I don't think they are reasons not to commit this. Please
>> correct me if I misread the replies.
>
> I believe it should not be committed in its present form as it changes
> a default and forces the user to use an inappropriately named flag to
> get back the current behavior. -- justin
True, it changes a default, but its a weird and confusing behaviour that
shouldn't be default and is really only of interest to people doing
advanced packaging of Subversion (such that various libsvn_fs|ra_foo can
be placed in separate rpms/debs).
As for the name, I think there's sufficient prior use of the term in APR
and HTTPD to justify leaving the option name alone at least until
Subversion 2.x for compatibility's sake. But we should improve the
configure help string for it to say something like:
[[[
Do not link the RA and FS library implementations to the core libraries.
Instead load them at run-time as DSOs/loadable modules using dlopen() or
equivalent.
]]]
Also, using --enable-dso doesn't restore current behaviour:
There are supposed to be two ways of loading ra|fs modules:
1) Normal linking, just like any other library (can be static or dynamic
depending on other build options)
2) DSO a.k.a. dlopen a.k.a. explicit programmatic module loading.
The current default behaviour is to use (1), and then, (and this bit is
wrong and what the patch aims to remove) if the particular ra|fs module
in question was not compiled in the build (e.g. no neon, no bdb), fall
back to trying DSO loading. Now, since the module in question wasn't
built, you have a very strong likelyhood that if it finds any version of
that module to load, it will be one from some older svn installation
which will trigger a compatibility error.
Max.
Received on 2008-02-20 03:40:39 CET