We use subversion for a few projects, and found a few highly non-trivial maintainance issues. We list them here for future reference:
- Restricted access subfolder in publicly readable root folders are ignored
- svn move or svn copy leads to a "502 Bad Gateway" error
- Don't modify the old repositoy after an move.
- svn commit gives an 403 Forbidden error
- Don't check out on a NFS mount
Restricted access subfolder in publicly readable root folders are ignored
A nice example of leaky abstractions∞
svn move or svn copy leads to a "502 Bad Gateway" error
See the Subversion502BadGateway
Another nice example of leaky abstractions∞
, which shows how a bug in mod_ssl leads to a bug in webdav, which leads to a bug in subversion!
Don't modify the old repositoy after an move
We moved our repository to a new URL. Export and import all worked fine.
Then, I committed the following file to the repository at the old URL:
The myrepos repository has moved. Please change to the new URL:
svn switch --relocate https://www.example.net/svn/myrepos/ \
Now, that turned out to be stupied. Because after the svn update, users got this error:
svn: REPORT request failed on '/projects/G805-Article/!svn/vcc/default'
svn: No such revision 86
Well, oops. I eaasily fixed it by committing the same file at the repository at the new URL, and then doing another commit removing the file. Of course a few users already found out that a simple rm -rf of the old folder, and a new checkout worked fine for them too.
svn commit gives an 403 Forbidden error
I access subversion with Webdav, and found this error in the apache error.log:
Access denied: auser OPTIONS myrepos:/
Access denied: auser MKACTIVITY myrepos:/
I frantically looked to a <tt><Limit MKACTIVITY></tt> statement in the apache logs. Of course there was none. I had to look in the access control list.
It would certainly have helped me if the error statement in the error.log was more helpful. E.g.:
Access denied: user auser has no write permissions set in /etc/apache2/dav_swv.acl
instead of the above.
It really helps to understand that there are as much as 3 places where access control can be enforced with subversion. You really have to look in all three of them.
- Apache authentication. This method allows you to restrict access to certain users. It does not allow anonymous access. For example:
AuthName "Subversion Repository"
- Apache <Limit> and <LimitExcept>. This allows you to give anonymous access, but does not allow folder-based access control. For example, the following permits anonymous read access, but restricts commits to authenticated users:
allow from all
<LimitExcept GET PROPFIND OPTIONS REPORT>
- Fine grain access control with AuthzSVNAccessFile. This methods allows you to restrict control on a per-folder basis. Note that for some fundamental reasons∞, it is never possible to create a restricted access folder within a publically readable root folder.
Don't check out on a NFS mount
Simply, don't. We found that if a home directory was NFS mounted, and users did a checkout, they got error messages, the subversion client was not able to read the local repository. We expect that this was due to the usage of Berkeley DB files in the working copy. We worked around it by giving users a local disk storage to do check outs.