[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: Julian Fitzell <julian_at_beta4.com>
Date: 2002-04-15 23:44:41 CEST

Perry E. Metzger wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>>>I realize that extracting Apache and such from the process would be
>>>very hard, but would it be difficult to make the standard tools able
>>>to operate through port forwarded ssh connections the way that CVS
>>>happily operates via CVS_RSH=ssh based connections?
>>i don't believe it would be possible (or at least easy) to make
>>ra_local work over ssh, like cvs does, but you could get much the same
>>effect by using ra_dav over ssl.
> "Much the same effect" might not be sufficient for some people. There
> are a lot of people who are really used to using ssh. With port
> forwarding, though, this should be doable, shouldn't it?

But all those people are also really used to using CVS. If they're
going to switch version control systems, surely the secure connection
mechanism is secondary? I mean CVS_RSH is almost transparent anyway so
people aren't really *used* to using it and SSL should be even more
transparent since it is (or will be) fully supported by the svn client.
  This is all from a client perspective, of course. From a server
administrators perspective, enabling SSL is basically just a matter of
passing the appopriate flags to configure and using the right apache
directives. Hardly any harder than configuring apache in the first place.

So, yes, you have to allow the appropriate port through but I don't see
what else people would cling to about CVS_RSH...


Beta4 Productions (http://www.beta4.com)
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 15 23:46:16 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.