Thank! Good clue!
Its not svn at all, but eclipse, tho I can't imagine why only .svn
contents gets affected.
I checked out a working copy outside of eclipse, then imported that into
a new eclipse project, "fsusage". The import operation is what's setting
some files immutable. The files are *not* immutable in the import source
copy; just in the destination.
I'll move this problem over to the eclipse list. And thanks for the
help! I rarely use chflags for exactly this reason...too easy to mess up.
15:54:09.240 chflags
tadata/.plugins/org.eclipse.core.resources/.history/3f/301352b85297001a1c36d8fbb4c06a44
0.000023 java
15:54:09.298 chflags
tadata/.plugins/org.eclipse.core.resources/.history/25/101859b85297001a1c36d8fbb4c06a44
0.000023 java
15:54:10.820 chflags
/Users/bcox/Projects/workspace.binary/fsusage/.svn/dir-wcprops
0.000047 java
15:54:10.830 chflags
/Users/bcox/Projects/workspace.binary/fsusage/.svn/empty-file
0.000032 java
15:54:10.846 chflags
/Users/bcox/Projects/workspace.binary/fsusage/.svn/entries
0.000034 java
15:54:10.849 chflags
/Users/bcox/Projects/workspace.binary/fsusage/.svn/format
0.000026 java
15:54:10.853 chflags
/Users/bcox/Projects/workspace.binary/fsusage/.svn/README.txt
0.000026 java
15:54:10.858 chflags
/Users/bcox/Projects/workspace.binary/fsusage/.svn/prop-base/.classpath.svn-base
Stephen Davis wrote:
> 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 22:15:11 2006