[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ssh based access?

From: Scott Lenser <slenser_at_cs.cmu.edu>
Date: 2002-04-18 19:35:53 CEST

> 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.

I'd put the network mounted storage into use case 2. I've seen many CVS
repositories that are shared amongst a group of people simply by putting
the repository storage on a networked file system like AFS. This gives
reasonable performance and the filesystem already has all the permission
mechanisms built in. This is a pretty convenient way to share a repository
but isn't really necessary as long as there is a convenient way to handle
use case 2.

> 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.

> 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 ;-).

I agree with the sentiment that more attention needs to be paid to use case 2.
I'm not sure that apache necessarily is excluded by this though. Personally,
I felt setting up for use case 2 was painful but not excessively so enough to
make me not want to use subversion; until I wanted the traffic to the repository
machine to be encrypted. It could just be my general lack of understanding of
exactly how certificates are done, but I gave up after I add made what I thought
was a valid certificate and compiled apache with ssl support and then went to
try it and got nothing. Non-ssl connections could be used fine. I think any
solution that approximates the amount of overhead of setting up user accounts
for everyone and setting up keys for everyone is fine, even if apache is used.
I think the comparison should be setting up cvs+accounts+ssh+keys versus
setting up apache+ssl+certificates+permissions. I don't think apache is that
bad until the permission stuff enters into it.

Perhaps, this could be taken care of simply by pointing to the appropriate
Apache HOWTO plus an example of accessing a ssl-based repository. If I
get time to look into this some more and manage to get it work, I'll write
up a little HOWTO for you. Other transport mechanisms would be nice, but I
think these can be a post-1.0 item.

> 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.


- Scott Lenser

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 18 19:37:17 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.