What should I 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 clea         


        

Answer 1

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.

Answer 2

(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.

Answer 3

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.)

Answer 4

I solved this problem by copying some colleague's .svn directory into mine and then updating my working copy. It was a nice, quick and clean solution.

Answer 5

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'

Answer 6

I just removed the file svn-xxxxxxxx from the ~\.svn\tmp folder, where xxxxxxxx is a number.