• R/O
  • SSH


File Info

Rev. 12896
Größe 52,416 Bytes
Zeit 2008-05-11 16:22:13
Autor stefankueng
Log Message

FAQ entry:
TSVN not showing up on x64 OS versions.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="http://www.w3.org/1999/xhtml">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<style type="text/css"> /* <![CDATA[ */
  @import "branding/css/tigris.css";
  @import "branding/css/inst.css";
  /* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
<script type="text/javascript" src="branding/scripts/tigris.js"></script>
<title>TortoiseSVN FAQ</title>

<div class="app">

<h1>TortoiseSVN FAQ</h1>

<div class="h2"><!-- no 'id' or 'title' attribute for TOC -->
<h2>Table of Contents</h2>

<h4>Installation &amp; Upgrade:</h4>
<li><a href="#uninstallfirst">When upgrading TortoiseSVN, do I have to uninstall the existing version first?</a></li>
<li><a href="#adminpriv">Do I need Admin privileges to install TortoiseSVN?</a></li> 
<li><a href="#installsubversion">Do I need to install Subversion before I can use TortoiseSVN?</a></li>
<li><a href="#uninstall">How do I uninstall TortoiseSVN?</a></li>
<li><a href="#msidisabled">MSI installation is disabled on my machine. Is there a .exe installer?</a></li> 
<li><a href="#whymsi">Why are you using MSI instead of an exe or no installer at all?</a></li>
<li><a href="#installerror">The installer aborts with an error message</a></li>
<li><a href="#nomenus">After installing, TortoiseSVN does not show up, no context menus are available</a></li>

<h4>Overlay icons:</h4>
<li><a href="#ovlnotshowing">Why don't the icon overlays appear?</a></li>
<li><a href="#ovlnotall">The overlay icons appear, but not all of them!</a></li>
<li><a href="#ovlonlylocal">Why are the icons only visible on local and not on network drives?</a></li>
<li><a href="#ovlsubst">Why are the overlay icons on SUBSTed drives messed up?</a></li>
<li><a href="#ovlwrong">Why are the overlays showing the wrong status?</a></li>
<li><a href="#ovlmessed">Why do the overlay icons sometimes change to random graphics?</a></li>

<h4>General questions:</h4>
<li><a href="#100cpu">100% CPU, when I right-click on a file.</a></li>
<li><a href="#repoonshare">Can I create a local repository on a network directory?</a></li>
<li><a href="#reponoserver">Can I keep my repository on a network share instead of setting up a server?</a></li>
<li><a href="#listparentpath">Can I get a list of all the repositories on my Server?</a></li>
<li><a href="#multiclients">Can I use different Subversion clients with the same working copy?</a></li>
<li><a href="#eol">Can TortoiseSVN convert line breaks in text files on the fly?</a></li>
<li><a href="#propconflict">How do I find out what the conflict is when it is in a directory's property list?</a></li>
<li><a href="#getremovedfileback">I accidentally removed a file. How do I get it back?</a></li>
<li><a href="#multiplemenus">I get multiple TortoiseSVN context menu entries when I right click on a link!</a></li>
<li><a href="#sharedfiles">Is it possible to use 'Shared Files' like in Visual Source Safe?</a></li>
<li><a href="#noserver">Is it possible to use TortoiseSVN without a server?</a></li>
<li><a href="#username">Is there a way to send username & password when using TortoiseProc?</a></li>
<li><a href="#revisiongraph">How does the revision graph work?</a></li>
<li><a href="#noauthor">Why is there no 'author' shown in the logs when I commit changes via svn+ssh?</a></li>
<li><a href="#detectmodification">Why does TortoiseSVN not recognize that a file has been modified?</a></li>
<li><a href="#commitremoved">When I remove a file it vanishes, how do I commit it?</a></li>

<h4>How can I...</h4>
<li><a href="#keywords">... add keyword information like author, revision, date and commit-time to my files?</a></li>
<li><a href="#casechange">... change the case of a filename?</a></li>
<li><a href="#editlog">... change the log message or author after committing?</a></li>
<li><a href="#clearhistory">... clear the drop-down lists in TortoiseSVN?</a></li>
<li><a href="#removerepo">... completely remove a repository from my computer?</a></li>
<li><a href="#exportlog">... export the log out to a text file?</a></li>
<li><a href="#subwcrev">... get the project revision number into my project?</a></li>
<li><a href="#noautomerge">... prevent Subversion from doing automatic merges?</a></li>
<li><a href="#currentrepo">... see what my current sandbox/repository is?</a></li>
<li><a href="#silentinstall">... install TortoiseSVN silently/automatically?</a></li>

<h4>Error messages</h4>
<li><a href="#cantmove">Can't copy / move 'XXX.svn-base' to 'XXX.tmp': The system cannot find the file specified.</a></li>
<li><a href="#inuse">Can't open file 'XXX\nnn-n.txn\changes': The process cannot access the file because it is being used by another process</a></li>
<li><a href="#alreadyexists">Failed to add 'XXX': object of the same name already already exists</a></li>
<li><a href="#401">OPTIONS of '&lt;path&gt;': 401 Authorization Required &lt;url&gt;</a></li>
<li><a href="#clientold">This client is too old to work with working copy 'XXX'</a></li>
<li><a href="#wcoutofdate">Working copy is out-of-date</a></li>
<li><a href="#standardout">Unable to write to Standard output</a></li>
<li><a href="#400">400 Bad Request</a></li>
<li><a href="#403">403 Forbidden</a></li>
<li><a href="#405">405 HTTP Method Not Allowed</a></li>

<div class="h2" id="installation-and-upgrade" title="installation-and-upgrade">
<h2>Installation &amp; Upgrade:</h2>

<div class="h3" id="uninstallfirst" title="uninstallfirst">
<h3>When upgrading TortoiseSVN, do I have to uninstall the existing version first?</h3>
<p>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.</p>

<div class="h3" id="adminpriv" title="adminpriv">
<h3>Do I need Admin privileges to install TortoiseSVN?</h3>
<p>Yes, you need to have Admin privileges to install TortoiseSVN, or at least
have the rights to install <em>with</em> Admin privileges.</p>
<p>But after TortoiseSVN has been installed, you can use it without having
Admin privileges.</p>

<div class="h3" id="installsubversion" title="installsubversion">
<h3>Do I need to install Subversion before I can use TortoiseSVN?</h3>
<p>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.</p>

<div class="h3" id="uninstall" title="uninstall">
<h3>How do I uninstall TortoiseSVN?</h3>
<p>Simply uninstall from Add/Remove Programs in the Windows control panel. 
This does not affect your repositories or working copies at all.</p>

<div class="h3" id="msidisabled" title="msidisabled">
<h3>MSI installation is disabled on my machine. Is there a .exe installer?</h3>
<p>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.</p>

<div class="h3" id="whymsi" title="whymsi">
<h3>Why are you using MSI instead of an exe or no installer at all?</h3>
<p>There are several reasons why we use MSI as our installer instead of something else:
<li>It's open. Everybody can see what we're doing by using msi tools like Orca.</li>
<li>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.</li>
<li>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).</li>
<li>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.</li>
<li>msi is the standard and recommended way of installing windows applications. It's even <b>required</b> now to get the "Certified for Vista" logo from Microsoft.</li>
<li>There's a great open source tool for creating msi files: <a href="http://wix.sourceforge.net">WiX</a> which we use.</li>
<li>msi takes care of reference counting of installed modules which prevents the so called <a href="http://en.wikipedia.org/wiki/DLL_hell">dll hell</a>.</li>
<li>an installer is required since we have to <b>register</b> TortoiseSVN with the shell. A simple exe for you to run wouldn't work.</li>

<div class="h3" id="installerror" title="installerror">
<h3>The installer aborts with an error message</h3>
<p>There are several reasons why the installation cannot succeed:
<li><em>&quot;This installation package is not supported by this processor type. Contact your product vendor.&quot;</em> 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 <em>x64</em> in it.</li>
<li><em>&quot;The installer was interrupted before TortoiseSVN could be installed. You need to restart the installer to try again&quot;</em>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.</li>
<li><em>&quot;The windows installer service could not be accessed&quot;</em> 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 <a href='http://support.microsoft.com/default.aspx?scid=kb;en-us;q315346'>Q315346</a> (basically, check that the folder where the msi is stored isn't encrypted or compressed)</li>
<li><em>&quot;The system can not open the device of file specified&quot;</em>, followed usually by <em>&quot;The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2755&quot;</em>. This can happen if:
	<li>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.</li>
	<li>The installation is being run over a terminal Server via a mapped network drive.</li>
	<li>The installation is unable to create or write to the Installer directory in a Windows NT system environment.</li>
	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:
	<li><a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;220780">220780</a> OFF2000: Setup Error 2755 with Earlier Office Version Installed</li>
	<li><a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;217714">217714</a> OFF2000: Setup Appears to Stop Responding, Followed by Internal Error 2336 or 2755</li>
	<li><a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;254841">254841</a> OFF2000: Internal Error 2755, When You Try to Install from a Remote Windows Terminal Server Client</li>
	<li><a href="http://support.microsoft.com/default.aspx?scid=kb;en-us;305640">305640</a> PRJ2000: Internal Error 2381 or Internal Error 2755 When You Install Microsoft Project</li>
<li><em>&quot;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.</em> You need at least <a href="http://support.microsoft.com/kb/893803/">version 3 of the msi installer</a>.</li>

<div class="h3" id="nomenus" title="nomenus">
<h3>After installing, TortoiseSVN does not show up, no context menus are available</h3>
<p>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.</p>
<p>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.</p>


<div class="h2" id="overlay-icons" title="overlay-icons">
<h2>Overlay icons</h2>

<div class="h3" id="ovlnotshowing" title="ovlnotshowing">
<h3>Why don't the icon overlays appear?</h3>
<li>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.</li>
<li>Go to the settings of TSVN and activate the icon overlays for at least the fixed drives. The installer does this automatically for the <em>current</em> 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.</li>

<div class="h3" id="ovlnotall" title="ovlnotall">
<h3>The overlay icons appear, but not all of them!</h3>
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.
<li>Normal, Modified and Conflicted are always loaded and visible.</li>
<li>Deleted is loaded if possible, but falls back to Modified if there are not enough slots.</li>
<li>ReadOnly is loaded if possible, but falls back to Normal if there are not enough slots.</li>
<li>Locked is only loaded if there are less than 13 overlays already loaded. It falls back to Normal if there are not enough slots.</li>
<li>Added is only loaded if there are less than 14 overlays already loaded. It falls back to Modified if there are not enough slots.</li>

<div class="h3" id="ovlonlylocal" title="ovlonlylocal">
<h3>Why are the icons only visible on local and not on network drives?</h3>
<p>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 <b>slow down</b> not only TortoiseSVN but the whole system.

<div class="h3" id="ovlsubst" title="ovlsubst">
<h3>Why are the overlay icons on SUBSTed drives messed up?</h3>
<p>If your working copy is on a SUBST drive the icons might be mixed up.</p>
<p>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.</p>
<p>There is an easy way to solve this: just exclude the original path from 
showing overlays (settings->icon overlays->exclude paths).</p>
<p>For example, if you have mapped \\station\folder\wc to g: then put "\\station\folder\wc*" as the exclude pattern.</p>

<div class="h3" id="ovlwrong" title="ovlwrong">
<h3>Why are the overlays showing the wrong status?</h3>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>

<div class="h3" id="ovlmessed" title="ovlmessed">
<h3>Why do the overlay icons sometimes change to random graphics?</h3>
The Windows icon cache is a fairly buggy creature. You can solve this in one of the following ways:
<li>Install Microsoft's <a href='http://www.microsoft.com/ntworkstation/downloads/powertoys/networking/nttweakui.asp'>TweakUI</a> and run the option to rebuild icons.</li>
<li>Or increase the icon cache size. Go to <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer</code> and add a new String Value called <code>Max Cached Icons</code>. The default value is 500 - try increasing it to 2048 (see <a href='http://support.microsoft.com/support/kb/articles/Q132/6/68.asp'>Q132668</a> in the Microsoft knowledge base for more details). </li>
<li>Or delete the file called ShellIconCache in your Windows directory. And reboot.</li>
<li>With TortoiseSVN 1.3.0 and later, you can also rebuild the icon cache by calling TortoiseProc from the command line like this <code>TortoiseProc.exe /command:rebuildiconcache</code></li>


<div class="h2" id="general-questions" title="general-questions">
<h2>Overlay icons</h2>

<div class="h3" id="100cpu" title="100cpu">
<h3>100% CPU, when I right-click on a file.</h3>
<p>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?</p>
<p>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:
<li>Start the Control Panel Display applet.</li>
<li>Select the Appearance tab.</li>
<li>Click Effects, then clear the "Use the following transition effect for menus and tooltips" check box.</li>
<li>Click OK to close all dialog boxes.</li>
Another solution that often works is to left-click the file or folder before right-clicking to display the context menu.

<div class="h3" id="repoonshare" title="repoonshare">
<h3>Can I create a local repository on a network directory?</h3>
<p><strong>Do not create a Berkeley DB repository on a network share!</strong></p>
<p>A BDB repository <em>cannot</em> 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.</p>
<p>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.</p>
<p>If you <em>really</em> need to access an FSFS repository on a network share you
should do one of the following:
<li>Use drive mapping using the syntax below:
<dt>Map //server/shared to S:</dt>
<dd><strong>file:///S:/repos</strong> (3 leading slashes before drive letter)</dd>
<li>Specify a UNC path directly using the syntax below:
<dt>Subversion >= 1.2</dt>
<dd><strong>file://server/shared/repos</strong> (2 leading slashes)</dd>
<dt>Subversion < 1.2 (strange syntax, we know)</dt>
<dd><strong>file://///server/shared/repos</strong> (5 leading slashes)</dd>
<dd><strong>file:///\server/shared/repos</strong> (3 slashes + backslash)</dd>
<p>But don't say we didn't warn you ...</p>

<div class="h3" id="reponoserver" title="reponoserver">
<h3>Can I keep my repository on a network share instead of setting up a server?</h3>
<p>If you need multiple computers to access the repository, you can in theory create 
an FSFS repository (<strong>but not a BDB repository</strong>) on a network share 
and access it using file:// protocol.
In practice this is <strong>not</strong> recommended for three very good reasons:
<li>You are giving direct write access to all users, so they could accidentally 
delete or corrupt the repository file system.</li>
<li>Not all network file sharing protocols support the locking that Subversion requires. 
One day you will find your repository has been subtly corrupted.</li>
<li>You have to set the access permissions in just the right way. 
SAMBA is particularly difficult in this respect.</li>
<p>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. 
<a title='Chapter 6. Server Configuration' href='http://svnbook.red-bean.com/en/1.4/svn.serverconfig.html'>Chapter 6, Server Configuration</a> 
in the Subversion Book covers this process in detail.</p>

<div class="h3" id="listparentpath" title="listparentpath">
<h3>Can I get a list of all the repositories on my Server?</h3>
<p>With TortoiseSVN and the command line Client: No.</p>
<p>With a web browser: Yes</p>
<p>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.</p>
<p>Unfortunately, this is a limitation in the Subversion libraries that both the 
command-line client and TortoiseSVN uses. It does not have the capability to 
arbitrarily enumerate repositories on a server.</p>
<p>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.</p>

<div class="h3" id="multiclients" title="multiclients">
<h3>Can I use different Subversion clients with the same working copy?</h3>
<p>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.</p>
<p>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.5.x can be used together (the 'x' indicates
that this number is not relevant for compatibility).</p>
<p>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 <em>not</em> 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 <em>not</em> use a Linux and a Windows client on the same working 

<div class="eol" title="eol">
<h3>Can TortoiseSVN convert line breaks in text files on the fly?</h3>
Check the subversion book about the svn:eol-style property <a title='svn:eol-style' href='http://svnbook.red-bean.com/en/1.4/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style'>here</a>.
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 <a title='setting properties' href='/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html#tsvn-dug-propertypage-props'>here</a>.

<div class="h3" id="propconflict" title="propconflict">
<h3>How do I find out what the conflict is when it is in a directory's property list?</h3>
Inside the folder with the conflicting properties, you'll find a file called 
<code>dir_conflicts.prej</code>. 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.

<div class="h3" id="getremovedfileback" title="getremovedfileback">
<h3>I accidentally removed a file. How do I get it back?</h3>
<p>If you haven't committed your changes yet, you can do a <cite>revert</cite> 
on the parent folder where you deleted the file or directory.</p>
<p>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 <cite>Copy to...</cite> 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.</p>
<p>You can also restore a deleted directory using this technique.</p>
<p>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'.</p>

<div class="h3" id="multiplemenus" title="multiplemenus">
<h3>I get multiple TortoiseSVN context menu entries when I right click on a link!</h3>
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).</p>

<div class="h3" id="sharedfiles" title="sharedfiles">
<h3>Is it possible to use 'Shared Files' like in Visual Source Safe?</h3>
You can't share single files in Subversion, but you can share folders. Please 
look at the chapter <a href="http://svnbook.red-bean.com/en/1.4/svn.advanced.externals.html">External Definitions</a> 
in the <a href="http://svnbook.red-bean.com/">Subversion Book</a>.

<div class="h3" id="noserver" title="noserver">
<h3>Is it possible to use TortoiseSVN without a server?</h3>
<p>Yes, it is. You can use the file:// protocol to access your repository locally.</p>

<div class="h3" id="username" title="username">
<h3>Is there a way to send username & password when using TortoiseProc?</h3>
<p>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.</p>

<div class="h3" id="revisiongraph" title="revisiongraph">
<h3>How does the revision graph work?</h3>
<p>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 
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>

<div class="h3" id="noauthor" title="noauthor">
<h3>Why is there no 'author' shown in the logs when I commit changes via svn+ssh?</h3>
<p>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.

<div class="h3" id="detectmodification" title="detectmodification">
<h3>Why does TortoiseSVN not recognize that a file has been modified?</h3>
<p>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.</p>
<p>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
<li>the file 'last modification' date has changed (some tools like hex editors like to reset that time)</li>
<li>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</li>
Subversion determines whether a file has changed with the following approach:
<li>has the 'last modification' date  and/or the file size changed?</li>
<li>if not: file is not modified</li>
<li>if yes: compare file content with the BASE file</li>
<li>stop at the first byte that differs, mark the file as modified</li>
<li>if no byte differs regarding to BASE, mark the file as not-modified</li>

<div class="h3" it="commitremoved" title="commitremoved">
<h3>When I remove a file it vanishes, how do I commit it?</h3>
<p>Easy, you commit the whole directory! <cite>Right-click</cite> in the Explorer 
window next to the file, and choose <cite>commit</cite>. The commit dialog will 
show you every modification as well as added or deleted files.</p>

<div class="h2" id="how-can-i" title="how-can-i">
<h2>How can I...</h2>

<div class="h3" id="keywords" title="keywords">
<h3>... add keyword information like author, revision, date and commit-time to my files?</h3>
<p>Read about the Subversion property 
<a href='http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html'>svn:keywords</a> 
in the Subversion book.</p>
<p>With TortoiseSVN, set the properties as described 
<a href='/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html#tsvn-dug-propertypage-props'>here</a>.</p>

<div class="h3" id="casechange" title="casechange">
<h3>... change the case of a filename?</h3>
<p>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.</p>
<p>By far the easiest way is to rename directly using the repository browser:
<li>Commit the changes in your working copy.</li>
<li>Rename the file from UPPERcase to upperCASE directly in the repository using the repository browser.</li>
<li>Update your working copy.</li>

<div class="h3" id="editlog" title="editlog">
<h3>... change the log message or author after committing?</h3>
<p>Call up the log dialog and do a <cite>Right-Click</cite> 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 
<cite>pre-revprop-change</cite> 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.</p>

<div class="h3" id="clearhistory" title="clearhistory">
<h3>... clear the drop-down lists in TortoiseSVN?</h3>
<p>>ou can clear all the stored data from the settings dialog of TortoiseSVN. 
Just click on the corresponding button.</p>

<div class="h3" id="removerepo" title="removerepo">
<h3>... completely remove a repository from my computer?</h3>
<p>Aehemm: select the folder and hit 'delete' (the key on your keyboard may be labelled only 'del').</p>
<p>Seriously, there are no hidden files or settings. The repository is completely 
contained in one folder tree.</p>
<p>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.</p>

<div class="h3" id="exportlog" title="exportlog">
<h3>... export the log out to a text file?</h3>
<p>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.</p>
<p>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.</p>

<div class="h3" id="subwcrev" title="subwcrev">
<h3>... get the project revision number into my project?</h3>
<p>If you want the revision number in your program version number,	you need an 
additional tool to do that. You can find the tool <cite>SubWCRev.exe</cite> on 
the download page on our website or in your TortoiseSVN Folder under <cite>bin</cite>.</p>
<p>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:
<dd>This string will be replaced by the revision number of your working copy.</dd>
<dt>WCMODS?Modified:Not modified$</dt>
<dd>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 <cite>Modified</cite> or <cite>Not modified</cite>.
<dd>Will be replaced by the date of the highest revision in your working copy.</dd>
As an example, have a look at the file <cite>version.in</cite> in the 
<a href='http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/src/version.in'>TortoiseSVN source tree</a>.
This file is used in TortoiseSVN and its resource files. The SubWCRev.exe tool 
is called from the build script like this:
<code>SubWCRev.exe path\\to\\working\\copy version.in version.h</code>
This creates a new file <cite>version.h</cite> with all the strings above 
replaced with the values of the working copy. The <cite>version.h</cite> file 
is then used in the project itself and included in the resource files for the 
version information.</p>

<div class="h3" id="noautomerge" title="noautomerge">
<h3>... prevent Subversion from doing automatic merges?</h3>
<p>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 
<li>In TortoiseSVN->Settings->Subversion configuration file, click on the edit button.</li>
<li>Change the [helpers] section by adding
diff-cmd = "C:\\false.bat"
diff3-cmd = "C:\\false.bat"
(note the double backslash)</li>
<li>Create the file C:\false.bat which contains two lines
@type %9
@exit 1 </pre>
This effectively makes auto-merge fail every time, forcing the file into conflict.</p>
<p>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.</p>

<div class="h3" id="currentrepo" title="currentrepo">
<h3>... see what my current sandbox/repository is?</h3>
<p>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.</p>
<p>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.</p>

<div class="h3" id="silentinstall" title="silentinstall">
<h3>... install TortoiseSVN silently/automatically?</h3>
<p>Just start the msi installer like this:</p>
<pre>msiexec /package TortoiseSVN.msi /quiet INSTALLDIR="path/to/install/dir"</pre>

<div class="h2" id="error-messages" title="error-messages">
<h2>Error messages</h2>

<div class="h3" id="cantmove" title="cantmove">
<h3>Can't copy / move 'XXX.svn-base' to 'XXX.tmp': The system cannot find the file specified.</h3>
<p>This error message typically occurs when you try to update your working copy. The reason for this error is either:
<li>There are actually 2 different files in the repository whose names differ 
only in case. This <emphasis>cannot</emphasis> 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.</li>
<li>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).</li>
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.</p>
<p>There are several ways to solve the problem and to prevent it from happening 
again. Take a look at these <a href="#casechange">instructions</a>. </p>

<div class="h3" id="inuse" title="inuse">
<h3>Can't open file 'XXX\nnn-n.txn\changes': The process cannot access the file because it is being used by another process</h3>
<p>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.</p>
<p>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.</p>
<p>Similar errors can occur in your working copy. Try ignoring the .svn folder there.</p>

<div class="h3" id="alreadyexists" title="alreadyexists">
<h3>Failed to add 'XXX': object of the same name already already exists</h3>
<p>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:</p>
<li>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.</li>
<li>A file has been renamed in the repository, but it differs only in case, 
like <cite>Install.txt</cite> to <cite>install.txt</cite>, 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.</li>
<li>There are actually 2 different files in the repository whose names differ 
only in case. This <emphasis>cannot</emphasis> 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.</li>

<div class="h3" id="401" title="401">
<h3>OPTIONS of '&lt;path&gt;': 401 Authorization Required &lt;url&gt;</h3>
<p>When upgrading to version 1.4.x, you suddenly can't access your repository 
anymore. Every try is rejected with the error message: <em>OPTIONS of 'path': 401 Authorization Required 'url'</em></p>
<p>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 
<p>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 <em>authentication</em> succeeds, 
but the <em>authorization</em> fails.</p>
<p>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).</p>
<p>To solve this issue you have the following options:</p>
<li>disable the GUEST account on the domain controller</li>
<li>use the same accounts for your workstations and access to the repository</li>
<li>disable SSPI authentication for the repository</li>
<li>Check the case of the usernames. Changing the usernames in the access files to lowercase also might solve this problem</li>

<div class="h3" id="clientold" title="clientold">
<h3>This client is too old to work with working copy 'XXX'</h3>
<p>The full error message is: This client is too old to work with working copy 
'.'; please get a newer Subversion client.</p>
<p>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.</p>
<p>The reason for this is that Subversion 1.4 and 1.5 upgrade the working copies 
transparently on every command. But once the working copy format is upgraded, 
older clients can't access the working copy anymore because they don't know the new format.</p>
<p>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.</p>

<div class="h3" id="wcoutofdate" title="wcoutofdate">
<h3>Working copy is out-of-date</h3>
<p>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.</p>
<p>That means you need to use the <cite>Update</cite> command to update your 
working copy to the same level as the repository.</p>
<p>It may not be obvious why you need to do this, especially if you <em>know</em> 
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:</p>
Add Folder in revision 1
Add File1 and File2 in revision 2
Modify File1 and commit in revision 3
<p>Now the repository is at revision 3, but in your working copy the revisions look like this:</p>
Folder       : revision 1
Folder/File1 : revision 3
Folder/File2 : revision 2
<p>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).</p>
<p>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!</p>

<div class="h3" id="standardout" title="standardout">
<h3>Unable to write to Standard output</h3>
<p>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.</p>
<p>"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.</p>
<p>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.</p>
<p>If normal plink just hangs, then the wrong params are passed to it 
(settings dialog, network tab).</p>
<p>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 &quot;which svnserve&quot;. 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.</p>

<div class="h3" id="400" title="400">
<h3>400 Bad Request</h3>
<p>REPORT request failed on '...' REPORT of '...': 400 Bad Request (http://...)</p>
<p>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 <strong>https://</strong> instead of <strong>http://</strong> like in 
<a href='https://svn.collab.net/repos/svn/'>https://svn.collab.net/repos/svn/</a>
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).
<p>Also some virus scanners (i.e. Kapersky) are known to interfere and cause
this error.</p>

<div class="h3" id="403" title="403">
<h3>403 Forbidden</h3>
<p>PROPFIND request failed: 403 Forbidden</p>
<p>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.</p>
<p>For more information about the actual error, seek out the Apache error log.</p>

<div class="h3" id="405" title="405>
<h3>405 HTTP Method Not Allowed</h3>
<p>PROPFIND Request Failed - Error 405 HTTP Method Not Allowed</p>
<p>This message comes in different flavours. You might be seeing this error when:</p>
<li><strong>PROPFIND Request Failed</strong>
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.</li>
<li><strong>PROPFIND Request Failed</strong>
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.</li>
<li><strong>PROPFIND Request Failed</strong>
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.
<br />
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.</li>
<li><strong>Lock Request Failed</strong>
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.</li>
<p>For more information about what actually caused the error, seek out the Apache error log.</p>

Show on old repository browser