> I am puzzled, however. Given that client/server has been part of the
> SVN design from the first, why not just use SVN in client/server
> mode and run the server on your central machine?
I, for one, am a little concerned with breaking the CVS operational
model in this respect. I haven't been loud about it, since the major
target audience of Subversion is open-source development projects
which pretty much all use client/server.
However, at MIT we have a few big AFS cells where it's fairly easy to
get space, and scores of CVS repositories are run by various
individuals and small groups out of this filesystem. It's kind of
pokey, but it's easy to set up and doesn't require any maintenance.
To introduce Subversion here would require people to dedicate server
machines or would require much more commitment from the operations
group. That's a noticeable barrier.
As I understand it, we already have a way of selecting different
methods of repository access. (That is, libsvn_ra_dav is slated to be
only one of several options.) That's good; it means that in the
future, someone could write code which allows clients to access a
repository (probably in some different format) directly through the
filesystem.
Perhaps we should also have a way of having the server select
different repository formats? So libsvn_fs would become libsvn_fs_db.
This is less important to me, but it might be a good door to leave
open.
More ambitiously, we could unify the concept of "access mechanism" and
"repository format" and make them both available to either client or
server. Then you could trivially create a Subversion application
proxy by running a server which uses libsvn_ra_dav as its "repository
format." Or a client could access a db3 repository directly without
any extra shim code. I'm not sure if the details of this approach
work out, but it's interesting to think about.
Received on Sat Oct 21 14:36:08 2006