Greg S --
I'm looking through some of your (great) libsvn_ra stuff, and I have a
philosophical question.
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.
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. 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.
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.
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.
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.
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.
Am I making sense? Does svn_ra.h meet this ideal?
Received on Sat Oct 21 14:36:10 2006