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    gt 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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

ls -la  svn   rm -f  svn lock   Then     svn update   Hope it helps

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

After going through most of the solutions that are cited here  I still was getting the error   The issue was case insensitive OS nbsp 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

User · Answer

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 stocked 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

User · Answer

I just removed the file svn-xxxxxxxx from the    svn tmp folder  where xxxxxxxx is a number

User · Answer

This answer only applies to versions before 1 7  thanks  LukaszBachman    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

User · Answer

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

User · Answer

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     gt 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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

Whenever I have similar problems I use rsync  NB  I use Linux or Mac nbsp OS nbsp 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

[svn] What should I do when 'svn cleanup' fails?

Examples related to svn