On Tuesday 16 Apr 2002 7:00 am, Greg Stein wrote:
> On Tue, Apr 16, 2002 at 12:15:12AM +0200, Lodewijk Voge wrote:
> > exactly. I only have my own university as a frame of reference, but I see
> > that scheme being used a lot. very light-weight and no special privileges
> > needed.
>
> "special privileges" *ARE* needed. Specifically, you need an account on the
> target machine.
>
> In normal Subversion [server] operation, users only need Apache logons
> rather than system accounts. From a security standpoint, avoiding the
> system accounts is a HUGE win.
As I see CVS used around here there are 3 basic use cases.
1) private repository accessed on local storage
CVS does this, SVN does this. Although am I right in thinking that the use of
db means you'd have problems if this was nfs mounted storage? If so this is
rather limiting for people whose $HOME is network mounted.
2) repository used by small group/one person over a few machines
CVS does ok here. It's a little clunky but the rsh (ssh) route works very
well. As it currently stands SVN doesn't seem to fit. It requires someone
to setup apache to provide the authentication and authorisation, ignoring the
security infrastructure local to the site. If people were to run
repositories from local workstations they would need to run a new network
server which would need maintaining. Plus the user would have to set up
access control themselves, which they may, or may not, be capable of doing
securely.
3) actively maintained repository for a larger (possibly publicly) accessed
project
CVS has well known limitations here, ssh isn't the best solution, and pserver
doesn't do too well. SVN is designed to fix them. I'm really looking
forward to being able to replace CVS repositories which I maintain for wider
usage with subversion when it's ready.
While they are both network accessed repositories, cases (2) and (3) are very
different in requirements. For (3) not needing system accounts is a big win,
for (2) not requiring them is a BIG loss!
In many cases what starts out as case (1) very soon becomes (2). Almost all
the repositories I started out using locally I have at some point or other
accessed remotely, it's very handy to be able to use ssh to access from a
remote site occasionally. With CVS/ssh I can do this even from outside a
firewall, and I get it all for free I don't have to setup usernames/passwords
etc, other than what is already there in my devel environment.
To be as useful as CVS, subversion _must_ support usage style (2) better than
it currently does. I don't think that any solution involving setting up
something as apache will fly here. A streamable protocol which can be piped
over ssh, or any other socket for that matter, which maps onto local unix
access semantics is ideal. For me this is a 1.0 requirement, but then you're
the developers, I'm just a user ;-).
After writing all this I'm sorry that I don't have the time to offer help. I
really hope that subversion turns out to be a success.
Yours,
John Pybus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 18 15:15:00 2002