[scponly] subversion support

[Kaleb Pederson]

On Thursday 07 April 2005 8:45 am, Dimitri Papadopoulos-Orfanos wrote:
> > Yes.  As mentioned in one of the e-mails you pointed out in the archive,
> > this is used for ssh+svn://... support.  *Both* are needed but need to be
> > handled separately.  In my case, I only need svn support but not svnserve
> > support, as the server is somewhere else and reached via https.  For
> > cases when you are allowing them to use svn+ssh, then svnserve is
> > required and svn would not be wanted.
>
> Why support anything apart from svn+ssh? I mean, if you want to support
> http, why not use https as you do? And if you're using https, why tunnel
> through ssh? Anyway, I'm sure there's a reason, but the primary way to
> use Subversion with SSH is svn+ssh. So shouldn't svnserve be the default?

Our users aren't ssh'ing into the computer that is running subversion.  They 
have checkouts on a webserver that they only have scponly access to.  Thus, 
they can use sftp to modify the files, and then use ssh user at host svn ci -m 
"blah blah" /path/... to commit the files.  Or, ssh user at host svn 
update /path/....  Even though they could commit directly to the repository, 
they wouldn't have a good way to update the web server with access to the svn 
command on the server.

We could use a post-commit hook, but then we have to find a way to allow users 
to decide when the changes really should propagate, revert, etc. etc.

The default should be whatever most people have need of.  For us, we need to 
use the svn command.  Recently, a couple of people have posted about 
svnserve.  Apparently svn use was needed first... if that's indicative of the 
need???

> > Currently, there is no way to set a umask under scponly.  Perhaps there
> > should be?  I patched scponly for my institution, because I needed a
> > umask identical to yours.  This still allows certain clients to use
> > permissions that we don't want to see, but it works much better in most
> > cases.
> >
> > Perhaps this should be a configure time option?  I didn't expect most
> > people to need this functionality, so I hadn't considered it much
> > more....
>
> Yes, that would be a nice option. In the meantime, I just noticed the
> default umask is OK for us. We will just have to set permissions
> manually on a few top-level directories.

I found that it is mostly dependent on the client.  On Linux and Mac, the 
permissions on the files being uploaded seem to carry over, despite whatever 
the umask may be set to on the server.  On Windows, this doesn't happen.  On 
some clients, permissions are never respected but manually changed on upload.

--Kaleb