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.

Things have changed with SVN 1.7, and the popular solution of deleting the log file in the .svn directory isn't feasible with the move to a database working-copy implementation.

Here's what I did that seemed to work:

Delete the .svn directory for your working copy. Start a new checkout in a new, temporary directory. Cancel the checkout (we don't want to wait for everything to get pulled down). Run a cleanup on this cancelled checkout. Now we have a new .svn directory with a clean database (although no/few files) Copy this .svn into your old, corrupted working directory. Run svn update and it should bring your new partial .svn directory up to speed with your old working directory.

That's all a little confusing, process wise. Essentially, what we're doing is deleting the corrupt .svn then creating a new .svn for the same checkout path. We then move this new .svn to our old working directory and update it to the repo.

I just did this in TSVN and it seems to work fine and not require a full checkout and download.

-Jody

Take a look at

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

Summary of fix from above link (Thanks to Anuj Varma)

Install sqlite command-line shell (sqlite-tools-win32) from http://www.sqlite.org/download.html sqlite3 .svn/wc.db "select * from work_queue" The SELECT should show you your offending folder/file as part of the work queue. What you need to do is delete this item from the work queue. sqlite3 .svn/wc.db "delete from work_queue" That’s it. Now, you can run cleanup again – and it should work. Or you can proceed directly to the task you were doing before being prompted to run cleanup (adding a new file etc.)

If all else fails:

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

The latest verion (I'm using 1.9.5) solve this problem by adding an option of "Break locks" on the clean up menu. Just make sure this check box is selected when doing clean up.

https://i.stack.imgur.com/6A4el.png

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.

I've tried to do svn cleanup via the console and got an error like:

svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.

So I created this file manually (empty) and did svn cleanup again. This time it was done OK.

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:

Check out at platform with a real filesystem (Unix-based), rename the file, and commit changes. 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. 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

Run svn cleanup command in a terminal (if it fails from Eclipse which was my case):

~/path/to/svn-folder/$ svn cleanup

I tried different solutions explained here, but none worked.

Action Team → Update to head fails:

svn: E155004: There are unfinished work items in '/home/user/path/to/svn-folder'; run 'svn cleanup' first.

Action Team → Cleanup fails with same error.

Solution that worked for me: run svn cleanup command in a terminal.

The command succeeded.

Then Team → Update in Eclipse worked again.

Note: my SVN version is 1.9.3.

Also check Chris's answer if svn cleanup does not work.

I had the same problem. For me the cause was a conflict with EasySVN and (TortoiseSVN or just SVN). I had auto update and commit with EasySVN (which wasn't working).

When I turned this off, I was unable to cleanup, commit, or update. None of the above solutions worked, but rebooting did :)

Subclipse gets confused by Windows' truly diabolical locking behaviour. Unlocker is your friend. This can find locked files and forcibly release the locks.

I just had this same problem on Windows 7 64-bit. I ran console as administrator and deleted the .svn directory from the problem directory (got an error about logs or something, but ignored it). Then, in explorer, I deleted the problem directory which was no longer showing as under version control. Then, I ran an update and things proceeded as expected.

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.

Whenever I have similar problems I use rsync (NB: I use Linux or Mac OS X) to help out like so:

# Go to the parent directory
cd dir_above_borked

# Rename corrupted directory
mv borked_dir borked_dir.bak

# Checkout a fresh copy
svn checkout svn://... borked_dir

# Copy the modified files to the fresh checkout
# - test rsync
#   (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/

# - If all ok, run rsync for real
#   (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/

That way you have a fresh checkout, but with the same working files. For me this always works like a charm.

When I face this issue with TortoiseSVN (Windows), I go to Cygwin and run the 'svn cleanup' from there; it cleans up correctly for me, after which everything works from TortoiseSVN.

I ran into that too lately. The trick for me was after selecting "Clean up", in the popup options dialog, check "Break Locks", and then "OK". It cleaned up successfully for me.

I faced the same issue. After some searching on the Internet found the below article. Then realized that I was logged as a user different from the user that I had used to setup SVN under, a permission issue basically.

There are some very good suggestions in the previous answer, but if you are having an issue with TortoiseSVN on Windows (a good product, but ...) always fallback to the command line and do a simple "svn cleanup" first.

In many circumstances the Windows client will not run the cleanup command, but cleanup works fine using thing the SVN command line utility.

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.

Answers here didn't help me, but before checking out the project again, I closed and opened Eclipse (Subversive is my SVN client) and the problem disappeared.

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

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

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.

I hit an issue where following an Update, SVN showed a folder as being conflicted. Strangely, this was only visible through the command line - TortoiseSVN thought it was all fine.

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup, svn revert, svn update and svn resolve were all unsuccessful at fixing this.

I eventually solved the problem as follows:

Look in the .svn directory for "sub_dir"

Use RC -> Properties to uncheck the 'read only' flag on the entries file

Open the entries file and delete the line "unfinished ..." and the corresponding checksum

Save, and re-enable the read-only flag

Repeat for the my_dir directory

Following that, everything was fine.

Note I didn't have any local changes, so I don't know if you'd be at risk if you did. I didn't use the delete / update method suggested by others - I got into this state by trying that on the my_dir/sub_dir/sub_sub_dir directory (which started with the same symptoms) - so I didn't want to risk making things worse again!

Not quite on-topic, but maybe helpful if someone comes across this post as I did.

I did sudo chmod 777 -R . to be able to change the permissions. Without sudo, it wouldn't work, giving me the same error as running other commands.

Now you can do svn update or whatever, without having to scrap your entire directory and recreating it. This is especially helpful, since your IDE or text editor may already have certain tabs open, or have syncing problems. You don't need to scrap and replace your working directory with this method.

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.

While facing a similar issue, manual merge in the repository sync view helped to solve the issue.

One file name was conflicting with other and it clearly mentioned the issue. Renaming the newer file to a different name resolved it.