You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Andrew McNabb <am...@mcnabbs.org> on 2006/11/06 23:23:04 UTC
avoiding umask headaches
Back in 2003, someone posted "RFC: svnserve.conf umask directive". As
far as I can tell, nothing has happened with this yet. I was just
curious what the current plans are for fixing Subversion with svn+ssh
and file so it works with groups.
Most people seem to be recommending:
1) Get root access on the machine you are using.
2) Move /usr/bin/svn and /usr/bin/svnserve to /usr/bin/svn.orig and
/usr/bin/svnserve.orig (thus breaking upgradability if you are using a
package manager)
3) Create /usr/bin/svn and /usr/bin/svnserve wrapper scripts, which
assumes that all users on the system always want to create
group-writable repositories
As it is, we have students on a shared system who would like to use
version control for group projects, but I can't recommend Subversion to
them because they cannot set up a system-wide wrapper script. Is there
any other possible solution to the problem? Are there any plans to fix
the problem permanently, preferably with a config file somewhere?
Thanks.
--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: avoiding umask headaches
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2006-11-06 at 18:23 -0500, Andrew McNabb wrote:
> Back in 2003, someone posted "RFC: svnserve.conf umask directive". As
> far as I can tell, nothing has happened with this yet. I was just
> curious what the current plans are for fixing Subversion with svn+ssh
> and file so it works with groups.
Is there a reason you can't use FSFS? It's not umask-dependent.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: avoiding umask headaches
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 11/6/06, Andrew McNabb <am...@mcnabbs.org> wrote:
> As it is, we have students on a shared system who would like to use
> version control for group projects, but I can't recommend Subversion to
> them because they cannot set up a system-wide wrapper script. Is there
> any other possible solution to the problem?
How about what the svnbook describes here?
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
That is, have a single user access the repository (and make the
repository wholly owned by that user), and then drop your students'
ssh keys (and custom commands) into the user's authorized_keys file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: avoiding umask headaches
Posted by Max Bowsher <ma...@ukf.net>.
Andrew McNabb wrote:
> Back in 2003, someone posted "RFC: svnserve.conf umask directive". As
> far as I can tell, nothing has happened with this yet. I was just
> curious what the current plans are for fixing Subversion with svn+ssh
> and file so it works with groups.
>
> Most people seem to be recommending:
>
> 1) Get root access on the machine you are using.
>
> 2) Move /usr/bin/svn and /usr/bin/svnserve to /usr/bin/svn.orig and
> /usr/bin/svnserve.orig (thus breaking upgradability if you are using a
> package manager)
>
> 3) Create /usr/bin/svn and /usr/bin/svnserve wrapper scripts, which
> assumes that all users on the system always want to create
> group-writable repositories
>
> As it is, we have students on a shared system who would like to use
> version control for group projects, but I can't recommend Subversion to
> them because they cannot set up a system-wide wrapper script. Is there
> any other possible solution to the problem? Are there any plans to fix
> the problem permanently, preferably with a config file somewhere?
Creating an /etc/svnserve.conf has been considered, and is likely to
happen eventually - I believe it's mainly an issue of "when someone gets
around to writing the code".
Max.