- Project pages
- Project tools
- How do I...
|Over 500 more tools...
Site Maintenance: Dec 6th 7:00 PM PST to Dec 7th 7:00 AM PST
The Site is scheduled for maintenance and will be unavailable during the period. Sorry about the inconvenience.
There will be a brief maintenance window every Friday at 17:00 Pacific.
For further details, see CollabNet's maintenance and upgrade policy.
Table of Contents
Installation & Upgrade:
How can I...
Installation & Upgrade:
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
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:
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:
- 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
- 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.
Why don't you install the 32-bit version along with the 64-bit version?
That sounds like a good idea, but is difficult for a number of practical reasons:
- msi does not allow installing x64 and win32 binaries together, there must be two separate msi files.
- Even if it were allowed, the installer size would more than double to 40MB, and you only need the 32-bit version if you want TSVN to work within the file open/save dialogs of 32-bit apps.
- In theory we could supply only the shell extension in both 32 and 64-bit. But to make the shellex work we also have to provide the APR dlls, the C runtime dlls, MFC and a heap of other stuff in 32 and 64-bit versions.
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).
If that doesn't work try these other FAQ entries
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
Other apps which are known to use overlays:
- 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.
- 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
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
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:
- Start the Control Panel Display applet.
- Select the Appearance tab.
- Click Effects, then clear the "Use the following transition effect for menus and tooltips" check box.
- 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 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:
- You are giving direct write access to all users, so they could accidentally
delete or corrupt the repository file system.
- Not all network file sharing protocols support the locking that Subversion requires.
One day you will find your repository has been subtly corrupted.
- You have to set the access permissions in just the right way.
SAMBA is particularly difficult in this respect.
- 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. We also have a chapter on
setting up a server
in our own docs.
You can find a user-friendly server installer as part of the
CollabNet server package
or you can download 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
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'.
Is it possible to use TortoiseSVN without a server?
Yes, it is. You can use the file:// protocol to access your repository locally.
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
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 or
because we're too stupid to optimize it, even though some of you seem to
imply that. It is really 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 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:
- has the 'last modification' date and/or the file size changed?
- if not: file is not modified
- if yes: compare file content with the BASE file
- stop at the first byte that differs, mark the file as modified
- 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:
- Download tzedit.exe from http://support.microsoft.com/kb/914387
- Start tzedit.exe
- 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)
- click "Edit"
- click "Ok"
For more information, see here
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
http://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:
delete readonly = yes
For older versions, try:
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:
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.
Will you add the standard subversion client to the installer?
No. The subversion command line binaries are available from several places already, notably tigris.org and CollabNet.
Whilst it would be a convenience for our users there are several good reasons, both technical and
practical, why we will not do this.
If we ship those binaries we have to support them too, which we do not have time for.
Although we include the basic svn.exe and svnadmin.exe on our nightly build site,
these are not 100% compatible with the official binaries. For a start they are statically linked,
they are built using a different compiler and our own build scripts, and we use a few different
build options, notably in the authentication area. If you were to report a subversion bug using
those binaries it is not guaranteed that the official subversion client would show the same bug,
so any bug reports sent to the subversion list would simply get bounced back to us.
As our binaries are statically linked, adding the subversion binaries would increase the size
of the installer by several MB, and it is already quite large.
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
After you install Subclipse you need to make a fresh checkout. It will not fix checkouts that were made before it was installed.
How can I...
... add keyword information like author, revision, date and commit-time to my files?
Read about the Subversion property
in the Subversion book.
With TortoiseSVN, set the properties as described
... 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. You cannot do this
easily within your working copy as Subversion requires 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:
- Commit the changes in your working copy.
- Rename the file from UPPERcase to upperCASE directly in the repository using the repository browser.
- Update your working copy.
... 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:
- 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.
- 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
... 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
- In TortoiseSVN->Settings->Subversion configuration file, click on the edit button.
- Change the [helpers] section by adding
diff-cmd = "C:\\false.bat"
diff3-cmd = "C:\\false.bat"
(note the double backslash)
- Create the file C:\false.bat which contains two lines
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:
msiexec /package TortoiseSVN.msi /quiet INSTALLDIR="path/to/install/dir"
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, but on Windows 7 it is
likely to be the Windows Indexing Service. Turn off the indexing service on your
working copies and repositories, and exclude them from virus scans.
Here's how you can configure the indexing service:
- Click the start menu button, then click in the text box to begin a search
- Type in “windows index”
- Click on “Indexing Options” that should come up in the search
- When the Indexing Options box comes up, Click on the Modify button. This will pop up an Indexed Locations dialog, where you should see a list of some “locations”, with your hard drive(s) being in the list.
- Expand the desired hard drive, down to the root folder of the files you’re using SVN with, and make sure the box is unchecked. Also note that the hard drive will most likely be collapsed, and will have its box unchecked, even though once you expand it, you may find checked boxes.
Note: there's a bug in Win7 which causes this error message to appear a lot more
than necessary. The bug will be 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:
- 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.
- 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.
- 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.
Can't create directory 'c:\test\working-copy\.svn': Access is denied
You have to manually add yourself (the user you're logged in as) to the folder
with full access. On Windows 7, the C:\ drive root has limited access rights for
all users, and subfolders automatically inherit those limited access rights.
This applies even if you have disabled UAC.
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
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
"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:// like in
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. Kapersky) are known to interfere and cause
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@example.com
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
Another user has reported the following server-side fix:
- 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.