OT: Re: [scponly] subversion support

[Dimitri Papadopoulos-Orfanos]

Hi,

> The biggest reason by far not to do what you mention is that svn+ssh 
> permissions granularity is very poor.  That is, because it happens at the 
> filesystem level, I can't control which hierarchies people have access to and 
> which one's they don't.  Using https, I can use the apache path controls with 
> fine granularity.

I disagree. The granularity and general capabilities of filesystem 
permissions are not poor. Actually they may be richer than Apache's. 
It's perfectly possible to define groups at the system-level and setting 
group ID on directories. Then you also have ACLs.

Anyway, that's not my point. The standard way of using SSH with 
Subversion is the one described in the Subversion book and Web site. I 
maybe haven't been reading Subversion documentation and mailing lists in 
enough detail, but this is the first time I hear of such a setup. As far 
as I can understand, the working copy isn't even on the user's computer, 
one has to copy files from the repository to a working copy and then 
from the working copy to the user's computer. If so, I can't believe 
this is a common scenario.

What we seem to agree on is that it would be nice to have support for 
'svnserve'.

What we can't agree on is the support for 'svn'. I believe it should be 
disabled by default, and 'svnserve' should be the default. But again, I 
may have missed posts on Subversion mailing list that recommend the use 
of the 'svn' setup instead of the 'svnserve' setup, or I may have 
misunderstood the complexity of the 'svn' setup.

--
Dimitri Papadopoulos