SVN - Not a working copy error

Question

I'm pulling my hair out on this one.

I have a site which is version controlled using Subversion. I use aptana (eclipse, subclipse) to do the svn. I have been checking in and out files, updating etc and everything is fine. However the system we have been building has been adding its own files and folders.

When I try to commit these, it tells me <path> is not a working copy. If I try to do a cleanup then it gives the same error. I found I can manually add each file to version control but this throws the same error. Doing an update doesn't help, refreshing the workspace does not do anything either. Cleanup seems to die after the error and then the directory is locked.

I know you're supposed to add files using SVN, but how on earth do you work with generated files? How do I get around this "<folder> is not a working copy directory" error? How do I get Subversion to just look at the files and add them to its repository?

Monodic

Answer 1

If you want the generated files to be added to SVN, use svn add to recursively add them - this will make sure that all directories are part of the working copy, and all files and directories are added to SVN, and will be committed as part of the next svn commit.

However, often generated files and folders should not be added to SVN, since they are generated from the source files as part of a build. In this case, you should mark the with svn:ignore so that they are not part of the working copy.

Wellington

Answer 2

We had this problem today when I tried to add a folder "A" in which I didn't have write permission (so it couldn't create the A/.svn folder).

Running svn status gave me a "~" next to folder A. Running svn cleanup said that parent of A was locked.

What ended up working was:

cp -r A A~    # backup, since A was not in the repo
rm -rf A      # removed locked directory
svn rm A      # remove A from pending commit
mv ~A A       # restore backup
svn add A     # re-add to pending commit
svn cleanup   # (had to cleanup several parent folders higher as well)

Kovach

This didn't work for me on the first try. The second try, I added an svn commit after the svn rm, and that seemed to do the trick. Thanks for the tip! +1. – Midis

Answer 3

The not a working copy error means that the current folder has not been correctly initialised by SVN.

To fix the error just rename the current folder and then get a proper working copy of the project from SVN by doing a checkout of the project.

The check out will then create a properly configured working copy of that project.

Veriee

Answer 4

I just encountered the "not a working copy" error in my, ahem, working copy. This was for a JDeveloper project and it turned out that the JDeveloper upgrade (11.1.1.2.0) that I'd just installed incorporated a later version of SVNKit than the one I use for command-line SVN access (jsvn). So JDeveloper had quietly upgraded the format of the .svn files, which meant that the command-line client couldn't understand them. The penny dropped when jsvn complained about a missing file ".svn/format" in my project's top-level directory. I found heaps of these in subfolders, all looking identical and containing only the digit "9". So I copied one into the top-level folder and jsvn then finally gave an appropriate message: "svn: This client is too old to work with working copy '.'; please get a newer Subversion client". Once I had identified (via Google) and installed the compatible client SVNKit level, the new improved jsvn was able to recognise that my working copy IS in fact a working copy. Moral of story: if you get this error and you're using different SVN clients on the same machine, the problem may be that they've got out of sync.

Outcome

Answer 5

Ran into this now using TortoiseSVN cleaning up some dead directories. I made a backup of the files and then used the rep browser to delete the faulty dir (which was a goner anyways). Then cleanup on the project worked and I can now keep going with my current files.

Verdi

Answer 6

Please try to find out where the problem is . Is this the missing .svn file or something else. Remember .svn file is created when you are done with your checkin. and contains the corresponding directory path, code names with a unique number tagged to them. Go to the base path of your project you think is checked in perfectly. Create a new temporary package and added a sample java code in that path. Add to the version and try to commit. If you get an error saying that the folder is locked(Attempting to lock the already locked folder), then go the .svn folder and rename the lock file. Try again to checkin and commit

If it works fine, then you are done. Use the same base directory and checkin your code again onwards from that directory to your folder level after cleaing up.

Milling

Answer 7

"Not a working copy" means that one of the places where your IDE is trying to run svn into is not controlled by svn itself (like adding files in a sub-directory not under svn). I'd say check your paths within the IDE.

Riordan

Answer 8

Because I do every tasks with visual tools, I can´t tell you what commands need to be executed.

This is my environment, Windows XP. tortoiseSVN 1.6.7 with Subversion 1.6.9, Eclipse 3.5 with Subclipse 1.6.10. and the repository is managed with visual SVN server over windows.

1. In visual svn server I deleted the folder that was created by the other tool (this was the problem, just like Keltia said).
2. In my windows explorer right click over my project and with the options of tortoise SVN press update. With this action the folder was deleted in my working copy.
3. Commited all my changes.
4. ran the tool that create the folder (again).
5. with tortoise SVN I marked with add to ignore list.

Hope this helps.

Yarmouth

Answer 9

in my case I move eclipse workspace place to another then problem is occured. For solving problem I checkout project form the svn repo. Then in old project I clean all svn files. (simple search .svn and delete ) then I copy the content to the just checkedout one my changes become visible and my project is up to date. This method can be applied for other annoying errors. Hope help someone

Dimmer

Answer 10

please move current directory in another location, and execute svn update command , then replace directory with moved directory
if use tortoisteSVN, you can before run svn update , run cleanup you root directory

Unseasonable