SVN Error - Not a working copy

Question

Recently our svn server was changed and we did a svn switch   Since the working copy had a huge amount of unversioned resources  the working copy got locked and we started switching folder by folder for all folders under svn  which works perfectly fine   But at the top most level of the repository  when I try to update files  I get the svn  Working copy     locked error and cleanup is not helping either  When I do cleanup  I get errors like these - svn   content  is not a working copy directory  Fresh checkout is NOT an option at all  Are there any other ways to cleanup and release the locks and do the switch completely    EDIT   The last paragraph in JesperE s answer     If you get a  not a working copy  when   doing a recursive  svn cleanup  my   guess is that you have a directory   which should be a working copy  i e    the  svn directory at the toplevel   says so   but it is missing its own    svn directory  In that case  you   could try to just remove move that   directory and then do a local update   seems to be the solution to the problem in the repository  I have identified those folders and did a fresh checkout of those specific folders alone and wow  the locks are released in the subsequent cleanup  Thanks a lot JesperE     But  I still cannot figure out the svn switch error which now reads something like      svn  The repository at    svn   repourl reponame foldername    has uuid  m reponame   but the WC   has  b5b39681-0ff6-784b-ad26-2846b9ea8e7d    Any ideas

User · Answer

This is what I did    rename trunk to trunk  create a new folder trunk Re-checkout and interrupt the process after few files are checked-out Move the files from trunk  to trunk Do svn cleanup Do svn update  This will update the status of files and then all your files will be versioned

User · Answer

If you get a  not a working copy  when doing a recursive svn cleanup my guess is that you have a directory which should be a working copy  i e  the  svn directory at the top level says so   but it is missing its own  svn directory  In that case  you could try to just remove move that directory and then do a local update  i e  rm -rf content  svn checkout content    If you get a not a working copy error  it means that Subversion cannot find a proper  svn directory in there  Check to see if there is an  svn directory in contents  The ideal solution is a fresh checkout  if possible

User · Answer

I solved it by   Copy a backup of the impacted folders SVN revert the impacted folders Paste the files back from the backup   In my case the problem was due to deleted  svn-files

User · Answer

I also meet this problem in svn diff operation  it was caused by incorrect file path  you should add      to indicate the current file directory

User · Answer

Had this same problem  turns out we had Slik 1 6 2 as well as Tortoise on the same machine  Tortoise had been updated  and had updated the working copy  but Slik had not  so Tortoise worked OK  but command lines failed with      svn      is not a working copy directory   Removing both Tortoise and Slik  then reinstalling Tortoise with command line tools enabled fixed this for me

User · Answer

You must have deleted a SVN - base file from your project  which are read-only files   Due to this you get this error   Check out a fresh project again  merge the changes  if any  of your older SVN project with new one using  Winmerge  and commit the changes in your latest check out

User · Answer

I just got  not a working copy   and for me the reason was the Automouter on Unix  Just a fresh  cd  path to work directory  did the trick

User · Answer

I got into a similar situation  svn   papers  is not a working copy directory  a different way  so I thought I d post my battle story  simplified      svn add papers svn  Can t create directory  papers  svn   Permission denied   Oops  fix permissions    then     svn add papers svn  warning   papers  is already under version control   svn st       papers   svn cleanup svn   papers  is not a working copy directory   And even moving papers out of the way and running svn up  which worked for the OP  didn t fix it  Here s what I did     mv papers papers    svn cleanup   svn revert papers Reverted  papers    mv papers   papers   svn add papers   That worked

User · Answer

I just got  not a working copy   and for me the reason was the Automouter on Unix  Just a fresh  cd  path to work directory  did the trick

User · Answer

Delete  svn folder that is present in your local machine  Press windows icon and type  svn  delete the entire folder  It worked for me

User · Answer

Delete  svn folder that is present in your local machine  Press windows icon and type  svn  delete the entire folder  It worked for me

User · Answer

If you created a file inside a new directory  instead of  svn add newdir newfile  use  svn add newdir  because you need to add the directory   All the files inside the directory will be added by default

User · Answer

Recently I was using other developers Mac I had the same situation  problem was  first I needed to type get repo path to terminal but I didn t  than it says what is your user name and password

User · Answer

I got into a similar situation  svn   papers  is not a working copy directory  a different way  so I thought I d post my battle story  simplified      svn add papers svn  Can t create directory  papers  svn   Permission denied   Oops  fix permissions    then     svn add papers svn  warning   papers  is already under version control   svn st       papers   svn cleanup svn   papers  is not a working copy directory   And even moving papers out of the way and running svn up  which worked for the OP  didn t fix it  Here s what I did     mv papers papers    svn cleanup   svn revert papers Reverted  papers    mv papers   papers   svn add papers   That worked

User · Answer

Today i have found same issue  FILE NAME  is not a working copy in morning and i have spent more then two hours to solve it  After long of RND and Google i found some solution and that is CHECKOUT    CHECKOUT from SUBVERSION to local as new project  Change some of code in java file and COMMIT the project  It s Works for me    Hope it will helpful for you

User · Answer

Could it be a working copy format mismatch  It changed between svn 1 4 and 1 5 and newer tools automatically convert the format  but then the older ones no longer work with the converted copy

User · Answer

Could it be a working copy format mismatch  It changed between svn 1 4 and 1 5 and newer tools automatically convert the format  but then the older ones no longer work with the converted copy

User · Answer

This is what I did    rename trunk to trunk  create a new folder trunk Re-checkout and interrupt the process after few files are checked-out Move the files from trunk  to trunk Do svn cleanup Do svn update  This will update the status of files and then all your files will be versioned

User · Answer

Same  I needed to update a  contrib  folder    Moved the old folder out   Copied the new one Copied the  svn folders into each  only three in my case  new folder    I my case too the problem was due to deleted  svn folders   Solved

User · Answer

If you get a  not a working copy  when doing a recursive svn cleanup my guess is that you have a directory which should be a working copy  i e  the  svn directory at the top level says so   but it is missing its own  svn directory  In that case  you could try to just remove move that directory and then do a local update  i e  rm -rf content  svn checkout content    If you get a not a working copy error  it means that Subversion cannot find a proper  svn directory in there  Check to see if there is an  svn directory in contents  The ideal solution is a fresh checkout  if possible

User · Answer

I also meet this problem in svn diff operation  it was caused by incorrect file path  you should add      to indicate the current file directory

User · Answer

You must have deleted a SVN - base file from your project  which are read-only files   Due to this you get this error   Check out a fresh project again  merge the changes  if any  of your older SVN project with new one using  Winmerge  and commit the changes in your latest check out

User · Answer

for mac  - take checkout from server side and a new window will open to select directory from your local machine than put your all code in selected folder then open svn local side and add and commit the project

User · Answer

I tried pasting the  svn folder from the sub folder to the root folder  It works

User · Answer

Recently I was using other developers Mac I had the same situation  problem was  first I needed to type get repo path to terminal but I didn t  than it says what is your user name and password

User · Answer

svn  The repository at  svn   repourl reponame foldername  has uuid  m reponame   but the WC has  b5b39681-0ff6-784b-ad26-2846b9ea8e7d    Every subversion repo has a unique identifier  uuid   Subversion uses this to make sure that the repo is actually the same when doing things like switching  You should probably change the uuid on the server to be the same as before

User · Answer

If you created a file inside a new directory  instead of  svn add newdir newfile  use  svn add newdir  because you need to add the directory   All the files inside the directory will be added by default

User · Answer

svn  The repository at  svn   repourl reponame foldername  has uuid  m reponame   but the WC has  b5b39681-0ff6-784b-ad26-2846b9ea8e7d    Every subversion repo has a unique identifier  uuid   Subversion uses this to make sure that the repo is actually the same when doing things like switching  You should probably change the uuid on the server to be the same as before

User · Answer

I just ran into a case where the  svn directory is on a nfs server on a different machine  and the nfs client was not running the file locking service  lockd    svn  E155007    mnt svnworkdir  is not a working copy   This went away once lockd was started on the nfs client host   It seems like subversion could come up with a better error message when it has trouble locking files   This was subversion 1 10 0

User · Answer

If you get a  not a working copy  when doing a recursive svn cleanup my guess is that you have a directory which should be a working copy  i e  the  svn directory at the top level says so   but it is missing its own  svn directory  In that case  you could try to just remove move that directory and then do a local update  i e  rm -rf content  svn checkout content    If you get a not a working copy error  it means that Subversion cannot find a proper  svn directory in there  Check to see if there is an  svn directory in contents  The ideal solution is a fresh checkout  if possible

User · Answer

Workaround  Rename directory which is not  working copy  Checkout update restore this directory again Move files from renamed directory to new Commit changes  Reason  You made some changes to some files under  svn directory  this breaks  working copy

User · Answer

Maybe you just copied tree of folder and trying to add lowest one   SVN          subfolder1                 subfolder2    here you get an error    in that case you have to commit directory on the upper level

User · Answer

You must have deleted a SVN - base file from your project  which are read-only files   Due to this you get this error   Check out a fresh project again  merge the changes  if any  of your older SVN project with new one using  Winmerge  and commit the changes in your latest check out

User · Answer

Could it be a working copy format mismatch  It changed between svn 1 4 and 1 5 and newer tools automatically convert the format  but then the older ones no longer work with the converted copy

User · Answer

for mac  - take checkout from server side and a new window will open to select directory from your local machine than put your all code in selected folder then open svn local side and add and commit the project

User · Answer

Today i have found same issue  FILE NAME  is not a working copy in morning and i have spent more then two hours to solve it  After long of RND and Google i found some solution and that is CHECKOUT    CHECKOUT from SUBVERSION to local as new project  Change some of code in java file and COMMIT the project  It s Works for me    Hope it will helpful for you

User · Answer

I just ran into a case where the  svn directory is on a nfs server on a different machine  and the nfs client was not running the file locking service  lockd    svn  E155007    mnt svnworkdir  is not a working copy   This went away once lockd was started on the nfs client host   It seems like subversion could come up with a better error message when it has trouble locking files   This was subversion 1 10 0

User · Answer

If you get a  not a working copy  when doing a recursive svn cleanup my guess is that you have a directory which should be a working copy  i e  the  svn directory at the top level says so   but it is missing its own  svn directory  In that case  you could try to just remove move that directory and then do a local update  i e  rm -rf content  svn checkout content    If you get a not a working copy error  it means that Subversion cannot find a proper  svn directory in there  Check to see if there is an  svn directory in contents  The ideal solution is a fresh checkout  if possible

User · Answer

I tried pasting the  svn folder from the sub folder to the root folder  It works

User · Answer

I made a new checkout from the same project to a different location then copied the  svn folder from it and replaced with my old  svn folder  After that called the svn update function and everything were synced properly up to date

User · Answer

Workaround  Rename directory which is not  working copy  Checkout update restore this directory again Move files from renamed directory to new Commit changes  Reason  You made some changes to some files under  svn directory  this breaks  working copy

User · Answer

Maybe you just copied tree of folder and trying to add lowest one   SVN          subfolder1                 subfolder2    here you get an error    in that case you have to commit directory on the upper level

User · Answer

svn  The repository at  svn   repourl reponame foldername  has uuid  m reponame   but the WC has  b5b39681-0ff6-784b-ad26-2846b9ea8e7d    Every subversion repo has a unique identifier  uuid   Subversion uses this to make sure that the repo is actually the same when doing things like switching  You should probably change the uuid on the server to be the same as before

User · Answer

JesperE mentions that you need to change the uuid   The following should help you achieve this     On SVN 1 5   you can do svnadmin setuuid  you can then check that it s been set correctly using svnlook uuid  On earlier versions of SVN  it s a harder process  See http   chestofbooks com computers revision-control subversion-svn Managing-Repository-UUIDs-Reposadmin-Maint-Uuids html  Additionally the UUID of  m reponame  looks suspicious  I believe it should be a hex-formatted number like the working copy s  so maybe this action will improve things all round  -    I originally commented on  JesperE s answer  but created this answer to make it more obvious to people and more helpful for Google   I ve since removed my comments

User · Answer

You must have deleted a SVN - base file from your project  which are read-only files   Due to this you get this error   Check out a fresh project again  merge the changes  if any  of your older SVN project with new one using  Winmerge  and commit the changes in your latest check out

User · Answer

Had this same problem  turns out we had Slik 1 6 2 as well as Tortoise on the same machine  Tortoise had been updated  and had updated the working copy  but Slik had not  so Tortoise worked OK  but command lines failed with      svn      is not a working copy directory   Removing both Tortoise and Slik  then reinstalling Tortoise with command line tools enabled fixed this for me

User · Answer

I made a new checkout from the same project to a different location then copied the  svn folder from it and replaced with my old  svn folder  After that called the svn update function and everything were synced properly up to date

User · Answer

svn  The repository at  svn   repourl reponame foldername  has uuid  m reponame   but the WC has  b5b39681-0ff6-784b-ad26-2846b9ea8e7d    Every subversion repo has a unique identifier  uuid   Subversion uses this to make sure that the repo is actually the same when doing things like switching  You should probably change the uuid on the server to be the same as before

User · Answer

JesperE mentions that you need to change the uuid   The following should help you achieve this     On SVN 1 5   you can do svnadmin setuuid  you can then check that it s been set correctly using svnlook uuid  On earlier versions of SVN  it s a harder process  See http   chestofbooks com computers revision-control subversion-svn Managing-Repository-UUIDs-Reposadmin-Maint-Uuids html  Additionally the UUID of  m reponame  looks suspicious  I believe it should be a hex-formatted number like the working copy s  so maybe this action will improve things all round  -    I originally commented on  JesperE s answer  but created this answer to make it more obvious to people and more helpful for Google   I ve since removed my comments

User · Answer

I solved it by   Copy a backup of the impacted folders SVN revert the impacted folders Paste the files back from the backup   In my case the problem was due to deleted  svn-files

User · Answer

Same  I needed to update a  contrib  folder    Moved the old folder out   Copied the new one Copied the  svn folders into each  only three in my case  new folder    I my case too the problem was due to deleted  svn folders   Solved

User · Answer

Workaround  Rename directory which is not  working copy  Checkout update restore this directory again Move files from renamed directory to new Commit changes  Reason  You made some changes to some files under  svn directory  this breaks  working copy

User · Answer

Could it be a working copy format mismatch  It changed between svn 1 4 and 1 5 and newer tools automatically convert the format  but then the older ones no longer work with the converted copy

User · Answer

Workaround  Rename directory which is not  working copy  Checkout update restore this directory again Move files from renamed directory to new Commit changes  Reason  You made some changes to some files under  svn directory  this breaks  working copy

[svn] SVN Error - Not a working copy

Examples related to svn