Justin Erenkrantz <justin@erenkrantz.com> writes:
> > Sure -- I'm also proposing that they be kept separate. All I meant
> > was, reorganize libsvn_ra_dav/ to have two separate subdirs:
> >
> > libsvn_ra_dav/neon/ <-- for everything currently in libsvn_ra_dav/
> > libsvn_ra_dav/serf/
> >
> > The above change sounds major, but it's pretty trivial to implement.
> > The compile-time switch would determine which subdir gets used.
>
> I guess we have a gap on just how difficult this would be to implement
> in the build system. Are you seeing a short-cut I'm not seeing? The
> build system *could* make that choice at autogen.sh, but I'm not
> seeing an easy way to do it at configure-time because gen_make walks
> all of the dependencies at autogen-time.
No, I don't see a shortcut, I was just asserting that it's trivial
without doing any research to back it up.
(Would you like fries with your brutal honesty, sir?)
Improvising here, but this is roughly what I had in mind for
build.conf:
Index: build.conf
===================================================================
--- build.conf (revision 17541)
+++ build.conf (working copy)
@@ -203,14 +203,22 @@
install = lib
msvc-static = yes
-# Accessing repositories via DAV
-[libsvn_ra_dav]
+# Accessing repositories via DAV, using the Neon HTTP library
+[libsvn_ra_dav/neon]
type = ra-module
-path = subversion/libsvn_ra_dav
-install = dav-lib
+path = subversion/libsvn_ra_dav/neon
+install = dav-neon-lib
libs = libsvn_delta libsvn_subr aprutil apriconv apr neon
msvc-static = yes
+# Accessing repositories via DAV, using the Serf HTTP library
+[libsvn_ra_dav/serf]
+type = ra-module
+path = subversion/libsvn_ra_dav/serf
+install = dav-serf-lib
+libs = libsvn_delta libsvn_subr aprutil apriconv apr serf
+msvc-static = yes
+
# Accessing repositories via SVN
[libsvn_ra_svn]
type = ra-module
Corresponding changes would have to be made for configure.in, which
currently refers to "dav-lib". Am I on a crazy track here, or could
this work?
Basically the idea is: if the user requests DAV support, we have two
ways of satisfying it, either via neon or via serf. If the user
requests DAV support generically, we decide which is the default. If
the user requests exactly one of those two libs, we know they want DAV
support *and* we know how. If the user requests both libs, we error
at configure time -- because we don't support loading them
simultaneously.
I'm not too up on all our --with-foo flags, so rather than say
something stupid, I've expressed the idea in general terms above. I
guess I'm asking you to see if you make things work this way; if you
run into a showstopper obstacle, then okay, it can't be done. But if
it's just a matter of some configury and link rearrangement...
If you want, start out by implementing a totally skeleton Serf-based
DAV implementation, one that just implements the svn_ra API but errors
on every call. I'll help try to fit that into my scheme above; if I
can't do it, I certainly won't complain that you couldn't.
> I think we're in agreement that neon and serf can't *both* be loaded
> at the same time because they both want control over the http/https
> scheme. I don't think an 'agent' system like what ra_svn does makes
> sense here.
Yes, agreed.
> Plus, if we have a library that has the same name but could have two
> completely independent implementations, I'm very concerned that it
> would present difficulties on a user-support issue.
Sure. We should change *both* their names, to dav-neon and dav-serf
(adjust appropriately for underscore- and prefix-preferring contexts).
> Like we have libsvn_fs_fs and libsvn_fs_base, I could see
> libsvn_ra_dav_neon and libsvn_ra_dav_serf. But, I'd be wary of having
> the library name not clearly indicate what client library we'd use.
I agree the library name should clearly indicate which library it is.
> I've also been trying to avoid forcing a rename in libsvn_ra_dav as I
> haven't thought through the consequences on our compatiblity rules if
> we remove that library. -- justin
Let's think those through, then...
Hmmm, did we have this problem when it was libsvn_fs? No, because
libsvn_fs became a forwarding library, that (as it happens) can
actually support both of its forwardees simultaneously. We could do a
similar thing, but just refuse to have both forwardees available at
the same time. That is, at run time, it looks like a pointless level
of indirection; but at development/compile time, the indirection
switches between two real choices.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 29 00:07:55 2005