Question

This morning, I tried to commit a revision to Subversion and found that all of a sudden I did not have permission to do so.

Can't move '/svn/db/txn-protorevs/21000-ga9.rev' to '/svn/db/revs/21/21001': Permission Denied

Looking at the revs directory, I noticed that somebody had committed the 21000th revision, and the group write permission for the new directory is missing for some reason.

     drwxrwsr-x  2 svn    svn  24K 2008-10-27 10:04 19     drwxrwsr-x  2 svn    svn  24K 2008-12-18 07:13 20     drwxr-sr-x  2 jeff   svn 4.0K 2008-12-18 11:18 21 

Setting the group write permission on that directory allows me to commit, so I’m good for another 1000 revisions. But why does this happen, and what can I change to make sure it doesn’t happen again?

Answer 1

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.