What to do when 'svn cleanup' fails?

Question

I have a lot of changes in a working folder, and something screwed up trying to do an update.

Now when I issue an 'svn cleanup' I get:

>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control

MemPoolTests.cpp is a new file another developer added and was brought down in the update. It did not exist in my working folder before.

Is there anything I can do to try and move forward without having to checkout a fresh copy of the repository?

Clarification: Thanks for the suggestions about moving the directory out of the way and bringing down a new copy. I know that is an option, but it is one I'd like to avoid since there are many changes nested several directories deep (this should have been a branch...) What I'm hoping for is a more aggressive way of doing the cleanup, maybe someway of forcing the file svn is having trouble with back into a known state (and I tried deleting the working copy of it ... that didn't help).

Answer 1

If all else fails:

1. Checkout 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.

Answer 2

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/tortoise

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 svn help checkout

Answer 3

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.

Hope this helps.

Answer 4

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)

Then did a cleanup..

Then resumed my update.

Answer 5

It might not apply in all situations, but when I recently encountered this problem my "fix" was to upgrade the subversion package on my system. I had been running 1.4.something, and when I upgraded to the latest (1.6.6 in my case) the checkout worked.

(I did try re-downloading it, but a checkout to a clean directory always hung at the same spot.)

Dan

Answer 6

It's possible that you have 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 does not grok the difference between Filename and FILEname. You have two possible fixes:

1. check out at platform with real filesystem (unix-based), rename the file and commit changes.
2. when you are sticked to windows you can rename files in Eclipse svn repository browser which does recognise the difference and rename the file there.

Answer 7

Deleting the log file in the problematic directory worked for me as well!

Answer 8

Read-only locking sometimes happens on network drives with windows. Try to disconnect and reconnect it again. Then cleanup and update.