On Fri, 30 Mar 2001, Daniel Stenberg wrote:
> I think you're mixing things here. I've used many CVS repositories, and once
> I've checked out the code I've never bothered about the "two houses" dilemma
> as you describe it. A source code repository is usually singularis. There's
> only one, be it local or remote.
I was speaking mainly of understanding the distinction as a sysadmin
installing a CVS repo and configuring clients for the first time. My
experience with Perforce was simple: you drop the server in a directory,
tell it to listen on a port, then point your client at that port. If you
want SSH, you build a tunnel to that port and point your client to the
local side of the tunnel.
All of this maps to knowledge I already had of how "network" services
work, which made my life as a sysadmin straightforward.
CVS, on the other hand, required me to understand that the toolset could
use the repository locally, through the filesystem, or remotely through
the pserver protocol, or remotely over SSH, which ultimately treated the
access as "local" through the filesystem, piping output around
willy-nilly.
It scared me. I didn't like it. It was veeery bad :)
> 1 - we're not always system administrators when we want to run SVN on a few
> simple files. requiring apache is an immense barrier in that scenario.
I hate to be cavalier, but this is what I envision:
rpm -i svn-toto-1.0-1.i386.rpm
> 2 - even when we are system administrators, we might just want to have a
> bunch of local files in the repository. Requiring Apache and even
> featuring apache in the install procedure will make possibly dreadful
> collisions and weird setup quirks for people that already have apache
> installed and up and running (compared to using SVN on a local
> repository)
/opt/svn/
apache/
bin/
httpd
lib/
mod_dav.so
mod_dav_svn.so
/etc/opt/svn/
apache/
httpd.conf
svn/
...
/var/opt/svn/
...
In this layout, the "Apache" serving SVN is completely self-contained
-under- SVN's directory and config hierarchy. It lives on a separate port,
uses a separate lib/module directory (and that's presuming you don't
statically link mod_dav and mod_dav_svn, though it would make sense to do
so), and so forth.
Note that I'm not suggesting that this should be the -only- way to install
SVN. Of course, them what wants to install it into their existing Apache
install are welcome to! (rpm -i svn-1.0-1.i386.rpm ? :) ). I'm just saying
that the "low-barrier" method would include everything.
> What about the "weekend warrior" who uses a machine he can't install servers
> on?
A relocatable version of the above kit, installed in the user's home
directory, listening on an unprivileged port (probably computed based on
an offset and the user's UID, so it doesn't conflict with another user
also evaluating SVN).
I guess I just feel like the entire "local" versus "remote" access
dichotomy is "askin' fer trouble". It duplicates code, even when you're
diligent about sharing code. It adds new places for bugs to hide. It
allows users and sysadmins to do grievous damage if they're not aware of
the distinction and the implication of the distinction (I might have made
that last one up, but I'm not sure).
It grates on my "elegance" nerve, basically. How much weight you give to
-my- elegance nerve is, of course, a matter for open debate :)
Take care!
--
Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/
------------------------------------------------------------------------------
"Fiber makes you poop." -- From <http://www.pvponline.com/bts_studio.php3>
Received on Sat Oct 21 14:36:26 2006