Can't copy / move 'XXX.svn-base' to 'XXX.tmp': The system cannot find the file specified.

This error message typically occurs when you try to update your working copy.

The reason for this error is either:

• There are actually 2 different files in the repository whose names differ only in case. This cannot work on a Windows checkout, because the Windows file system is not case-sensitive. It is likely that one of the files got added by mistake, so you need to find out which one, make sure there are no changes committed to the wrong file, then delete it.

or

• There is a file with an illegal (illegal on Windows) filename. For example names like "con", "lpr", "com", etc. are illegal on Windows because those are device names. And of course names with "/\*?:|" and some other special chars in them are also not possible on Windows (NTFS and FAT).

And yes, we know the error message isn't really helpful in this case. But the error message comes from the Subversion library, which we can't change on our own.

There are several ways to solve the problem and to prevent it from happening again. Take a look at these instructions.

Can't open file 'XXX\nnn-n.txn\changes': The process cannot access the file because it is being used by another process

People who report this error often state that it happens randomly, and often part way through a large commit. Retrying the commit may succeed, or it may fail at a different point.

The most likely cause is a virus scanner holding a file handle open when it shouldn't. Try disabling the scanner, or get it to ignore your repository.

Similar errors can occur in your working copy. Try ignoring the .svn folder there.

Failed to add 'XXX': object of the same name already already exists

This error message typically occurs when you try to update your working copy. It is thrown because Subversion never deletes or overwrites existing local data. There may be three reasons why you get this error:

1. You have a local unversioned file with the same name as a file which has been added by somebody else recently. In this case the solution is to move your local file somewhere else (or rename it), then update. Afterwards you can decide whether the two files need to be combined in some way, or if the choice of name is purely coincidental you can give your file a different name.
2. A file has been renamed in the repository, but it differs only in case, like Install.txt to install.txt, and you have local changes. When you update, you end up in a situation (1), where the modified local file appears as unversioned. Move it somewhere else, update, then sort out the mess.
3. There are actually 2 different files in the repository whose names differ only in case. This cannot work on a Windows checkout, because the Windows file system is not case-sensitive. It is likely that one of the files got added by mistake, so you need to find out which one, make sure there are no changes committed to the wrong file, then delete it.

There are several ways to solve the problem and to prevent it from happening again. Take a look at these instructions.

OPTIONS of '<path>': 401 Authorization Required <url>

When upgrading to version 1.4.x, you suddenly can't access your repository anymore. Every try is rejected with the error message:
OPTIONS of 'path': 401 Authorization Required 'url'

The reason for this is the automatic authentication with SSPI which is activated in version 1.4.x. That means TortoiseSVN now tries to authenticate automatically with the credentials of the user logged on to the Windows domain controller.

If you have set up your server to authenticate with SSPI against a domain controller, and the domain controller does not have the user account GUEST enabled, you should be fine. But if the user account GUEST is active, then all authentication succeeds with that user - and you usually won't give the user GUEST access to your repository. That's why the authentication succeeds, but the authorization fails.

Another reason why it can fail is if you have set up different accounts for the repository access than you use for logging in to your workstations (although then I wonder why you are using SSPI authentication in the first place).

To solve this issue you have the following options:

• disable the GUEST account on the domain controller
• use the same accounts for your workstations and access to the repository
• disable SSPI authentication for the repository
• Check the case of the usernames. Changing the usernames in the access files to lowercase also might solve this problem

This client is too old to work with working copy 'XXX'

The full error message is:
This client is too old to work with working copy '.'; please get a newer Subversion client.

You will get this error message once you have used a Subversion client linked with a higher Subversion version, and then try to execute a command with a Subversion client linked with an older version, e.g., you used an 1.4.x client on your working copy, and now you try an svn 1.3.x client on the same working copy.

The reason for this is that Subversion 1.4 and 1.5 upgrade the working copies transparently on every command. But once the working copy format is upgraded, older clients can't access the working copy anymore because they don't know the new format.

The only solution to 'fix' this is to upgrade whatever client you use and that gave you this error message.
Or do a fresh checkout with the older client.

Unknown hostname abc.net

After upgrading TSVN to 1.2.0 from 1.1.7, when I do an update I get "unknown
hostname abc.net". Uninstalled 1.2.0 and reinstalled 1.1.7 and all is well.

Some firewall programs detect program changes and silently disallow access to the network. In this case, fixing ZoneAlarm's settings for TSVN solved the problem.

Working copy is out-of-date

You will get this error message when you are trying to commit changes you made to your working copy. Normally this happens, because somebody else has changed the same file(s) in the repository as you have.

That means you need to use the Update command to update your working copy to the same level as the repository.

It may not be obvious why you need to do this, especially if you know the repository has not changed. The answer is simply that your working copy is not completely updated by a commit. Only changed files and folders get updated automatically. Consider this example on a newly created repository:

Now the repository is at revision 3, but in your working copy the revisions look like this:

Now if you modify File2 and try to commit, it fails. The client tells the repository that File2 is at revision 2 with local modifications, but the repository is already at revision 3. If you then do an update, File2 will be at revision 3 as well (and of course your local changes will still be there).

The same thing may happen if you try to create a branch or tag. The answer is always the same:
If your working copy is out-of-date, update it!

Apache Error Messages

There are many error messages which can be thrown by apache when you try to access your repository. Most of these errors do not have anything to do with TortoiseSVN, but hint at some server misconfiguration. It is also possible that you have simply entered wrong repository URL.

To solve the configuration problems, the FAQ isn't quite the right place, because we need to know a lot more about your server setup. Please come to our mailing list at dev@tortoisesvn.tigris.org and ask your question there. Also, the Subversion mailing list users@subversion.tigris.org might be an even better idea for server configurations.

These error messages hint at configuraton problems:

• '401 Authorization Required'
• '500 Internal Server Error'

SVN+SSH Error Messages