AIR Wiki : SubversionIssues

HomePage :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register

Subversion Issues


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


See:

A nice example of leaky abstractions!

svn move or svn copy leads to a "502 Bad Gateway" error


See the Subversion502BadGateway page

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:

repository_has_moved.txt:
The myrepos repository has moved. Please change to the new URL:

svn switch --relocate https://www.example.net/svn/myrepos/  \
	https://www.example.org/projects/myrepos/
svn update


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.

  1. Apache authentication. This method allows you to restrict access to certain users. It does not allow anonymous access. For example:
<Location /svn/myrepos>
  AuthType Digest
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
</Location>

  1. 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:
<Location /svn/myrepos>
  order allow,deny
  allow from all
  <LimitExcept GET PROPFIND OPTIONS REPORT>
	Require valid-user
  </LimitExcept>
</Location>

  1. 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.
<Location /svn/myrepos>
  AuthzSVNAccessFile /etc/apache2/dav_svn.acl
</Location>


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.

Categories
CategorySysAdmin

There are no comments on this page. [Add comment]

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by Wikka Wakka Wiki 1.1.6.0
Page was generated in 0.0301 seconds