views:

16725

answers:

11

Im pulling my hair out on this one.

I have a site which is version controlled using SVN, 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 is not a working copy, if I try to do a cleanup then it gives the same error and I found I can manually add each file to version control but this throws the same error. Doing an update doesnt help, refreshing the workspace does not do anything either. Cleanup seems to die after the error and then teh directory is locked.

I know your supposed to add files using svn, but how on earth do you work with generated files? How do I get around this error of is not a working copy directory. How do I get svn to just look at the files and add them to its svn!

A: 

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

Keltia
+4  A: 

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.

Avi
A: 

maybe you are working under UNIX where you have not the right to access the .svn directory in your working directory? (cd .svn)

I can veryfy this behaviour on my plattform

ll -d .svn
drwxrwxrwx (all fine)
drwxrws--- (not allowed to do svn)
Peter Miehle
A: 

Our system uses plugins which are installed through the system. We need everyone to access the generated plugin files so we can all see how they are being added and if its being done correctly etc.

I have tried aptana's team -> add to version control and it just throws the same error. There are a lot of smaller files, is it possible to svn add a whole directory?

Paul M
Try to add to version control from the top-level directory (which is already in version control)
Avi
+4  A: 

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.

jussij
This worked for me, under TortoiseSVN.
neontapir
+7  A: 

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)
Sam
Thanks, this fixed it for me.
kurious
+2  A: 

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.

Durban_legend
A: 

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.

Blaine
+1  A: 

Hi all I ran into this kind of problem.

When I try to run 'svn update', I get

Skipped '.'

and when I try to run 'svn cleanup', I get

svn: '.' is not a working copy directory

I took the advice of some one and deleted the folder .svn in my project but that did not help.

Any help, thanks in advance.

Regards, Jani.

jani
A: 

Hello. well a had the same trouble. i found a very simple solution.

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

This is my environment, win 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 rigth click over my proyect 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.

and that´s it.

Hope can help some one.

OJVM
A: 

EDIT : not the same problem ;)

jhice