Can't open activity db: Permission denied error for SVN commits

On my way to work this morning I got an emergency call from developer who unsuccessfully tried to commit latest java code changes to Subversion repository using TortoiseSVN. The developers was getting "Can't open activity db: Permission denied" error in TortoiseSVN client when he tried to commit or create a new tag in SVN.

The Apache error log had this lines related to SVN commit problem
Could not create activity /!svn/act/9dac40a3-4acf-3456-b328-a2598c258d06
Could not open dbm files
Can't open activity db: Permission denied

Just in case I have run svnadmin verify on Subversion repository, but as expected there was no problem at all. Then I noticed that the files on the dav folder of the SVN repository are not writable by Apache server. I changed files permission and successfully committed files with TortoiseSVN again.

The configuration used in this solution

• SVN 1.4.6
• Apache 2.0.49
• Tortoise 1.4.7

Unfortunately no references related to SVN commit problem were found in Subversion FAQ or TortoiseSVN FAQ

Update: I set permissions for "activites.pag" and "activities.dir" files in dav folder to 777

JIRA Subversion Plugin

I got the Jira/Subversion plugin up and running. This plugin checks the Subversion repository once an hour and if any commits have been made to the repository AND the developer has referenced a Jira issue, it will show up in Jira. "Subversion commits" tab is visible on Jira next to Comments and Change History. In addition to the installation steps for Jira Subversion plugin described on Atlassian web site, I added View Version Control permission for Jira users. Remaining step is to enforce developers to use reference to issues during code commit.

Implementing Subversion post-commit hook

Today I've configured Subversion to send a notification to a mail list every time one of developers commits a change to the specific project. This is obviously the most useful for a shared project and I do plan to expand SVN notifications to other projects as well. This is one of the ways we can all keep up with what's going on with shared projects, and will hopefully reduce the amount of "stepping on toes" when working on similar project.

Instead of using supplied with SVN commit-email.pl with hundred lines of Perl without an effort to format the check-in comment, I used SVN-Notify package. I added package to SVN server Linux machine that sends out an email notification when anyone checks in something to Subversion. The Subversion notification email contains the following information:

Person that made the change
What files were changed
Check in comments
Diff of all of the changes that were made

The Perl SVN-Notify package has been installed in the /data/scripts/svnnotify directory and an SVN post-commit hook has been added to the /data/svn/company/hooks directory. The post-commit hook is a shell file that calls the SVN-Notify package with the information from the Subversion checking. This file controls what notification gets sent to whom. The post-commit file has the line :

--to-regex-map DevAlias@foo.bar.com=project \

This line controls who gets notified of what. The DevAlias@foo.bar.com can be any email or email list and can be multiple email addresses separated by a comma. After the = sign, is the SVN repository pattern that is matched to determine if an email is sent for this checkin. In the example above, only checkins on the "project" directory will generate an email to DevAlias@foo.bar.com. This line can be repeated for each pattern that needs to be matched. So, an email notification can be sent to just the email list for that application by having a line for each application.

Next step would be implementation of Subversion and Atlassian's Jira bug tracking tool integration. Developers would have ability to reference Jira issues when they make SVN commits.

Troubleshooting Subversion and TortoiseSVN

Simultaneously I got the complaint from our outsourced teams in India about Subversion. Suddenly they started getting this uninformative error while trying to commit or checkout the code with TortoiseSVN client from SVN.

Error: PROPFIND request failed on '/application/name'
Error: PROPFIND of '/application/name': Could not resolve hostname 'svn. companyserver.com': The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. (https:// svn.companyserver.com)

We didn't perform any changes to SVN repository lately so I'm trying to get more information from network administrators of offshore teams and have feeling that something is wrong with Cisco VPN Client in offshore. On the one hand SVN problems appeared at the same time in two different locations, on the other hand when I started to ask them to connect to others restricted application they were not able to connect too. IPCONFIG /ALL on their machines returns IP addresses in accepted VPN range, but PING or TRACEROUTE are not able to come through network.

Update 1:
I got the response from one of the networking folks onsite. The public VPN server was upgraded last week. Today the network admin audited the new VPN server and compared it with the old VPN configuration and identified only one delta - 'IPSEC over UDP' was no enabled. Now I need the confirmation from offshore partners that Subversion and TortoiseSVN issue is resolved and they have an access to other restricted resources

Update 2: SVN and TortoiseSVN works behind VPN from offshore side