Post-Commit hook occassionally fails to fully update during TortoiseSVN commit

We are encountering a problem with the post-commit hook

as it updates to a cifs mounted file system on a unix system.

Here is our configuration

On a Redhat Linux 5.3 system we have set up the

subversion client (subversion-1.6.3-1).

We have set it up so windows clients using TortoiseSVN

(TortoiseSVN 1.6.3, Build 16613 - 32 Bit , 2009/06/20 09:28:19)

are able to checkout, update and commit via the webdav interface

through secure apache.

This seems to work correctly.

The Repositories are located on a local file system, in /data/svn

on the linux system (and are owned by apache:apache).

To complicate the situation we have mounted a windows file system

using the following entry in /etc/fstab

  //winfileserver/devweb /data/DEV cifs \

 
user,rw,credentials=svn_cifs,uid=48,gid=48,file_mode=0755,dir_mode=0755

The svn_cifs file has the following

 username=some-user

 password=some-password

 uid=apache

 gid=apache

 filemode=0660

 dirmode=0770

 nosuid

 nosetuids

The windows filesyem will then be mounted on a windows server running
IIS.

Lets assume we have created a repository called proj, and

We have then used svn to checkout a copy into /data/DEV/proj (this

directory is owned by user apache:apache).

We have set up a hook post-commit so that when the user does a
TortoiseSVN commit

it will automatically update /data/DEV/proj.

This generally works correctly.

However, periodically when a user commits, it breaks the update to
/data/DEV/proj

which is then left in a mixed version (this can be checked with the
svnversion

command).

From that point on, whevever the user tries a commit, the repository is
properly

changed, but no additional changes are propagated to /data/DEV/proj.

The message they receive is

svn: Working copy '/data/DEV/proj' locked

svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)

Unfortunately, running cleanup in TortoiseSVN or from the SVN server

has no effect.

The only way we have been able to fix the problem, is by deleting the
contents of

/data/DEV/proj and then re-checkout to that directory. This might not
be so bad

except one of the projects is 2+ Gigabytes and takes a fairly long time
to fix.

I have done some other testing, and it seems that if the /data/DEV/proj
is on a

mounted linux file system, it does not seem to cause a problem.

I am only left to believe that the problem is because we are using a
mounted windows

file system. Perhaps we are not properly specifing the option during
the mount.

Or perhaps there is a know problem.

Any assistance is appreciated.

paulw

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2376149

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-27 23:31:35 CEST