Subversion umask tip
When using the subversion source control system with access methods other than apache2+webdav it’s a good idea to create a seperate group and add all developers’ usernames into this group.
Afterwards change the group of everything in the repository to this group. Assuming the group name is ‘svn‘ the unix command to do this would be something like
chgrp -R svn /path/to/repository
Then you will also have give the group write access to the repository;
chown -R g+rw /path/to/repository
If everybody’s umask’s are set such that newly created files/directories will have ‘rw‘ access for the group, then you’re all set. That mask would be something like 002 (which creates a file equivalent to the chmod parameter 775).
umask’s are usually not set at 002, they are set at 022 which gives write access to only the creator of the file.
So it’s a good idea to use wrapper scripts for commands such as svn, svnadmin , svnserve etc. (When doing svn+ssh , a svnserve instance running as that user is spawned, so the wrapper will get called there too)
Before creating the wrapper, rename the actual svn executable to svn-real.
Assuming ‘svn’ is at /usr/local/bin a wrapper for ‘svn’ might look like this
#!/bin/sh
umask 002
/usr/local/bin/svn-real "$@"
It would also make things a lot easier if you initially created the repository while logged in as a user that’s in the ‘svn’ group. Just remember to do
umask 002
before running the ‘svnadmin create‘ command and the permissions will be created correctly.
It’s a little late in the post to tell you why you need all of this but it’s better late than never. When using the file:// and svn+ssh:// methods of access, svn commands are run with the identity and permissions of the user that’s running the command (in the ssh case, the username given to ssh). When multiple people are accessing the same repository, sooner or later you will get stuck with permission errors while creating or modifying the Berkeley DB files subversion creates in the repository. The above solution is needed to fix this. When using apache2+webdav this problem does not exist because once configured access to the database file is always made by the same daemon user.
Good luck.
