What should I do when 'svn cleanup' fails?

When starting all over is not an option...

I deleted the log file in the .svn directory (I also deleted the offending file in .svn/props-base), did a cleanup, and resumed my update.

If all else fails:

1. Check out into a new folder.
2. Copy your modified files over.
3. Check back in.
4. Zip the old folder up somewhere (you never know + paranoia is good) before deleting it and using the new one.

This answer only applies to versions before 1.7 (thanks @ŁukaszBachman).

Subversion stores its information per folder (in .svn), so if you are just dealing with a subfolder you don't need checkout the whole repository - just the folder that has borked:

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

This will give you a good working copy of the borked folder, but you still have your changes backed up in borked_dir.bak. The same principle applies with Windows/TortoiseSVN.

If you have changes in an isolated folder have a look at the

svn checkout -N borked_dir   # Non-recursive, but deprecated

or

svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'

$ ls -la .svn
$ rm -f .svn/lock

Then

$ svn update

Hope it helps

I had the exact same problem. I couldn't commit, and cleanup would fail.

Using a command-line client I was able to see an error message indicating that it was failing to move a file from .svn/props to .svn/prop-base.

I looked at the specific file and found that it was marked read-only. After removing the read-only attribute I was able to cleanup the folder and the commit my changes.

It's possible that you have a problem with two filenames differing only by uppercase. If you ran into this problem, creating another working copy directory does not solve the problem.

Current Windows (i.e. crappy) filesystems simply do not grok the difference between Filename and FILEname. You have two possible fixes:

1. Check out at platform with a real filesystem (Unix-based), rename the file, and commit changes.
2. When you are bound to Windows you can rename files in the Eclipse SVN repository browser which does recognise the difference and rename the file there.
3. You can rename the problematic files also remotely from any command-line SVN client using svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename

If the issue is case sensitivity (which can be a problem when checking out to a Mac, as well as Windows) and you don't have the option of checking out onto a *nix system, the following should work. Here's the process from the beginning:

% svn co http://[domain]/svn/mortgages mortgages

(Checkout ensues… then…)

svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory

Here SVN is trying to check out two files with similar names that differ only by case - Header_3_noBookmark.gif and Header_3_nobookmark.gif. Mac filesystems default to case insensitivity in a way that causes SVN to choke in situations like this. So...

% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

However, running svn cleanup doesn't work, as we know.

% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control

spacer.gif isn't the problem here… It just can't move past the previous error to the next file. So I deleted all of the files from the directory other than .svn, and removed the SVN log. This made cleanup work, so that I could check out and rename the offending file.

% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A    Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A         foo
D         Header_3_nobookmark.gif
% svn up
A    spacer.gif
A    Header_3_noBookmark.gif

Following this, I was able to go back to the root directory of the project, and run svn up to check out the rest of it.

(Before you try moving folders and doing a new checkout.)

Delete the folder the offending file(s) are in - yes, even the .svn folder, then do an svn cleanup on the very top / parent folder.

I also had the problem where cleanup would fail. Originally I was trying to commit some code, but it said:

svn: E155004: There are unfinished work items in '/my/path/to/files'; run 'svn cleanup' first.

But when I tried to cleanup:

svn: E155007: '/my/path/to/files' is not a working copy directory

In my case, it turns out that I had a revision conflict. My svn folder contained .mine, .r1, and .r2 files. Once I resolved the conflict, the cleanup ran successfully.

After going through most of the solutions that are cited here, I still was getting the error.

The issue was case insensitive OS X. Checking out a directory that has two files with the same name, but different capitalization causes an issue. For example, ApproximationTest.java and Approximationtest.java should not be in the same directory. As soon as we get rid of one of the file, the issue goes away.