Release Management

Monday, March 3, 2008

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

Labels: ,

Saturday, December 29, 2007

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

Labels: , , ,


All posts in one place

  • Doxygen vs JavaDoc
  • Installing JNetDirect's JSQLConnect driver
  • Finding problems in Java code wtih PMD
  • Log4j best practices
  • Can't open activity db: Permission denied error for SVN commits
  • Jira Subversion Plugin
  • Implementing Subversion post-commit hook
  • Troubleshooting Subversion and TortoiseSVN
  • IIS 6.0 does not serve files with .docx
  • Installing ANT on Windows XP
  • Luntbuild dealing with SMTP response 554
  • Confluence and Jira OutOfMemory errors
  •