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

Re: Resend: .svn/entries getting locked on OSX somehow.

From: Stephen Davis <subversion_at_soundgeek.org>
Date: 2006-02-06 20:39:25 CET

On Feb 6, 2006, at 10:22 AM, Brad Cox wrote:

> Resending. Any suggestions out there? Is this getting thru?

Yes, I just think everybody is still scratching their heads. :-)

> Brad Cox wrote:
>> After having been away from subversion for a year or so, I've
>> started encountering severe problems getting back in the saddle on
>> Mac OSX. Namely, nearly everything I do to a working copy leads to
>> a broken
>> (locked) repository as shown below:
>> bcox$ svn status
>> ...looks OK, but...
>> bcox$ svn ci
>> subversion/libsvn_wc/lock.c:158: (apr_err=155004)
>> svn: Working copy '/Users/bcox/Projects/workspace.binary/binary-
>> gar-convoy2' locked
>> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup'
>> for details)
>> ...OK, if you say so...
>> bcox$ svn cleanup
>> subversion/libsvn_subr/io.c:2416: (apr_err=1)
>> svn: Can't move '.svn/tmp/entries' to '.svn/entries': Operation
>> not permitted
>> Permissions problem?
>> bcox$ ls -l .svn
>> -r--r--r-- 1 bcox bcox 118 Feb 5 14:06 README.txt
>> -r--r--r-- 1 bcox bcox 75 Feb 5 14:06 dir-wcprops
>> -r--r--r-- 1 bcox bcox 0 Feb 5 14:06 empty-file
>> -r--r--r-- 1 bcox bcox 9556 Feb 5 14:06 entries
>> -r--r--r-- 1 bcox bcox 2 Feb 5 14:06 format
>> -rw-r--r-- 1 bcox bcox 0 Feb 5 14:06 lock
>> drwxr-xr-x 35 bcox bcox 1190 Feb 5 14:06 prop-base
>> drwxr-xr-x 35 bcox bcox 1190 Feb 5 14:06 props
>> drwxr-xr-x 35 bcox bcox 1190 Feb 5 14:06 text-base
>> drwxr-xr-x 4 bcox bcox 136 Feb 5 16:22 tmp
>> drwxr-xr-x 35 bcox bcox 1190 Feb 5 14:06 wcprops
>> The real problem seems to be that .svn/entries is somehow actually
>> locked (via OSX chflags), not just write protected as I at first
>> suspected.
>> Its not clear who's doing this (svn? eclipse?), but svn seems the
>> most likely culprit at this point.
>> I'm using http: access method via apache2 installed on port 18080.
>> Checkouts work fine, as is the repo itself. Initial working copies
>> are fine, but go south after one or more changes.
>> I've tried several SVN GUI's (subclipse, isvn, simplesvn, etc)
>> which I thought might have been responsible. But the above example
>> was a fresh working copy accessed only by the svn client, version
>> 1.3.0 r17949.
>> Can someone please advise? Subversion is pretty much unusable at
>> this point.

I have no idea why your entries file would be getting its immutable
bit set. Some things to ask:

1) Is your home directory using File Vault?
2) Do you have any anti-virus software running?
3) Have you explicitly checked that the immutable bit is not set
before but is set after a commit? Or does it take a few commits for
this to occur?

One thing you might want to do is use fs_usage to see what's going on
in the filesystem while the commit operation occurs. Unfortunately,
this is sort of difficult with command line tools since you can't
just watch the output of that tool directly. However, you can do
something like the following:

-- in a Terminal Window
sudo fs_usage -w | grep svn

-- in a *different* Terminal window
svn ci -m "a comment" theFile

That will hopefully show you when the immutable bit is getting set if
svn is doing it. I think you should see a line that looks something
like this:

11:32:50.387 chflags
Info.plist 0.001865 svn

Be forewarned that there will be a TON of output from fs_usage so
you'll need to sift through it all to find the chflags operation.
However, if it is not svn doing it then you'll have to remove the
"grep" from above to see who is.

hth,
stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 6 20:41:49 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.