You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Tripp Lilley <tl...@perspex.com> on 2001/03/30 03:52:09 UTC
Installation [was Re: transaction roots]
On 29 Mar 2001, Ben Collins-Sussman wrote:
> In the long run, I'd hate to see ra_local relegated to an obsolete
> test harness. I still think setting up Apache/DAV/mod_dav_svn on a
> local box is way too high a barrier to entry for someone who wants to
> create a private repository for personal use... so I predict (I hope?)
> that ra_local will be used just often as it's used in CVS. (But
> that's just an opinion... I'm sure you'll personally write an amazing
> install-script to lower that Apache barrier. ;) )
Just as a side note, I recently installed CVS for the first time (someone
was holding a gun to my head). One of the things that bugged me was the
disconnect between "local", "remote", and "external" access to the repo.
To my admittedly small mind, I'd prefer a system that declared itself as
being "a network app" that happened to work locally through the magic of
the localhost interface or perhaps domain sockets :) As an administrator
and user, it helps me to not have to keep track of the difference. As a
coder / possible contributor, it helps me to not have to think of the "two
houses, both alike in dignity" that need updating...
To that end, I propose that the lowered entry barrier is pretty simple
really: when you build RPMs, BSD ports, etc., you have them include a
stripped down Apache install with mod_dav and mod_dav_svn all configured,
and all set to run on a different port and to use a different set of
directories for config, libraries, etc. In that sense, Apache, mod_dav,
and mod_dav_svn are all just "part of the installation".
Anyone who cares about the fact that you're running "another" copy of
Apache is someone who cares enough to install it themselves by hand, to
their specific liking. Your "weekend warrior" who just wants SVN to manage
a small repo for personal use is likely to be just grabbing the RPM and
going, anyway.
Some of these opinions are worth what you paid me for them :) Others are
pure gold. Which is which? ;)
--
Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/
------------------------------------------------------------------------------
"Fiber makes you poop." -- From <http://www.pvponline.com/bts_studio.php3>
Re: Installation [was Re: transaction roots]
Posted by RADICS Peter <mi...@lbcons.net>.
Just for the record, I'm personally +1 (or even +2) on ra_local.
Right now I'm working on a 486 box with 16 megs of ram, so I'd be very
happy to do svn without apache. Yes, I know computers are cheap these
days. So what? I happen to like this one :) So please don't force
everyone to use apache for their small repos. Long live ra_local! :)
(of course cheers to ra_dav as well, but for different reasons)
cheers,
mitch
--
// RADICS Peter <mi...@lbcons.net> (http://lbcons.net)
//
// "If human beings don't keep exercising their lips,
// their brains start working." -- Ford Prefect
Re: Installation [was Re: transaction roots]
Posted by Daniel Stenberg <da...@haxx.se>.
On Fri, 30 Mar 2001, Greg Stein wrote:
> > 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)
[snip]
> Why do you supposed there would be conflicts?
I can't say there *will* be, and I surely couldn't argue about apache setup
issues with you! ;-) I'm just saying there's a risk. I don't know what kind
of weird setups and requirements people can have and use for their web
servers that the new one would have to use (or not have to use) as well.
This is not a very strong argument as I don't have any specific examples or
even a possible problematic scenario.
> So... Average Joe can definitely run an SVN Server (oh, sorry, Apache
> server plus SVN :-). The question is whether the machine administrator
> will let these things run continually. But hey... to run one while logged
> in? Surely, an admin would be fine with that.
Right, that's true of course. It could certainly run while the user is logged
in...
> Apache will increase the source footprint, but it doesn't necessarily
> create an insurmountable barrier for Joe User. Just think "port 4734"
I agree. I'm not seeing any insurmountable barriers. I'm only saying that I
see advantages with the local-mode.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: Installation [was Re: transaction roots]
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 30, 2001 at 09:39:50AM +0200, Daniel Stenberg wrote:
> On Fri, 30 Mar 2001, Tripp Lilley 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.
Agreed. For the cases I've seen/used, a repository is local or remote. Never
both.
> > To that end, I propose that the lowered entry barrier is pretty simple
> > really: when you build RPMs, BSD ports, etc., you have them include a
> > stripped down Apache install with mod_dav and mod_dav_svn all configured,
> > and all set to run on a different port and to use a different set of
> > directories for config, libraries, etc. In that sense, Apache, mod_dav,
> > and mod_dav_svn are all just "part of the installation".
That's my hope/intent. "Oh, yah, there's an Apache server in there. why do
you ask?"
> I'd really not like that. For a number of reasons, but these are the two
> main ones I can immediately think of:
>
> 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.
And if the SVN install preconfigures it for you? Just another little app
running.
> 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)
I have two Apaches running on my system. No conflicts at all. I could run a
third on port 80, should I choose.
Oh. Actually, I have a third. It's running on another interface at port 80.
Why do you supposed there would be conflicts?
> > Anyone who cares about the fact that you're running "another" copy of
> > Apache is someone who cares enough to install it themselves by hand, to
> > their specific liking. Your "weekend warrior" who just wants SVN to
> > manage a small repo for personal use is likely to be just grabbing the
> > RPM and going, anyway.
>
> What about the "weekend warrior" who uses a machine he can't install servers
> on?
Ah. Now we get to it. You can install Apache on any machine that you want.
Nobody said the thing had to run on port 80. And you can install/run it from
/home/gstein/svn if you'd like.
I run a development Apache 1.3 on 8080 as "gstein". Apache 2.0 (as "gstein")
on 8081. Apache 1.3 on test.webdav.org, port 80. No issues, no problems.
So... Average Joe can definitely run an SVN Server (oh, sorry, Apache server
plus SVN :-). The question is whether the machine administrator will let
these things run continually. But hey... to run one while logged in? Surely,
an admin would be fine with that. For personal SVN servers, we'd simply have
Apache configured to start a single process/thread. If the server happens to
be used by many people, then Apache would just scale up the number of ready
workers. But an admin is not going to complain about a single process
hanging out while a user is logged in.
etc etc
Apache will increase the source footprint, but it doesn't necessarily create
an insurmountable barrier for Joe User. Just think "port 4734"
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Installation [was Re: transaction roots]
Posted by Daniel Stenberg <da...@haxx.se>.
On Fri, 30 Mar 2001, Tripp Lilley wrote:
> > 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
Now, I'm not any RPM knowledgable person, but doesn't that use hard-coded
paths? If you're not sysadmin, how can to install files in system
directories?
> > 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).
You're missing my point (my fault, I didn't really spell it out).
I'm not talking about a fysical limitation, I'm talking system policies. Like
imagine my account over at my web hotel that hosts a bazillion domains and
users. They frawn upon servers started by users. Sure, finding a
non-priveledged port is simple enough, but that's not the problem I'd have to
work-around here.
Any program that requires a server is out of the question for me to install
there, unless I can get the management's attention and have their permission
or perhaps have them do the job to set it up system-wide.
I don't know how common this scenario is, but I know for sure that I've had
access to many such machines during my days that have imposed similar limits.
> 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.
Well, any new feature adds code and thus also problems/bugs. I think of
local-mode as a feature. A cool feature actually.
> 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
How would that be? How would I cause "grievous damage" to my local repository
if I mistakenly think it is a "remote" one all of a sudden?
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: Installation [was Re: transaction roots]
Posted by Tripp Lilley <tl...@perspex.com>.
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>
Re: Installation [was Re: transaction roots]
Posted by Daniel Stenberg <da...@haxx.se>.
On Fri, 30 Mar 2001, Tripp Lilley wrote:
> Just as a side note, I recently installed CVS for the first time (someone
> was holding a gun to my head). One of the things that bugged me was the
> disconnect between "local", "remote", and "external" access to the repo.
>
> To my admittedly small mind, I'd prefer a system that declared itself as
> being "a network app" that happened to work locally through the magic of
> the localhost interface or perhaps domain sockets :) As an administrator
> and user, it helps me to not have to keep track of the difference. As a
> coder / possible contributor, it helps me to not have to think of the
> "two houses, both alike in dignity" that need updating...
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.
> To that end, I propose that the lowered entry barrier is pretty simple
> really: when you build RPMs, BSD ports, etc., you have them include a
> stripped down Apache install with mod_dav and mod_dav_svn all configured,
> and all set to run on a different port and to use a different set of
> directories for config, libraries, etc. In that sense, Apache, mod_dav,
> and mod_dav_svn are all just "part of the installation".
I'd really not like that. For a number of reasons, but these are the two
main ones I can immediately think of:
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.
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)
> Anyone who cares about the fact that you're running "another" copy of
> Apache is someone who cares enough to install it themselves by hand, to
> their specific liking. Your "weekend warrior" who just wants SVN to
> manage a small repo for personal use is likely to be just grabbing the
> RPM and going, anyway.
What about the "weekend warrior" who uses a machine he can't install servers
on?
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol