This project is read-only.

Troubleshooting "x is not a working directory" issue

Mar 29, 2010 at 6:03 PM

I am getting "x is not a working directory" when using this import tool. I have tried it on several projects with the same result. It occurs in the same place but I am unsure the logic behind this particular piece of code so I am hesitant to change it.

svnClient.GetInfo(SvnTarget.FromString(dir), out infoEventArgs);

The code creates the project directory structure in the specified temp folder and then does a svn GetInfo on it. Since the directory is not in svn yet it seems to throw this error. Am I reading this wrong?

Also, the latest code for vssmigrate and the patch do not match. Hopefully this is not a stupid question but isn't the patch already included in the latest code? It seems at least some tagging support is in the source but it is not the same as what is in the patch.

Mar 29, 2010 at 8:29 PM

Hello mdutra, i did not simply patch the source with the patches from the patch section, but implemented it in a more sophisticated way. The source url is generated dynamically from the labels in VSS, and not simply a tag of the whole svn repository as proposed in the patch. Nevertheless i read through the code and took over some smaller parts, so, as matter of fact, neither "applied" nor "declined" is the right term here ;). Furthermore there is duplicate label handling and so on ...

The only things not implemented in the main version from the patches section as of now is pinning (newest version in svn is always the pinned version from vss) and "always get latest version" (a similiar thing). There is no real need to apply patches as of now.



Jul 16, 2010 at 12:43 PM
Edited Jul 16, 2010 at 12:47 PM

mdutra, did you ever get your problem solved? I'm having almost the same issue as you have, except my error is cause by the svnClient.GetStatus(filePath, out svnStatus); -line in the GetFileVersion-method. Calling the method throws a "x is not a working directory" -error.

I think that the problem is somehow related to the .svn-folders. In my case my project contains ~50 different folders but the VssMigrate-tool only creates one .svn-folder into the root project folder. For example:

My folder structure looks like this:

The tool only creates the .svn folder to the root:

When the code calls svnClient.GetStatus for Server.OneThing\myfile.cs, it throws the "x is not a working directory" -error. If I copy the .svn-folder manually from root project folder to the Server.OneThing -folder, the exception is not thrown.

May 8, 2012 at 4:03 AM
Edited May 17, 2012 at 12:23 AM

While I realize this thread is a bit old, I do have some insight for those who might be following it through subscriptions or might stumble across it.

This error occurs when a file path being migrated to SVN from VSS includes an intermediate folder between the project root and the file itself that has been created on the client, but not updated to SVN. When an attempt is made to call the Status() method against the file, SVN interprets the request as arising from a folder that doesn't exist in the project, and is not an independent project, and with no local .svn folder on the client, returns the "xxx is not a working copy" error.

For example, from the VSS side:


causes VSSMigrate to create


When VSSMigrate calls the Status() method for this local file, its premature because the "Folder" component exists only on the local client (checkout folder). As a result, because Folder is neither an independent project with its own hidden .svn file structure, nor has it been properly COMMITed back to SVN, Subversion throws the "File.txt is not a working copy" error. The solution is to ensure all intermediate paths between the project root and the file name have been updated back to SVN before calling Status.. I'm working on this problem myself, and expect that the solution would be to call Update against the project root before Status() is called.

My only concern is that the real issue should be that the "Folder" folder should be called as a separate creation (as a folder) back to SVN before any files are migrated, and the real fix might be to ensure the file/folder lists are being created properly.


EDIT: Corrected some errant terminology

Dec 3, 2014 at 2:53 PM
We are way behind on porting our legacy VSS projects to SVN. :)

Recently, while migrating one of our larger VSS projects, I also ran into this issue. I handled it by first creating the empty SVN repo, then creating all of the folders in that project locally, and then committing to SVN. I then ran the migration, and it did not throw this error because all of the folders already existed in SVN.

Perhaps David, or others were able to modify the code to overcome this issue. I simply did not have the time to do that. If you are pressed for time, I encourage you to try my workaround.