You could always make libsvn_ra_dav a link to either of the dav
implementations at install time. Then you could even support building
both, though only linking to the default one. Replacing the link
would allow switching between the two implementations.
Michael
On 28 Nov 2005 15:28:14 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 1 02:02:41 2005