When upgrading TortoiseSVN, do I have to uninstall the existing version first?

No. You can just install the new version over the old one. The installer will take care of uninstalling the old version first automatically. But you must reboot your computer after the installer finishes! Or at least you have to log off and log on again.

Do I need Admin privileges to install TortoiseSVN?

Yes, you need to have Admin privileges to install TortoiseSVN, or at least have the rights to install with Admin privileges.

But after TortoiseSVN has been installed, you can use it without having Admin privileges.

Do I need to install Subversion before I can use TortoiseSVN?

No. TortoiseSVN comes with everything you need to access a repository. Only if you want to set up a server then you will need the Subversion package.

How do I uninstall TortoiseSVN?

Simply uninstall from Add/Remove Programs in the Windows control panel. This does not affect your repositories or working copies at all.

MSI installation is disabled on my machine. Is there a .exe installer?

An exe installation file wouldn't help. If MSI installation is really disabled on your machine, then you don't have ADMIN privileges either. And you would need those to install TortoiseSVN (shell extensions require ADMIN rights to install). But first make sure that MSI installation is really disabled - that can only be if your domain administrator disabled it.

Why are you using MSI instead of an exe or no installer at all?

There are several reasons why we use MSI as our installer instead of something else:

• It's open. Everybody can see what we're doing by using MSI tools like Orca.
• It's easy to adjust an existing MSI for your special needs if you like. There are tools with which you can edit an MSI manually. You can't do that with an exe installer.
• It runs with SYSTEM privileges, not just as e.g. Administrator. That's important because TortoiseSVN is a shell extension which requires us to create and modify registry keys which aren't accessible to user accounts (this is especially important on Vista with UAC enabled).
• It's easy to distribute an MSI to multiple computers/users in a domain via GPO's. All other installers would require a domain admin to first 'wrap' that installer inside an MSI to do that.
• MSI is the standard and recommended way of installing Windows applications. It's even required now to get the "Certified for Vista" logo from Microsoft.
• There's a great open source tool for creating MSI files: WiX which we use.
• MSI takes care of reference counting of installed modules which prevents the so called dll hell.
• an installer is required since we have to register TortoiseSVN with the shell. A simple exe for you to run wouldn't work.

The installer aborts with an error message

There are several reasons why the installation cannot succeed:

• "This installation package is not supported by this processor type. Contact your product vendor." This means you are trying to install the 64-bit version of TortoiseSVN on a normal 32-bit operating system. You need to download and use the correct MSI file for your OS. For normal 32-bit OS, make sure the MSI file does not have an x64 in it.
• "The installer was interrupted before TortoiseSVN could be installed. You need to restart the installer to try again"Then the user SYSTEM doesn't have read/execution rights in the folder where the installer MSI is located. Either move the MSI file to another location or give the user SYSTEM read and execution rights.
• "The Windows installer service could not be accessed" This can occur if you are running Windows in safe mode, or if the windows installer is not correctly installed. Basically, check that the folder where the MSI is stored isn't encrypted or compressed
• "The system can not open the device of file specified", followed usually by "The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2755". This can happen if:
  • The installation does not have access to the Temp directory or if the default Temp directory of the machine is not clean or does not have enough space to run the setup.
  • The installation is being run over a terminal Server via a mapped network drive.
  • The installation is unable to create or write to the Installer directory in a Windows NT system environment.
  • The temp folder and/or the MSI file is encrypted/compressed
  To solve this problem, clear the temp folder, move the installer MSI file to your local harddrive where the user SYSTEM has full access rights.
• "This installation package cannot be installed by the Windows Installer service. You must install a Windows service pack that contains a newer version of the Windows Installer service. You need at least version 3 of the MSI installer.

After installing, TortoiseSVN does not show up, no context menus are available

Make sure you have installed the x64 version of TortoiseSVN if you're using XP or Vista 64-bit. Since the explorer on those OS versions is a 64-bit application, it can not load the 32-bit version of TortoiseSVN.

You can still keep the 32-bit version of TortoiseSVN installed on those OS versions though: it will show up in the 32-bit applications file-open/save dialogs of those applications.

After installing, there is no TortoiseSVN context menu for files

This problem may be caused by permission settings in registry. Try the following:

1. Go to registry editor using regedit.
2. Click on HKEY_CLASSES_ROOT/*/​shellex/ContextMenuH​andlers/TortoiseSVN
3. Observe error message box saying access is denied.
4. Right click on the key mentioned above, go to "Permissions"...
5. In the permission dialog, click on "Advanced"
6. Click on "Owner" tab, click on your account and click "Apply"
7. OK the dialog, click on "Add..."
8. Enter your account name in the text area and click "OK"
9. OK the permission dialog.
10. Click on HKEY_CLASSES_ROOT/*/​shellex/ContextMenuH​andlers/TortoiseSVN
11. Check there is NO error message box.

If you have problems with insufficient permissions to edit the registry you can work around it by downloading SysInternals PsTools Suite and launching regedit with the following command:

After upgrading TortoiseSVN, all my icon overlays have disappeared

This is a known issue with some upgrades, and in particular it has been reported for 1.6.8. If this happens to you, try doing a repair install (and reboot of course).

• Why don't the icon overlays appear?
• The overlay icons appear, but not all of them!

Why don't the icon overlays appear?

• You rebooted your PC of course after the installation? If you haven't please do so now. TortoiseSVN is a Windows Explorer Shell extension and will be loaded together with Explorer.
• Go to the settings of TSVN and activate the icon overlays for at least the fixed drives. The installer does this automatically for the current user (can't do it for other users...) but since you are using TSVN as a different user than you installed it you need to set this manually.

The overlay icons appear, but not all of them!

You may find that not all of these icons are used on your system. This is because the number of overlays allowed by Windows is limited to 15. Windows uses 4 of those, and the remaining 11 can be used by other applications. And if you have OneDrive installed, that uses another 5 slots. If you then have another cloud drive tool installed, those slots can be used up. TortoiseSVN tries to be a "Good Citizen (TM)"? and limits its use of overlays to give other apps a chance.

• Normal, Modified and Conflicted are always loaded and visible (if possible!).
• Deleted is loaded if possible, but falls back to Modified if there are not enough slots.
• ReadOnly is loaded if possible, but falls back to Normal if there are not enough slots.
• Locked is only loaded if there are less than 13 overlays already loaded. It falls back to Normal if there are not enough slots.
• Added is only loaded if there are less than 14 overlays already loaded. It falls back to Modified if there are not enough slots.

You can check which other apps are using overlays by using regedit to look at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers

• Windows itself. Vista and Win7 use more than XP.
• OneDrive
• GDrive
• Mega
• Dropbox
• many others

If there are too many overlay handlers installed and TortoiseSVN does not show any overlays, you can try to delete some of the installed handlers from the registry. But be careful when editing the registry!

Why are the icons only visible on local and not on network drives?

Go to the Settings -> Look and Feel -> Icon Overlays and check the drive types for which you want to see overlay icons. Be aware that enabling overlays for network drives will slow down not only TortoiseSVN but the whole system.

Why are the overlay icons on SUBSTed drives messed up?

If your working copy is on a SUBST drive the icons might be mixed up.

The problem arises because the cache tries to fetch the status for two "different" locations at the same time, but those locations are actually the same so there are two status fetchings for the same working copy at the same time.

There is an easy way to solve this: just exclude the original path from showing overlays (settings->icon overlays->exclude paths).

For example, if you have mapped \\station\folder\wc to g: then put \\station\folder\wc* as the exclude pattern.

Another way to make the overlays work is to set the "Status cache" setting from "Default" to "Shell".

Why are the overlays showing the wrong status?

Sometimes you find that the overlays don't reflect the real status of files and/or folders. Usually, hitting the F5 key is enough to make the overlays appear correctly (you might have to wait a few seconds until the cache has fetched the status again).

The treeview on the left side of the explorer is a whole other story. It won't update the overlays, no matter how many times you hit the F5 key. That's a problem with the explorer and outside of TortoiseSVN's reach.

A short explanation: The treeview always shows the whole explorer tree, including network drives and other namespace extensions. Since these can be very slow (e.g. slow network drives), the explorer tree doesn't ask the overlay extensions for updated overlays all the time. Even if you tell the explorer that a folder has changed and it should update the overlays accordingly, it doesn't do so. It first checks itself if the folder really has changed and only updates the overlays if it thinks the folder really has changed.

Now, since the Subversion status of a folder has nothing to do with the folder itself, the folder itself never really changes (only some file inside the .svn folder, but not the folder itself), explorer therefore doesn't update the overlays.

There are some tricks and workarounds to make the explorer refresh the overlays even on the left treeview, but those are tricks and workarounds, which obviously don't work all the time.

There's one trick that usually works, but it is slow and TortoiseSVN can't use that trick on-the-fly - it just would slow down the system too much. But you can trigger that trick manually by executing the 'cleanup' command on the root of your working copy. After the cleanup command has finished, you have to wait a few seconds for the treeview to update the overlay icons.

Why do the overlay icons sometimes change to random graphics?

The Windows icon cache is a fairly buggy creature. You can solve this in one of the following ways:

• Install Microsoft's TweakUI and run the option to rebuild icons.
• Or increase the icon cache size. Go to HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer and add a new String Value called Max Cached Icons. The default value is 500 - try increasing it to 2048.
• Or delete the file called ShellIconCache in your Windows directory. And reboot.
• With TortoiseSVN 1.3.0 and later, you can also rebuild the icon cache by calling TortoiseProc from the command line like this TortoiseProc.exe /command:rebuildiconcache

Why is there no overlay for 'update available' or 'locked by others'?

To show such an overlay, TortoiseSVN would have to contact the repository every time the overlay is shown. That would make explorer impossibly slow. Servers often take several seconds to respond, sometimes minutes - do you really want explorer to hang while that takes place, every time you open a versioned folder?

A fundamental design feature of TortoiseSVN is that the repository is never contacted except when explicitly requested by one of the context menu items. Even with that restriction, it is still hard work maintaining a fast response.

If you want to see which users have files locked in their working copies or which files need updating, use the Check for Modifications dialog and click on the Check repository button.

100% CPU, when I right-click on a file.

Every time I right click on a file, the CPU goes to 100% (whilst the right click menu is displayed.) If I select something from the menu, CPU goes back to normal. If I right click on 'nothing' then the CPU is OK. What is happening?

XP contains a known bug that causes the CPU usage to spike to 100 percent when you access the context menu under certain configurations. This bug causes file-copy operations to halt, network connections to slow, and streaming media (e.g., audio, video) to become distorted. To work around this bug, you need to disable the GUI's transition effects by performing the following steps:

1. Start the Control Panel Display applet.
2. Select the Appearance tab.
3. Click Effects, then clear the "Use the following transition effect for menus and tooltips" check box.
4. Click OK to close all dialog boxes.

Another solution that often works is to left-click the file or folder before right-clicking to display the context menu.

Can I create a local repository on a network directory?

You can use a repository on a network share, but only as a single user as you would use a local hard drive. The next FAQ item explains why sharing a repository in this way is a Bad Idea (TM). Unless you have really pressing reasons to keep your repository on a network share it is generally best to avoid doing so.

If you really need to access a repository on a network share you should do one of the following:

1. Use drive mapping using the syntax below:

   Map //server/shared to S:

   file:///S:/repos (3 leading slashes before drive letter)

2. Specify a UNC path directly using the syntax below:

   Subversion >= 1.2

   file://server/shared/repos (2 leading slashes)

   Subversion < 1.2 (strange syntax, we know)

   file://///server/shared/repos (5 leading slashes)

   file:///\server/shared/repos (3 slashes + backslash)

But don't say we didn't warn you...

Can I keep my repository on a network share instead of setting up a server?

If you need multiple computers to access the repository, you can in theory create a repository on a network share and access it using file:// protocol. In practice this is not recommended for four very good reasons:

1. You are giving direct write access to all users, so they could accidentally delete or corrupt the repository file system.
2. Not all network file sharing protocols support the locking that Subversion requires. One day you will find your repository has been subtly corrupted.
3. You have to set the access permissions in just the right way. SAMBA is particularly difficult in this respect.
4. If one person installs a newer version of the client which upgrades the repository format, then everyone else will be unable to access the repository until they also upgrade to the new client version.

By far the best way is to set up a real server process (such as Apache or svnserve), store the repository on a local filesystem which the server can access, and make the repository server available over a network. It is easier than you might think. Chapter 6, Server Configuration in the Subversion Book covers this process in detail.

Can I store a working copy on a network share?

This depends on the network share. But we really, really urge you to not do this! Even if you're using a Windows server and use those network shares, the fcntl() file locking is not fully reliable. And for Samba based shares all bets are off. Which means you will get a corrupted working copy and you then will lose data! Maybe not today, maybe not tomorrow, but someday you will.

If you really must store a working copy on a network share, have a close look at the corresponding FAQ entry of the SQLite project.

Can I use different Subversion clients with the same working copy?

Yes, you can change from one client to another whenever you want. The clients just control your working copy and the interaction between your working copy and the repository. The metadata inside the working copies used by the different clients is identical.

But you can only use different clients if they all use the same version of the Subversion library. The version of the Subversion library that TortoiseSVN uses is indicated in the filename of the installer, other clients have similar indications. You have to make sure that those versions match each other in the first two digits. For example, all clients using Subversion 1.6.x can be used together (the 'x' indicates that this number is not relevant for compatibility).

You must also be sure that all the clients are built for the same OS. Client compatibility is only guaranteed for a particular OS type and metadata representations may differ. You must not use a native Windows client and the Cygwin client on the same working copy. And if you share a working copy over a network you must not use a Linux and a Windows client on the same working copy.

Can TortoiseSVN convert line breaks in text files on the fly?

Check the subversion book about the svn:eol-style property here. If you set that property to e.g. 'native', then the file will have LF line-endings on Linux, but CRLF line-endings on Windows. To see how you can set those properties with TortoiseSVN, read our docs here.

How do I find out what the conflict is when it is in a directory's property list?

Inside the folder with the conflicting properties, you'll find a file called dir_conflicts.prej. Open that file in a text editor and you will see the conflicting properties. Choose the one you want to keep and overwrite the conflicting property with that one.

I accidentally removed a file. How do I get it back?

If you haven't committed your changes yet, you can do a revert on the parent folder where you deleted the file or directory.

If you have already committed the deleted file, then you can use the repository browser, change to the revision where the file still existed and then use the command Copy to... from the context menu. Enter the path to your working copy as the target and the deleted file will be copied from the repository to your working copy.

You can also restore a deleted directory using this technique.

If, after the file / folder has been restored using this trick, the log dialog doesn't show you the history of that file, don't worry. The history is still there. If you copy a file in SVN you copy its history too. But the default setting in TSVN's ShowLog is to 'Stop on copy', which means that when you look at the history, it only goes back to the branch point. The reason for this is that when you are looking at a real branch of a project, mostly you only want to see the history of that branch. To see the whole history in ShowLog you need to unselect the 'Stop on copy' checkbox and click on 'Get All'.

I get multiple TortoiseSVN context menu entries when I right click on a link!

This is by design. One entry is for the link itself (the .lnk-file), the other for the target the link points to. This way a link can both be versioned and in the same time work as a link should by allowing operations on its target. In fact, you can have up to three entries in the file menu (the context menu will show only two).

Is it possible to use 'Shared Files' like in Visual Source Safe?

Yes, but with some limitations. You can use "File Externals" to pull in single files from a different part of the same repository as your working copy, but not from a foreign repository. You can also share folders, and these can be from any repository. Please look at the chapter External Definitions in the Subversion Book.

Is it possible to use TortoiseSVN without a server?

Yes, it is. You can use the file:// protocol to access your repository locally. However we strongly recommend that you do this only for testing. For a more detailed explanation please refer to this FAQ entry.

Is there a way to send username & password when using TortoiseProc?

TortoiseSVN is a GUI client, therefore it will ask you for username and password in case it's needed. If you want to automate access to your repository without user interaction (i.e. without having to enter username and password if needed), use the command line client.

How does the revision graph work?

The revision graph is a little bit special, it's not like the other features found in TortoiseSVN. It shows a graph of a file or folder through the history with all the revision where the file or folder was copied, moved, branched or tagged.

We often get people asking questions why it needs to get the log for the repository root, or why it needs to get the full log from the HEAD revision back down to the first revision.

Just to make this clear: this is not because we're lazy programmers, it really is necessary.

The revision graph shows the history of a selected file or folder by finding all revisions where the selected item was copied. And the graph has to do that by using the information that is available.

If you look at the log messages for your selected file or folder, you can see in the lower pane of the log dialog all affected paths of the selected revision. That information is what we use for the revision graph. You will also notice that if you just show the log for e.g. /trunk, you won't see any entries in the log dialog for revisions which happened in a tag or branch. You won't even see an entry where you tagged or branched /trunk itself in that log. --> that's why we must fetch the log for the repository root: only the log of the repository root will give us all the information we need, including when and where a path has been copied/branched/tagged/moved to.

If we would only fetch the log for a specific range and not all revisions, we could miss the revision where (still using the example above with /trunk) the trunk was branched or tagged. And even though there are changes to those branches and tags or they still exist in the revision range, the graph could not know that those branches/tags were made from /trunk and not from some other path. That means, the graph would not just be incomplete, it would be wrong.

And no: we will never change that. Because there's nothing worse than a graph that's only sometimes correct - you would never know when and if it is correct, which means it would be worse than useless.

Why is there no 'author' shown in the logs when I commit changes via svn+ssh?

Since SSH completely takes care of the authentication process, Subversion won't even see the author who does the commit. So to tell Subversion an author you have to specify the author in the URL itself. E.g. svn+ssh://[email protected]. You should do that when you check out your working copy.

Why does TortoiseSVN not recognize that a file has been modified?

If you have modified a file, but TortoiseSVN does not recognize that the file has been modified, please first check whether the file really differs from what you have in your working copy.

If you know for sure that the file has modifications and it still does not show up as modified in the commit dialog, make sure that

• the file 'last modification' date has changed (some tools like hex editors like to reset that time)
• if the svn:eol-style property is set and the changes are only to newlines, the file won't show up as modified because for Subversion it hasn't changed

Subversion determines whether a file has changed with the following approach:

1. has the 'last modification' date and/or the file size changed?
2. if not: file is not modified
3. if yes: compare file content with the BASE file
4. stop at the first byte that differs, mark the file as modified
5. if no byte differs regarding to BASE, mark the file as not-modified

When I remove a file it vanishes, how do I commit it?

Easy, you commit the whole directory! Right-click in the Explorer window next to the file, and choose commit. The commit dialog will show you every modification as well as added or deleted files.

Permission problems with working copies on a SAMBA share.

After upgrading to TortoiseSVN 1.5.x or later, you get a lot of "Access denied" errors for most of the Subversion commands if your working copy is stored on a SAMBA share.

Some users reported that the problem went away after they upgraded SAMBA to the latest version. If that does not help or you can't upgrade, allow readonly files to be deleted in the SAMBA config file:

[global]
delete readonly = yes

[global]
create mask = 0644
force create mode = 0600
security mask = 0555
force security mode = 0600

The information we have received suggests that the main problem is fixed in SAMBA 3.2.3. There is a supplementary problem with making files with the svn:needs-lock property read-only. This is reported to be fixed in SAMBA 3.2.6 or 3.3.0.

Browsing very slow in explorer and file/open dialog.

If you have mapped network drives which are not resolved, either because the drive is inaccessible, or you have not logged in, file browsing may become unresponsive while Windows tries unsuccessfully to access the drive. Either unmap the drive or ensure that it can be accessed.

The bugtraq: properties don't work for dialogs started from the repository browser.

This is by design. The repository browser does not read the properties, because that is a very slow operation if done remotely. It's only fast enough when read from a local working copy.

If TortoiseSVN would read those properties directly from the repository, it could take several seconds (even minutes!) to fetch them.

Showing the log often crashes.

The log cache relies on all repositories having different uuids. A detailed explanation about why and what you can do about this is here: https://tortoisesvn.net/logcacheuuids.html.

We're aware that many Subversion hosting companies made the mistake of not creating new repositories for customers but simply copied a template repository. If you're using such a hoster, please tell them to fix this problem.

When I update a working copy, new files are not added!

Between TortoiseSVN 1.6.0 and 1.6.1, added folders were added with a depth of "Only this item". This lead to a so called "sparse checkout" of that part of your working copy.

Please update to the latest version of TortoiseSVN to avoid such problems in the future.

To fix your sparse working copy, instead of "Update", use the "Update to revision..." command from the TortoiseSVN submenu (right-click in explorer), change the "Update depth" combobox to "Fully recursive".

I was told that issue/bug X was fixed in rXXX, but the latest release still doesn't have this implemented/fixed?

Our release policy is to never introduce new features or resource changes on the stable branch. We work on the trunk, where we fix bugs, introduce new features or change the behavior of features. Only important bugfixes are merged back to the stable branch, and the stable branch is where we create our releases from.

We have this policy to prevent getting new bugs into the stable branch. After all, it's called the stable branch.

Your requested feature/reported bug, even though it is fixed/implemented on trunk was not merged back to the stable branch due to this policy. That's why you don't see the change in the latest release.

You can use a nightly build if you feel adventurous though: https://nightlybuilds.tortoisesvn.net/latest/

TortoiseSVN does not work well with Eclipse

Eclipse copies directories as part of its normal operation, and in a subversion working copy it will copy the .svn directory as well. This causes TortoiseSVN to think that there are versioned files in the bin directory.

If you want to keep using TortoiseSVN and just prevent this from happening, you need to add '**/.svn/' to Eclipse's source exclude list.

But Eclipse has its very own subversion plugin called Subclipse, which makes Eclipse SVN-aware and fixes the problem at source. You can find it at https://github.com/subclipse/subclipse. After you install Subclipse you need to make a fresh checkout. It will not fix checkouts that were made before it was installed.

Security warnings when uploading files in Internet Explorer

When you select files to upload using a web form in Internet Explorer, you may get security warnings saying that a program is trying to open web content, identifying TortoiseSVN as the culprit.

Don't panic! This is a (mis) feature of the Internet Explorer security model. Since TortoiseSVN is a shell extension it loads automatically whenever a file-open dialog is created, in order to provide the icon overlays and context menus.
There are two ways to stop the warnings:

1. In TortoiseSVN's settings go to the Icon Overlay section and check the box Show overlays and context menu only in Explorer.
2. When the warning appears, check the box marked never show for this application again.

Repeated dialogs to insert smart card

If you're using a smart card software, you might get a dialog asking you to insert your smart card every time TortoiseSVN tries to connect to a repository.

Unfortunately some smart card vendors consider this not a bug but a feature, even though it doesn't server any purpose other than annoying users.

To prevent TortoiseSVN from trying to access the Windows cert store in case a certificate is requested by the repository, create the registry key HKCU\Software\TortoiseSVN\OpenSSLCapi as a DWORD and set its value to 0.

"compare with working copy" does not use the configured diff viewer

When you run a "compare with working copy" from the log dialog, TortoiseMerge is started even if you have configured a different diff viewer tool to be used.

This is not a bug: this command does not compare two files even though it may appear like it. It actually creates a patch file and then starts TortoiseMerge to show what applying that patch file to the working copy would look like. And since we don't know of any other UI tool that can apply patch files, TortoiseMerge is started. Your configured diff viewer can not do that.

Where are the debug symbols?

All debug symbols, both for the official releases and the nightly builds are hosted on DrDump.com

To access the debug symbols, configure your debugger to use the symbol server at https://www.crash-server.com:8080/public/tsvn/71040F62-F78A-4953-B5B3-5C148349FED7/symsrv

To figure out how to use a debug symbol server, have look at this article.

... add keyword information like author, revision, date and commit-time to my files?

Read about the Subversion property svn:keywords in the Subversion book.

With TortoiseSVN, set the properties as described here.

... change the case of a filename?

Subversion is designed to work with case-sensitive file systems such as are used on Linux. When it comes to the Windows case-insensitive file system, things do not always run as you might expect. A case in point is renaming a file where only the case changes, e.g. renaming Makefile to MAKEFILE. Prior to Subversion 1.7 you could not do this easily within your working copy as Subversion required both names to exist simultaneously for a short time, and Windows cannot support this.

By far the easiest way is to rename directly using the repository browser:

1. Commit the changes in your working copy.
2. Rename the file from UPPERcase to upperCASE directly in the repository using the repository browser.
3. Update your working copy.

As of Subversion 1.7 this is no longer a problem as the whole working copy structure was changed, so files can simply be renamed using the normal TSVN->Rename command.

... change the log message or author after committing?

Call up the log dialog and do a Right-Click on the revision you want to edit. Then select "change author" or "change log message" from the context menu. To make the server accept these changes, a pre-revprop-change hook, that allows to change author or message, has to be installed for the repository. The default installation rejects changes to author and log message.

... clear the drop-down lists in TortoiseSVN?

You can clear all the stored data from the settings dialog of TortoiseSVN. Just click on the corresponding button.

Single items can be permanently removed from drop-down lists by pressing Shift-Delete.

... completely remove a repository from my computer?

Aehemm: select the folder and hit Delete (the key on your keyboard may be labelled only Del).

Seriously, there are no hidden files or settings. The repository is completely contained in one folder tree.

The same applies to working copies. If you send a working copy to the recycle bin it can seriously slow down future deletes because of the large number of small files. You may want to empty the recycle bin soon after.

... export the log out to a text file?

Use the log dialog. Select all the entries you want and press Ctrl+C. Then use Ctrl+V (or paste) in your favourite text editor.

If you want to process the log messages automatically or you need them in xml format, you can use the command line client for that.

... get the project revision number into my project?

If you want the revision number in your program version number, you need an additional tool to do that. You can find the tool SubWCRev.exe on the download page on our website or in your TortoiseSVN Folder under bin.

This tool traverses your whole working copy for the most recent revision. Once that revision is found, it replaces all occurrences of the following strings:

$WCREV$

This string will be replaced by the revision number of your working copy.

WCMODS?Modified:Not modified$

If you have local modifications, the string between question mark and colon will be inserted. If you have no local modifications, the string between colon and dollar sign will be inserted. In our example above Modified or Not modified.

$WCDATE$

Will be replaced by the date of the highest revision in your working copy.

As an example, have a look at the file version.in in the TortoiseSVN source tree. This file is used in TortoiseSVN and its resource files. The SubWCRev.exe tool is called from the build script like this: SubWCRev.exe path\\to\\working\\copy version.in version.h This creates a new file version.h with all the strings above replaced with the values of the working copy. The version.h file is then used in the project itself and included in the resource files for the version information.

... prevent Subversion from doing automatic merges?

Some people don't like the fact that Subversion merges changes from others with their own local working copy changes automatically on update. Here's how to force those files into a conflicted state so you can merge manually at your convenience.

1. In TortoiseSVN->Settings->Subversion configuration file, click on the edit button.
2. Change the [helpers] section by adding the two lines

   diff-cmd = "C:\\false.bat"
   diff3-cmd = "C:\\false.bat"

   (note the double backslash)
3. Create the file C:\false.bat which contains two lines

   @type %9
   @exit 1

This effectively makes auto-merge fail every time, forcing the file into conflict.

The reason for the curious 'type %9' line is that the diff3-cmd sends the merged output to stdout. Subversion then takes this and overwrites your local file with the merge results. Adding this line avoids getting an empty local file.

... see what my current sandbox/repository is?

Right-click on the folder in your working copy, choose "Properties" from the explorer context menu. Then, in the properties dialog, switch to the "Subversion" tab. There you can see all sorts of information about the selected folder, including to what URL it points to.

Another quick way of seeing this information is to select "Relocate" from the context menu and look at the first URL. Since you don't want to relocate your WC, just abort this dialog.

... install TortoiseSVN silently/automatically?

Just start the MSI installer like this:

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.
• 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 move '.svn/tmp/entries' to '.svn/entries': The file or directory is corrupted and unreadable.

This error message typically occurs when you try to update or commit your working copy, and seems to be common on Windows 7 systems. It is due to another process holding a handle on a file that Subversion needs to move or modify. This might be a virus scanner. Configure the virus scanner so that your working copies and repositories are excluded from being scanned.

Note: there's a bug in Win7 which causes this error message to appear a lot more than necessary. The bug is fixed with service pack 1. See this post for details.

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

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

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:

Add Folder in revision 1
Add File1 and File2 in revision 2
Modify File1 and commit in revision 3

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

Folder       : revision 1
Folder/File1 : revision 3
Folder/File2 : revision 2

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!

Unable to write to Standard output

TortoisePlink uses the standard plink code, but is compiled as a Windowless app, so there's nowhere to send the error messages to. In TSVN settings->network, set the SSH client box to use standard plink, where the error messages are displayed in a command box. Once that is working, use TortoisePlink with the same parameters.

"could not write to standard output" means that Plink wanted to throw an error, but since TortoisePlink doesn't provide a DOS-box there's no standard output to write the error message to.

So something with the setup is wrong. Try with the normal plink program and see there what error message really is thrown and then fix the setup.

If normal plink just hangs, then the wrong params are passed to it (settings dialog, network tab).

Another possibility is that the SSH daemon is most likely not able to find the svnserve binary. Login with your target user (here myuser) into the server and type "which svnserve". If you don't see the path to the binary, make this file (and most likely the other subversion binaries) globally accessible to this user.

400 Bad Request

REPORT request failed on '...' REPORT of '...': 400 Bad Request (http://...)

You're behind a firewall which blocks DAV requests. Most firewalls do that. Either ask your Administrator to change the firewall, or access the repository with https:// instead of http://. That way you connect to the repository with SSL encryption, which firewalls can't interfere with (if they don't block the SSL port completely).

Also some virus scanners (i.e. Kaspersky) are known to interfere and cause this error.

403 Forbidden

PROPFIND request failed: 403 Forbidden

It's probably because you've entered the parent path of your repository instead of the actual repository path. Try appending the name of the repository you wish to access to the URL. You also need to append the URL with a trailing '/' slash, after the repository name.

For more information about the actual error, seek out the Apache error log.

405 HTTP Method Not Allowed

PROPFIND Request Failed - Error 405 HTTP Method Not Allowed

This message comes in different flavours. You might be seeing this error when:

• PROPFIND Request Failed You tried to browse the parent path of a repository instead of the repository itself using an older version of TortoiseSVN. Try appending the name of the repository you wish to access, or upgrade TortoiseSVN to 1.2.3 or newer.
• PROPFIND Request Failed You forgot to append a '/' slash to the end of the URL you entered. Older versions of TSVN require that there be a '/' after the repository name. If you forget this, TSVN will strip the repository name from the URL and therefore try to access the parent directory.
• PROPFIND Request Failed You try to access the repository through a proxy which does not allow DAV requests. Usually you can browse your repository with your webbrowser just fine, only if you use a svn client you get this error. You have to configure your proxy/firewall server to let DAV requests through. Or try using https instead of http: most proxies can't analyze encrypted network packets and therefore can't block DAV requests anymore.
  Another possibility for this error is a virus scanner/firewall you have running on your machine. A lot of those filter out DAV requests without you even noticing it. Try disabling the scanner/firewalll.
• Lock Request Failed You tried to lock a file in your working copy which no longer exists in the repository. Update your working copy before trying to lock files.

For more information about what actually caused the error, seek out the Apache error log.

SVN+SSH: Connection closed unexpectedly

It has been reported that svn+ssh connections of the form svn+ssh://[email protected] which were previously working, stop working with TortoiseSVN 1.5. This seems to be related to plink, and occurs if you have a default hostname set in PuTTY.

If this is the case you can fix it by using regedit or regedt32 to clear HKEY_CURRENT_USER/Software/SimonTatham/Putty/Sessions/Default%20Settings/HostName.

• ssh into your account
• cd ~
• cp /etc/bashrc .bashrc
• nano .bashrc
• put a # before the line "mesg y" (which comments it out)
• Ctrl+X to exit, press Y when prompted to save.