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?

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

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

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

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

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

View more solutions

Comments

[jwismar]

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.