On Wed, Oct 11, 2000 at 03:41:44PM -0500, Ben Collins-Sussman wrote:
>...
> Once upon a time, we decided to make Apache the main "server" that
> would link to the Subversion filesystem. We had many, many postitive
> justifications for doing this (stability, load balancing, industry
> standards, WebDAV, proxying, etc.) The only "con" on this idea was
> the fact that Apache was a bit large, i.e. a bit of a
> barrier-to-entry:
>
> "If ordinary Joe Shmo wants to create a Subversion repository, he
> needs to set up Apache first?"
>
> "Yeah, but that's ok. Every free OS comes with Apache, ready-to-run
> right out of the box."
>
> And that was pretty much the end of the discussion.
Not quite. It is also very easy to have a "little" directory under svn/
which contains Apache. It can be preconfigured and set up specifically for
SVN. As far as users are concerned, the fact that Apache is used could be
completely invisible.
Consider: if the user is simply installing this under their own userid, then
we could supply an httpd.conf file that is totally preconfigured (except for
the port and server name).
Now... how is that different from SVN writing its own network server, and
shipping that preconfigured? :-)
If you want to operate on port 80, then yes: you need to deal with an
existing Apache installation. But that doesn't necessarily have to be
difficult. I installed CVS through an RPM. I could also install SVN via an
RPM and have it drop mod_dav_svn into the right areas.
> I'm realizing now that this situation could get annoying. For
> example, I run FreeBSD. My FreeBSD distro has always automatically
> loaded Apache on startup, but it always dies, because I've never yet
> bothered to spend the time configuring my httpd.conf.
Wow. On my Linux distro, it always works fine right out of the box. Somebody
isn't paying attention in FreeBSD packaging land :-)
> And it seems
> silly that I should *have* to get my Apache working before I can
> create a local repository on my machine. In fact, I'd not only have
> to get Apache working, but mod_DAV and mod_DAV_SVN as well.
Depends on how the stuff is packaged, and whether you want to run a private
SVN, or leverage off your existing Apache installation.
> The issue here for me is that a "repository" is (for now) a collection
> of Berkeley DB files on disk. I shouldn't need Apache to use them.
As long as our locking mechanism works between Apache access and local
access, then this would be a Good Thing(tm) ... no question there.
> I think we need to design libsvn_ra in such a way as to keep the
> public interface totally generalized. This means that someday we can
> implement a libsvn_ra_local library which implements the *same*
> interface, but is linked directly into libsvn_fs. As far as
> libsvn_client is concerned, it should have *no* idea whether the
> repository is remote or local.
Absolutely! That has been my thought, too. I like ra_local better than the
ra_direct or ra_linked that I was thinking of.
In any case... yes: you should be able to link the whole shmear together and
have it "just work". I could easily see the libsvn_ra_* as dynamic
libraries. At runtime, libsvn_client dynloads the appropriate library
(through apr_dso_*) and calls the requisite features.
> One of Subversion's design goals was to make the system "natively
> client/server". This addresses one of CVS's big weak points; in CVS,
> the networking and local-access features are two independent code
> branches, and every change to CVS needs to be tested in both places.
> This makes CVS a royal pain to maintain.
We will hopefully minimize the differential to libsvn_ra_dav and
libsvn_ra_local. That will *still* be a rather large chunk of different
code. Once we get the two libs, we'll want to analayze them for ways to trim
them back as much as possible.
> However, a good remedy for this situation isn't to force Subversion to
> always use a network socket. As long as `svn_ra.h' is well-defined,
> we should be able to access repositories both local and remote in a
> solid, maintainable way.
Making the interface the same isn't the same as reducing the number of code
paths to maintain :-)
> Am I making sense? Does svn_ra.h meet this ideal?
Yes. No.
svn_ra.h was just a quick whack at the prototypes that I needed to get a
"checkout" to work. I don't know if they're correct (they're reasonable, but
I reserve the right to change them :-), and I don't know how many more
functions will be needed in that interface. Therefore, I didn't bother to
doc the stuff yet.
Seriously, though... if/when we do a libsvn_ra_local, we will want to be
very careful to keep the code small. It will definitely introduce a
secondary code path. Even worse, it will be "easier" for SVN developers to
deal with, so the network code path won't get tested nearly as much (despite
that being the most common path of our *users*).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006