views:

157

answers:

2

When commiting changes to already existing files I receive the following error messages since today, although no one did change anything I know of at the server or client side.

The server is running SUSE Linux Enterprise Server 10 (i586). We're using use mod_dav_svn 1.6.4 in apache 2.2.13. The svn server is running behind a reverse-proxy whose settings are also said to have not changed.

Me and the persons who also do have the problem also are using Tortoise svn on windows as client.

Updating and creating new files also works without problems.

mod_dav_svn close_stream: error closing write stream  [500, #2]
Can't open file '/var/lib/svn/repos/project/db/transactions/1744-1gq.txn/next-ids': No such file or directory  [500, #2]
mod_dav_svn close_stream: error closing write stream  [500, #2]
Can't open file '/var/lib/svn/repos/project/db/transactions/1744-1gr.txn/node.c-293.0-1732': No such file or directory  [500, #2]
Could not MERGE resource "/repos/project/!svn/act/48c175a7-c2dc-624d-a16d-c50c9a4f1679" into "/repos/project/folder/branches/CR008/folder/folder/WebContent/custom/webtop/admin2".  [409, #0]
An error occurred while committing the transaction.  [409, #2]
Can't open file '/var/lib/svn/repos/project/db/transactions/1744-1gs.txn/props': No such file or directory  [409, #2]

I also checked for disk space and restarted the svn server and run svnadmin recover. What else could I try?

A: 

I'd check into those "no such file or directory" messages and see if they're true. These error log things are often true!

Chris Thornton
The folder /var/lib/svn/repos/project/db/transactions/1744-1gs.txn is indeed not existing. However I suppose that these folder in the transactions directory will get removed by svn when the transaction get's rolled back or committed. The /var/lib/svn/repos/project/db/transactions does exist.
Sorry, I missed the fact that we were all files, not directories. Still, it may be helpful to troubleshoot this on the basis of those files being missing, when you think those transactions should be there.
Chris Thornton
A: 

The problem occured due to an http proxy server which was between the reverse proxy and the client. As soon as it got deactivated SVN worked again :-).