[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Paul Williams <paul.williams_at_uwex.edu>
Date: Mon, 27 Jul 2009 16:26:17 -0500

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 \



The svn_cifs file has the following










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


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

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



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

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


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.




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

This is an archived mail posted to the Subversion Users mailing list.