How to Setup The Permissions in Linux So That Two Users Can Update The Same Svn Working Copy on The Server

How can I setup the permissions in Linux so that two users can update the same SVN working copy on the server?

Directory Set Group ID

If the setgid bit on a directory entry is set, files in that directory will have the group ownership as the directory, instead of than the group of the user that created the file.

This attribute is helpful when several users need access to certain files. If the users work in a directory with the setgid attribute set then any files created in the directory by any of the users will have the permission of the group. For example, the administrator can create a group called spcprj and add the users Kathy and Mark to the group spcprj. The directory spcprjdir can be created with the set GID bit set and Kathy and Mark although in different primary groups can work in the directory and have full access to all files in that directory, but still not be able to access files in each other's primary group.

The following command will set the GID bit on a directory:

chmod g+s spcprjdir

The directory listing of the directory "spcprjdir":

drwxrwsr-x 2 kathy spcprj 1674 Sep 17 1999 spcprjdir

The "s'' in place of the execute bit in the group permissions causes all files written to the directory "spcprjdir" to belong to the group "spcprj" .

edit: source = Linux Files and File Permissions

How do you setup a shared Working Copy in Subversion

In my experience it will work just fine out of the box. At my company we have had this setup for a number of years and not experienced any problems (outside the obvious ones of having a shared working copy).

You should however look into having separate working copies and a trigger (hook) that updates the shared location on commits if you need a "live" version of the site.

Subversion creating revision directories with too-strict permissions

If you have more than one developer accessing the repository through the file:// protocol, you may want to look into setting up a Subversion server (using svnserve or Apache). With that solution, the server itself is responsible for all access and permissions on the repository files, and you won't run into this problem.

From the SVN Book:

Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called “Supporting Multiple Repository Access Methods”). Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs—from a security standpoint, it's effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn't careful.

svn unix permissions

The permissions are correct. TortoiseSVN was simply asking for login multiple times (basically each request it had to make to the server). So I am now using a private key based authentication using Putty/Pageant and TortoisePlink.exe.

Default SVN permissions on .svn directory when adding a new directory

A couple of quick ideas:

Have a cron job periodically sanitize permissions on the tree. This is what I've done in the past with shared filesystem areas like this, especially to enforce a particular group name that's not a default group for either user.
Set each user's umask (i.e. in .bashrc) so that newly created files are group-writable. i.e.:
```
umask u=rwx,g=rwx,o=r
```
will result in new files created as -rw-rw-r--, and new directories created as drwxrwxr--

Sorry that neither of these is svn-specific, if I turn up a way to set an "svn umask" I'll check back with an edit.

SVN book suggests replacing the svn binary with a wrapper shell script that first sets the umask, then runs the actual svn command.

SVN access structure

Please, read carefully the whole Path-Based Authorization chapter in SVN-Book
After it you'll be able to detect 2 errors and at least 1 imperfection in your rules, which give you not the result you expect, but according to defined rulesets

If Repository is SVN-repo and /Project/* is tree inside repo, you have incorrect sections headers, because in [A:/B/C/D/E] A means REPOSITORY NAME and only repository
If some of your ACL-rules in child folder are identical to parent folder rule, you can skip it's definition - they are inherited in nested tree by default
No access in authz-file is empty list of access rules for defined user
Possible access rules are rw, r,

Thus, such a set of rules for solving the problem follows from the mentioned above

[/]
User_1 = rw
User_2 = rw

[Repository:Project/Folder_1]
User_2 =

[Repository:Project/Folder_2]
User_1 =

As alternative [/] you can have [Repository:] section, but in this case you have to define base ACL for each added repository on server (every SVN-server can have any amount of served repos) instead of inheritance from root-rules and tuning only needed parts of them