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. For this kind of error message, please check out the Microsoft Knowledgebase article Q315346 (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. The following knowledge base articles may help:
  • 220780 OFF2000: Setup Error 2755 with Earlier Office Version Installed
  • 217714 OFF2000: Setup Appears to Stop Responding, Followed by Internal Error 2336 or 2755
  • 254841 OFF2000: Internal Error 2755, When You Try to Install from a Remote Windows Terminal Server Client
  • 305640 PRJ2000: Internal Error 2381 or Internal Error 2755 When You Install Microsoft Project
  • 318080 "The system cannot open the device or file specified" error message occurs when you try to install the .NET Framework
• "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. If you are also using TortoiseCVS, then there are not enough overlay slots available, so 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.
• 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.
• Other Tortoise clients like TCVS. Newer versions of these used a shared icon set, TortoiseOverlays.dll, but you should check what your version uses.
• Dropbox
• Microsoft Groove (part of Office 2007/2010)

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 (see Q132668 in the Microsoft knowledge base for more details).
• 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?

Do not create a Berkeley DB repository on a network share!

A BDB repository cannot exist on a remote filesystem such as NFS, AFS, or Windows SMB. Berkeley DB requires that the underlying filesystem implement strict POSIX locking semantics, and more importantly, the ability to map files directly into process memory. Almost no network filesystems provide these features. If you attempt to use Berkeley DB on a network share, the results are unpredictable. You may see mysterious errors right away, or it may be months before you discover that your repository database is subtly corrupted.

You can use an FSFS 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 an FSFS 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 an FSFS repository (but not a BDB 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.

• CollabNet Subversion Edge
• uberSVN
• VisualSVN

Can I get a list of all the repositories on my Server?

With TortoiseSVN and the command line Client: No.

With a web browser: Yes

A lot of people would agree that the TSVN repository browser would be a much more useful tool if you could just point it at your versioning server and it would show you whatever available repositories it had. Same story, albeit to a lesser degree, with the command-line 'svn' client. Doing a 'svn ls' or equivalent and being able to see what repositories and projects are hosted on a specific versioning system would be very useful.

Unfortunately, this is a limitation in the Subversion libraries that both the command-line client and TortoiseSVN use. It does not have the capability to arbitrarily enumerate repositories on a server.

Some might even argue that the lack of this feature is incitement for end users to just jumble everything into one big repository, when it would be more appropriate to split things up.

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://username@server.com. 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.

I get garbage text shown instead of dates, or a checkout/update even crashes!

This usually happens after installing XP SP3. To fix this problem, do the following:

1. Download tzedit.exe from support.microsoft.com/kb/914387
2. Start tzedit.exe
3. Select your time zone from the list (Since all crash reports I got indicated they were from the "Jerusalem" time zone, I assume you'd have to select that)
4. click "Edit"
5. click "Ok"

The explorer crashes on every right-click on a folder with PowerDesk installed.

This is a bug in PowerDesk. You have to install a patch from their website to fix this issue. Go to kb.avanquestusa.com and then search for the article named "PowerDesk crashes when right-clicking on some files and folders".

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