Reputation: 47482
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...)
I'm hoping for 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).
Upvotes: 258
Views: 375984
Reputation: 4763
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:
svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename
Upvotes: 6
Reputation: 91
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.
Upvotes: 1
Reputation: 1341
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.
Upvotes: 4
Reputation: 1367
Take a look at
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.)
Upvotes: 119
Reputation: 759
I just removed the file svn-xxxxxxxx
from the ~\.svn\tmp
folder, where xxxxxxxx
is a number.
Upvotes: 0
Reputation: 31
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 :)
Upvotes: 3
Reputation: 67
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.
Upvotes: 0
Reputation: 191
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.
Upvotes: 1
Reputation: 21
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.
Upvotes: 2
Reputation: 420
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.
Upvotes: 2
Reputation: 945
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.
Upvotes: 0
Reputation: 10797
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.
Upvotes: 0
Reputation: 865
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.
Upvotes: 6
Reputation: 10114
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.
Upvotes: 1
Reputation: 383
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.
Upvotes: 2
Reputation: 1116
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:
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.
Upvotes: 0
Reputation: 21
(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.
Upvotes: 2
Reputation: 106
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.
Upvotes: 0
Reputation: 113
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.
Upvotes: 2
Reputation: 6155
Read-only locking sometimes happens on network drives with Windows. Try to disconnect and reconnect it again. Then cleanup and update.
Upvotes: 0
Reputation: 1026
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.)
Upvotes: 0
Reputation:
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.
Upvotes: 229
Reputation: 3495
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.
Upvotes: 6
Reputation: 78922
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'
Upvotes: 16
Reputation: 96157
If all else fails:
Upvotes: 43
Reputation: 291
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.
Upvotes: 29
Reputation: 1849
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.
Upvotes: 0
Reputation: 1662
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:
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
Upvotes: 124
Reputation: 21
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.
Upvotes: 2