All commits have the same username. How do I setup the author?

If all the commits from different people to the repository have the same username 'anonymous', you have to set up authentication on your subversion server. See our docs: Chapter Setting Up A Server

Can TortoiseSVN use my Windows login name and password?

If you have set up the server to authenticate against a windows domain, then yes. But you still have to enter username/password yourself.

See our docs on how to set up such a server:
Authentication With A Windows Domain

I lost my SVN password. How can I retrieve it?

There's no way to recover your password if you forgot it, if you are using basic authentication.
Change the password on the server/repository. If you don't have access to the server, you have to ask the administrator to do it for you.

Windows authentication, repository on a Linux server

There are at least two ways to make a Subversion server running on Linux perform authentication through a Windows domain. Either use PAM (Pluggable Authentication Modules) or one of the various authentication modules for Apache. PAM authentication also works for Apache, and is thus a more general solution.

If you wish to use the Apache-only solution, you will need to find an appropriate authentication module. This could for example be:

• mod_auth_kerb for authenticating against Windows 2000, XP and 2003 domains
• mod_auth_nt_lm for authenticating against Windows NT4 domains
• mod_auth_samba or mod_auth_smb for authenticating using older versions of Samba

Note that of the above, only mod_auth_kerb seems to be actively maintained.

Unless you feel that it is too complicated to setup, or that the particular authentication module you are looking for only exists for Apache, you will probably want to use PAM.

In order to use the PAM solution, you will first need to:

• Install Samba version 3 (or later)
• Configure Samba's winbind
• Adjust your system's PAM configuration through /etc/pam.d to allow winbind authentication for the services you wish to use

When you have set up the above appropriately, tunneled svnserve connections (svn+ssh://, svn+rsh:// and similar) should work out-of-the-box, since the ssh daemon and similar tools already per default uses PAM to authenticate users.

To get Apache to work with PAM, make sure that mod_auth_pam is installed and then configure Apache as appropriate.

And of course: This is actually a server question which has little to do with the TortoiseSVN client, and thus further information should be sought on the Subversion FAQ or the Subversion mailing list.

Windows authentication, repository on a Windows server

If you wish to make a Subversion server running on Windows perform authentication through your Windows domain, the most widely used option is to use Apache and the mod_auth_sspi which is now hosted and maintained on SourceForge. Configuration using this module is covered extensively in the TortoiseSVN documentation.

If you wish to use the svnserve-based solution, you're on your own. It should be possible, provided that you can find a Windows SSH server that will:

1. authenticate users against your Windows domain, and
2. properly launch svnserve in tunnel mode

More information about setting up a SSH server for Subversion can be found in the Subversion book.

If you find yourself successful in setting up a svn+ssh server on Windows that authenticate through your Windows domain, feel free to brag about it on our mailing list.

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

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

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

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

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

After I resolve a conflict, the overlay shows 'unmodified'

If you have resolved the conflict by using all parts from theirs, then you don't have to commit anything because your file now looks exactly the same as the one in the repository. That's why it has the green overlay.

Can I create a repository on a network directory?

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

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

If you need multiple computers to access the repository, you can create an FSFS repository on the network share, not a Berkeley DB repository. In practice this is not recommended for three very good reasons:

1. You are giving direct write access to all users, so they could accidentally
   delete or corrupt the repository file system.
2. Not all network file sharing protocols support the locking that Subversion requires.
   One day you will find your repository has been subtly corrupted.
3. You have to set the access permissions in just the right way.
   SAMBA is particularly difficult in this respect.

A better solution by far 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.

To access an FSFS repository on a network share you need to do one of the following:

1. Use drive mapping using the syntax below:
   

   Map //server/shared to S:

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

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

   Subversion >= 1.2

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

   Subversion < 1.2 (strange syntax, we know)

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

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

Can I define my own keyboard shortcuts to specific commands?

Sorry, No.

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 uses. It does not have the capability to arbitrarily enumerate repositories on a server.

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

In any case, you should take this request to the main Subversion mailing list, as it does not fall under TSVN.

Send any requests regarding this (and only this!) to dev@subversion.tigris.org. Remember to ask to be CC'd if you expect replies to your request.

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.

As of Subversion 1.4, the metadata format inside the working copy has changed. This means for you that once you accessed your working copy with a Subversion client based on Subversion 1.4 and higher, you can not use it again with an older client. You will get an error message telling you that the client is too old.

Can I work on lots of working copies from different repositories at once?

Yes, you can. This is a standard feature of Subversion. Each directory which was checked out of Subversion remembers where it came from. You can even multiply select working copies which came from different places, and update or commit them all at once.

If you want to have different subdirectories to come from different repositories you can set a special Subversion property called svn:externals.

Please look at the chapter External Definitions in the Subversion Book.

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

Since there are so many entries in the Daily Use Guide that deal with "How Do I" style of questions, all these are now summed up in this section.

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.

How does TortoiseSVN handle conflicts?

Imagine you check out revision 24 of a file and started editing it. In the meantime, someone else committed revision 25, and shortly after that revision 26. You tell TortoiseSVN to update your file now, and Subversion will try to incorporate all the changes between revision 24 and 26 into your local file.

But if the changes made between 24 and 26 were too close to or even overlap with the changes you have made, Subversion detects a conflict and creates conflict markers in the file. You then have to resolve these conflicts yourself. Read the section about conflicts in the
Daily Use Guide to find out more.

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

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

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

You can also restore a deleted directory using this technique.

If, after the file / folder has been restored using this trick, the log dialog doesn't show you the history of that file, don't worry. The history is still there.

If you copy a file in SVN you copy its history too. But the default setting in TSVN's ShowLog is to 'Stop on copy', which means that when you look at the history, it only goes back to the branch point. The reason for this is that when you are looking at a real branch of a project, mostly you only want to see the history of that branch. To see the whole history in ShowLog you need to unselect the 'Stop on copy' checkbox and click on 'Get All'.

I always get an error when I check out or export a single file

There's nothing wrong with it. Subversion only allows you to check out directories - not files.
It is however possible to export a single file. Well, at least Subversion allows it. In TortoiseSVN the export dialog doesn't allow exporting single files. But there are other ways to get a single file from a repository:

• From the log dialog, right-click on the file, then choose "Save as..."
• From the repository browser, right-click on the file, then choose "Save as..."

Note: exporting a single file from a working copy can be easily done by right-dragging the file and then choose "SVN Export to here" from the context menu.

I deleted a file and created a file with the same name. Why can't I commit?

Your're trying to fool subversion aren't you? No - seriously - what did you expect to happen?

Assume you're in revision #55.

You removed a file using TortoiseSVN, which told it to mark the file for deletion with the next commit and to remove it from the explorer. It's not really gone from the revision yet. Then you created a file with the same name and added it to TortoiseSVN, which marks the file for adding with the next commit. It's not yet added to the repository. Now you commit. Poor subversion tries to decide whether to add or remove your file at the same time in revision #56. The commit fails.

You should have committed immediately after you deleted the file using TortoiseSVN's remove command. You still have no clue what to do? Well, in that case:

1. Move that file to a safe place
2. Commit your changes. That tells the repository that the file is gone in the first place
3. Copy the file back
4. Commit again

I don't have a 'Subversion' tab for setting properties

Possible reasons:

• TortoiseSVN is not properly installed
• You didn't restart your computer after installing TortoiseSVN
• The file/folder you show the properties for is not under version control
• The file/folder is not readable by TortoiseSVN

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

This is by design. One entry is for the link itself (the .lnk-file), the other for the target the link points to.

This way a link can both be versioned and in the same time work as a link should by allowing operations on its target.

In fact, you can have up to three entries in the file menu (the context menu will show only two).

Update for TortoiseSVN 1.5.0
TortoiseSVN 1.5.0 will only show multiple entries if the target of the link is in a working copy.

I have changed the configuration file to match my proxy/etc. setup, why doesn't it work?

Use the TSVN settings dialog to set your proxy server and more. If you edit the configuration manually, notice that the '#' char in the config file means that the rest of the line is a comment. Comments are ignored. If you make changes to the provided examples that you wish to have effect, you must first remove the '#' mark in front of the affected lines.

If my connection drops during a checkout, do I have to start again?

If for some reason a checkout fails somewhere in the middle, e.g. because your internet connection failed, you don't have to do a fresh checkout of a probably large source tree again.

• Do a Cleanup on your partly checked out working copy
• Now use the Update command to finish the checkout

Is it possible to use 'Shared Files' like in VSS?

You can't share single files in Subversion, but you can share folders. Please look at the chapter External Definitions in the Subversion Book.

Is it possible to use TortoiseSVN without a server?

Yes, it is. You can use the file:// protocol to access your repository locally.

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.

Merge 'From:' revision is out by one when I use Show Log

This behaviour is deliberate and not a bug. Here is an example:

8 Removed other
7 Added that
6 Fixed this
5 Created "my_branch" branch from rev 4 of trunk

Suppose you want to merge only revs 7 and 8 back into trunk. With a GUI client the intuitive thing to do is select those 2 revs and hit the merge button. If TSVN filled out the From/To fields as 7-8 you would actually only merge rev 8. That is why we do an automatic -1, and set the merge range to 6-8.

In fact the same thing happens in the ShowLog dialog when you "Revert changes from this revision". You select one revision and TSVN quietly does a merge of N:N-1 to undo the changes. In this case, the revision numbers are hidden internally, but it is exactly the same principle: you just select the revisions you want to revert/merge, which is the expected behaviour for a GUI client. TortoiseSVN is not just a wrapper for the command line client.

Usually this question comes up when someone wants to merge the whole branch back into trunk. In that case they often select 5-8 and then wonder why TSVN has used 4-8.

If you copied the branch from trunk directly in the repository, you only need to merge the changes you made on the branch. ie. select revisions 6-8 in the log dialog. However, it won't matter if you include the branch creation as well, because trunk@r4 is identical to branch@r5, so it makes no difference whether you include r5 or not.

If you created the branch by copying from a modified WC then (assuming you want to include those initial mods as well) you *must* include the branch creation so TSVN's use of r4 is correct. Using r5 would merge only the changes *after* branch creation.

Permission control for read and write operations

Access control is extensively covered in the : Subversion Book

Revision graph

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

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

Just to make this clear: this is not because we're lazy programmers 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.

There's no 'author' shown in the logs when I commit changes via svn+ssh.

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

TortoiseSVN does not recognize a file as modified!

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

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

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

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

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

TortoiseSVN doesn't work with VS.NET web projects!

VS.NET when used with web / asp projects can't handle the .svn folders that Subversion uses to store its internal information. This is not a bug in Subversion. The bug is in Visual Studio and the frontpage extensions it uses. Even though you might argue that Windows can't handle such foldernames, it's not correct. Windows can handle such folders very well, you just can't create them with the explorer.
The error message you most likely will get in VS.NET2003 is "Refreshing the project failed. Unable to retrieve folder informatin from the server."

As of Version 1.3.0 of Subversion and TortoiseSVN, you can set the environment variable SVN_ASP_DOT_NET_HACK. If that variable is set, then Subversion will use _svn folders instead of .svn folders. You must restart your your shell for those env variable to take effect

However, this bug applies only when you use web projects, which is not the same as ASP.NET projects. Usually, when you want to create an ASP.NET project, you choose to create a web project. But you can create or convert an ASP.NET project as a class project. With some minor tweaking, you won't notice the difference, and you then can use TortoiseSVN and SVN with .svn folders without problems.

There is a really good blog post that helps you to convert your ASP.NET web projects to ASP.NET class project. You can find it here: http://www.pluralsight.com/fritz/Samples/aspdotnet_without_web_projects.htm

If you follow those instructions, you'll have a VS.NET working with ASP.NET projects and Subversion without troubles.

Alternatively, upgrade your copy of VS.NET. The bug has been fixed in VS.NET2005, so it no longer has this problem.

TortoiseSVN seems very slow on big directories

To show you the file and folder icon overlays TortoiseSVN must fetch the status each time you open such a folder in the explorer. This usually takes a fraction of a second, but can take much longer if you have either a slow hard disk or a very big directory.

Here are a few things to watch out for:

• Network drives can be very slow to respond, so you may have to turn off icon overlays for such drives. However, the caching scheme usually makes it workable.
• Whenever the last modified time of a file changed, TortoiseSVN needs to do a complete diff (!) of that file to find out if it has changed. If you often change a file, undo the changes and save the file again you'll encounter a slowdown in browsing. You can fix that condition by doing a Cleanup of your working copy folders.
• There are several Virus scanners around that interfere with TortoiseSVN. Most of the time they lock files inside the .svn Status directory, which can cause TortoiseSVN to hang or to become very slow. Sometimes you might even get an Access Denied error.

  Try to configure your virus scanner so that it ignores .svn directories.

• If you're working on Windows XP then you can also disable the zipfolders. This will also increase the browsing speed.
  1. Select Run from the start menu
  2. Type regsvr32 /u %windir%\\system32\\zipfldr.dll at the prompt and click ok
  3. The change will take effect immediately, but you may have to restart Windows for all traces of the built-in ZIP support to disappear.

  If, at any time, you wish to re-enable Windows XP's built-in ZIP support, just follow these steps:

  1. Select Run from the start menu
  2. Type regsvr32 %windir%\\system32\\zipfldr.dll at the prompt and click ok
  3. The change will take effect immediately, but you may have to restart Windows for all traces of the built-in ZIP support to be available.
• Check your system for spyware, policy enforcement software, or local search engines (like Google desktop). Those can all interfere with normal use quite effectively.

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.

Where can I view/edit the list of ignored files for each directory?

Right-click on a folder, choose properties from the context menu, then switch to the Subversion tab in the properties dialog. The svn:ignore property contains a list of ignored files in that directory.

There's also a configuration in the settings dialog where you can set ignore patterns.

And last but not least, Subversion itself uses a config file for ignoring files.
You can edit the Subversion config file
(Settings->General->Subversion configuration file->Edit).

You will find a line in there:
[miscellany]
global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

Subversion creates this config file when first used.

Why is SVN checkout so much slower than CVS?

From the Subversion developer list:
---SNIP---
Svn manipulates lots of small files in the .svn/ area. (It journals all of its actions, for example.) And NTFS is tremendously slow at this, compared to Linux filesystems. For operations that are working-copy intensive, windows seems to be about 2x slower in this regard. There's nothing we can do about it (other than redesign all of the working copy code in svn 2.0.)
---SNIP---

This means that some operations which make a lot of changes to the working copy seem slow. This mainly affects the initial checkout.

On the other hand many operations are much faster. Subversion stores a local copy of the unmodified file, which means that you can diff your local changes without contacting the server at all. You can also revert your changes and start again. And because it has both the new and old versions, subversion only needs to transmit the differences to update and commit, so these operations tend to be much faster over external networks.

Some workarounds for very large projects:
Checkout only a part of your project, not the entire tree.
Run update only on subtrees.
Search for Slow in this FAQ to look for other articles.

I need another overlay for 'locked by others'

There is no way to tell if a file has been locked by someone else, so I need a new overlay to show that.

Unfortunately, that's not possible. Locking information is held in the repository, so in order to refresh the page in explorer, we would have to contact the repository. 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 use locking to prevent simultaneous editing, then you should consider using the svn:needs-lock property. Read the locking section in the manual to learn how to use this property. That way, files in your working copy will be read-only and have a grey overlay until you acquire a lock.

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

Renaming in explorer should work as 'svn rename'

When a version controlled file is renamed in Explorer, why can't you offer to rename in Subversion as well?

Firstly, we cannot access the explorer rename command as it is not part of the TortoiseSVN shell extension.

Secondly, even if we could find a way around that limitation, it would not be desirable. There are occasions when you want to rename only in explorer. Here are 2 examples:

• You have made some changes to a file. You need to revert to a known working version so you can get a bugfix out, but you want to keep a copy of the changed file. The easiest way is simply to rename the changed file, then update your working copy, allowing Subversion to bring back the missing file for you.
• You want to unversion a file, ie. delete it from Subversion, but keep the file. The easiest way is to follow these steps:
  1. Rename the file, eg. MyFile.cpp to MyFile.bak.cpp.
  2. Commit the parent folder, making sure the missing file (MyFile.cpp) is checked for deletion.
  3. Rename the file again (MyFile.bak.cpp to MyFile.cpp).

TortoiseSVN 1.5.0 will have the ability to 'repair' a move/rename which was done without using the Subversion commands. Repairing works by selecting two files where one is unversioned and the other missing, then choose "repair move" from the context menu.

Symbolic links should be supported

Tortoise SVN should make Unix symbolic links and MS-Window short-cut interoperable. At present, Unix links are converted into a text file.

Well, actually no. Windows Shortcuts are not symlinks, they aren't even close. Attempting to use one as a substitute for the other is a bad idea.

But doesn't Windows since Win2K support real posix-type links?

Again, no. Those links (which work on NTFS5 only, not FAT32) are not symbolic links but hard links. Those are completely different from symbolic links. Windows refers to them as reparse points. For example, the junction points for directories (which is what resembles the linux hardlinks the most) are created by using reparse points.

But I heard that Vista has real symbolic links.

Correct, Vista now has 'real' symlinks. But there are still some problems which will lead to incompatibilities anyway.

• it only works on Vista
• symlinks are limited to 31 per path (I don't think Linux has that limitation)
• only admins are allowed to create symlinks - which means the whole
  feature is pretty much useless in svn since (I hope) that most users
  don't have admin rights anyway

But finally, and most important of all, any such handling of links would have to be handled outside of TSVN. It has to be done in the Subversion library, or even better in the apr library.

TortoiseMerge should have editing facilities

In version 1.5.0 and later, TortoiseMerge has editing implemented.

Blank TortoiseSVN menus

Some applications don't display the TortoiseSVN menus properly. They can even be completely blank (no icons, no text)

This is because the icons are completely ownerdrawn. If you don't like the way TSVN handles its menu entries, you can do the following: Just create a (DWORD) registry entry under:
HKCU\\Software\\TortoiseSVN\\OwnerdrawnMenus and set it to 0. This will force TortoiseSVN to use the windows standard routine to draw menu entries. You'll have all the menu entries any time, but you will have ugly icons, since window's default only allows 10x10 icons. If you delete this registry key (the default) or set it to something else than 0 you have the nice icons back.
In case you want no icons at all you can set this value to 2. Then the context menu entries show up as text only.

Can I use TortoiseCVS and TortoiseSVN on the same computer?

Yes they can live happily together on the same PC. You can even use them on the same folder if that makes any sense to you. But, remember, that if you'll commit from this folder using one of the two, control files from the other system can be also accidently added to repository and versioned.

To avoid this problem for subversion you should run a script that does svn propset svn:ignore -F .cvsignore . in all project directories.

It can also happen that some of the overlay icons are not displayed. See also:
The overlay icons appear, but not all of them

Does a similar app also exist for Macs or Linux?

TortoiseSVN is only available on Windows, but there are similar applications available for Mac OS X and various Unices.

Here's a couple of examples.

• Mac OS X finder plugin - SCPlugin
• Unix graphical SVN client - eSVN
• KDE-integrated SVN client - kdesvn

If you think we've left out a major or interesting piece of software from this list, feel free to drop us a note on the mailing list.

For a more complete listing of both CLI and GUI Subversion clients and plugins, please consult this page.

External Diff Tools

This list is by no means complete, but might help you to find something:

• WinMerge
  a great open-source viewer
• Perforce Win Diff
  a free tool from Perforce. You can download the full installer here.
• Examdiff or Examdiff Pro
  an excellent Free or Shareware tool, The 3.2 version can handle unicode.
• Beyond Compare
  an excellent Shareware tool, can handle Unicode
• SciTE
  for showing unified diffs, it has built-in support for syntax-coloring, since it's not only a viewer but a Text Editor as well.

External Merge Tools

This list is by no means complete, but might help you to find something:

• WinMerge
  a great open-source viewer.
• Perforce Win Merge
  a free tool from Perforce. You can find the full installer here.

To set up the calling parameters for these external tools read the section External Program Settings of our Daily Use Guide.

PowerDesk 5

I have PowerDesk version 4.x or 5.x installed. Whenever I right click on a folder in PowerDesk or in Windows Explorer, the application crashes.

This is a bug in PowerDesk.

We would provide a direct link to the knowledge base article, but the PowerDesk website doesn't allow that!
So, to get the update for PowerDesk which fixes this problem, go to http://kb.avanquestusa.com and then search for the article named "PowerDesk crashes when right-clicking on some files and folders".

Removable drives cannot be unmounted

Sometimes when you try to unmount a removable drive, such as a USB pen drive, you get an error message saying that the device is still in use.

The problem here is that Windows only allows a short time after issuing the request to release handles, and TSVNCache.exe cannot always release all handles in time.

However, if you wait a few seconds and try unmounting again, it should work the second time.

Total Commander

TortoiseSVN is a native Windows Explorer Shell extension, so it's only available inside Windows Explorer. Other Commanders/Explorers available don't necessarily load the explorer shell extensions, and if they do we can't guarantee that they do that correctly.

However, as of version 6.5 you can show overlay icons in Total Commander. These How-To notes from Jochem Wendebaum may help you to get started.

1. Enable right-click functionality
   Go to Configuration -> Options -> Operation and choose "Left mouse button (Windows standard)" in the "Mouse selection mode".
2. Show overlay icons
   Go to Configuration -> Options -> Layout -> Display and enable "Show overlay icons, e.g. for links". In TortoiseSVN settings, go to the Look and Feel tab and uncheck the box labelled "Show overlays only in explorer".
3. Show explorer SVN columns
   Install the free "ShellDetails"-Plugin available at
   http://www.ghisler.com/plugins.htm#filesys
   Important note: in order to use it, make sure you read the documentation at
   http://www.lefteous.de/tc/docs/shelldetails/readme.htm#fieldsearchdirs

You will need to restart Total Commander after making these changes.
Total Commander Homepage: http://www.ghisler.com/

TrueCrypt volumes cannot be unmounted

When trying to unmount a TrueCrypt volume you may get an error message saying that the volume is in use.

This is a bug in TrueCrypt prior to the 4.3a release, not TortoiseSVN.

They didn't send the required window messages so that apps holding open handles can close them. TSVNCache waits for these messages (windows itself sends them when e.g. unmounting a flash drive) and then closes the handles. TrueCrypt didn't send those, that's why you can't cleanly unmount those drives when TSVNCache is running.

In the meantime, here's another hint you can try:
If you mount drivecrypt always to the same drive letter, you can specify that path to the exclude list of the overlays (overlay page in the settings dialog). For example, if you always mount drivecrypt to g:\, put "g:\" into the "exclude paths" - next time the cache (TSVNCache.exe) starts up (kill it or next time you restart your computer), the cache won't monitor that drive anymore and therefore won't open any handles there.

Update
The bug is said to be fixed in the 4.3a release of TrueCrypt. Note that this version still identifies itself as simply 4.3 in the about box. The download, however, is "truecrypt-4.3a.zip.

Does TortoiseSVN support SSH?

TortoiseSVN uses Subversion. And Subversion supports SSH svn+ssh:// (repository reachable via svnserve). If you don't want to use the svnserve server but Apache instead (which we would recommend!) then Subversion supports secure connections via SSL.

A guide on how to secure your Apache server with SSL can be found in the TortoiseSVN Daily Use Guide

Please have a look at the subversion book and the INSTALL file of subversion on how to use svn+ssh://

Subversion / TortoiseSVN SSH HowTo

(revision 0.5 by (c) Marc Logemann)

Because many new subversion users run into problems when attempting to use subversion with SSH, I compiled a HowTo for that issue. Perhaps I will expand this HowTo later on and submit it to the Subversion or TortoiseSVN docs.

-------------------------
Our Scenario:
-------------------------
Server: Linux or unix like system
Client: Windows 2000/XP (or variant)

-----------------------------------------
Installing subversion (server)
-----------------------------------------
I won't go into details here, because this topic is covered in great length in the official Subversion documentation. But one thing I want to point out nevertheless. If you compile subversion from source and don't provide any argument to ./configure, Subversion creates a "bin" directory under /usr/local and places its binaries there. This is no problem as long as you run subversion as daemon, but if you want to use tunnelling mode with SSH, you have to be aware that the user logging into via SSH can execute the svnserve program and some other binaries. For this reason, either place /usr/local/bin into the PATH variable or create symlinks of your binaries to the /usr/sbin directory or any other directory which is commonly in the PATH.

To make sure that everything is OK. Login in with SSH and the target user to the system later on and type: "which svnserve". This command should tell you if svnserve is reachable.
To check if svnserve is available through ssh, type: "ssh svnserve"

Furthermore this document assumes that you already have a subversion repository created with "svnadmin create". Please pay attention to the ACL of the repository in order to reduce possible problems. Check that each user coming in via SSH has appropriate rights to work with the repository.

Sometimes your system has 'mesg y' put into the global bashrc file. This will make connections with TortoisePlink fail, since that line will make SSH throw out an error "stdin: is not a tty". You must remove that line from your bashrc file.
------------------------------------------------
OpenSSH and certificates (server)
------------------------------------------------
Again I wont go into details about OpenSSH installation as this is covered elsewhere better. But on most systems, enabling SSH is just a matter of installing an RPM. If you rent a pre-installed linux server from a hosting company, SSH is most likely already installed. To be sure everything is in place, type: "ps xa | grep sshd" and watch out for SSH jobs.

Assuming OpenSSH is installed, one of the most important steps is to create a keypair for authentication. There are two possible ways of creating the keys. The first way is to create the keys with puttygen (a program of the putty family), upload the public key to your server and use the private key with putty. Because of some problems with this approach, I prefer the other way. This way creates the keypair with the OpenSSH tool ssh-keygen, downloads the private key to your client and converts the private key to a putty-style private key.

Lets do this step by step:

- login to your server
- type: ssh-keygen -b 1024 -t dsa -N passphrase -f mykey
- change "passphrase" to a secret keyword only you know
- type: ls -l mykey*

We just created a SSH2 DSA key with 1024 bit keyphrase. You will see two files. One named "mykey" and one named "mykey.pub". As you might guess, the .pub file is the public key file, the other is the private one. Next create a user on the server with a home directory:

- type: useradd -m myuser

You will have a directory under /home with the name "myuser", create a new directory in "myuser" called ".ssh":

- type: cd /home/myuser
- type: mkdir .ssh

Then go to the directory where you created your keys and copy the public key to the .ssh userfolder with the following command:

- type: cp mykey.pub /home/myuser/.ssh/authorized_keys

or if you already have some keys in place

- type: cat mykey.pub >> /home/myuser/.ssh/authorized_keys

Please pay attention to the filename, it really must be "authorized_keys". In some old OpenSSH implementations, it was "authorized_keys2". Now download the private key file to your client computer. Remember, the file was "mykey"

------------------------------------------------------------
SSH key generation and connection check (client)
------------------------------------------------------------
Grab the tools we need for doing SSH on windows on this site:
http://www.chiark.greenend.org.uk/~sgtatham/putty/

Just go to the download section and get "Putty", "Plink", "Pageant" and "Puttygen"

In order to use the private key we get from the server, we have to convert it to a putty format. This is because the private key file format is not specified by some standard body. To do this we simple open "puttygen" and open the "conversions" menu and chose "Import Key". Then browse to your file "mykey" which you got from the server enter your provided passphrase upon creation of the key. Finally click "Save private key" and save the file as "mykey.PPK" somewhere on disk.

Now we are ready to use this key for the first time to test the connection. In order to do this, we open the program "putty" and create a new session like this:

Session->HostName: Hostname or IP Adress of your server
Session->Protocol: SSH
Session->Saved Sessions: MyConnection
SSH->Prefered SSH Protocol version: 2
SSH->Auth->Private Key file for auth: $PATH$\mykey.PKK (replace $PATH$ with real path to the mykey.PKK file)

Then go back to Session tab and hit "save" button. You will see "MyConnection" in the list of available connections.

Next click "open" and you should see a telnet login prompt. Use "myuser" as username (without double quotes of course) and if everything is OK, you don't have to provide a password to your system. If the system still requires a password, something went wrong. See Debugging Section of this HowTo.

-----------------------------------------------
Testing SSH with TortoiseSVN (client)
-----------------------------------------------
After installing TortoiseSVN right click on some folder inside your Windows Explorer. You will see a menu item called TortoiseSVN->RepoBrowser. After opening the browser you have to enter a URL like this:

svn+ssh://myuser@MyConnection/usr/local/repos

Lets talk briefly about the URL (if you need more infos, check the subversion docs). The Schema name is "svn+ssh", this tells Tortoise how to handle the requests to the server. After the double slashed, you can provide the user which is trying to connect to the server, in our case this is "myuser". After the "@", we supply our putty session name. This session name contains all details like where to find the private key and the servers IP or DNS. Last we have to provide the full path to the repository. Its assumed that a subversion repository resides at /usr/local/repos

If you submit the URL, you will see an opened tree on the next screen until the node "repos". Yet, there has not been made any connection, because the tree representation comes from the supplied URL. When you hit the "+" button in front of "repos", the connection will be established and you will see the "+" sign disappearing if you don't have anything in the repository or you will see your already imported projects and files.

Right now, you should have a running SSH Tunnel in conjunction with TortoiseSVN.

-----------------------------------------------
Configuration Variants (pageant)
-----------------------------------------------
Now I will continue to show some configuration variants, that can be helpful during everyday work.

One way to simplify the URL in TortoiseSVN is to set the user inside the putty session. For this you have to load your already defined session "MyConnection" in putty make the following entry:

connection->Auto Login username: myuser

Then save your putty session as before and try the following URL inside Tortoise:
svn+ssh://MyConnection/usr/local/repos

This time we only provide the putty session "MyConnection" to the SSH client TortoiseSVN uses (TortoisePlink.exe). This client is capable of checking the session for all necessary details like loginuser or server ip.

Some people like using pageant for storing all their keys and in fact each howto explains that it is important to place your keys there. In fact, because a putty session is capable of storing a key, you don't need pageant for normal business. But imagine you want to store keys for several users, in that case, you would have to edit the putty session over and over again, depending on the user you are trying to connect with. For this situation pageant makes perfectly sense, because when putty, plink, TortoisePlink or any other putty-based tool is trying to connect to a SSH server, it checks all private keys that pageant carries to initiate the connection.

For this task, simply start pageant and add a key. It should be the same private key you defined in the putty session above. If you use pageant for private keys storage, you can delete the "SSH->Auth->Private Key file for auth" section inside your putty session. You can add more keys for other systems or other users of course. If you don't want to repeat this procedure after every reboot of your client, you should place the pageant in autostart group of your windows installation. You can append the keys with complete paths as command line arguments to pageant.exe

The last way to connect to a SSH server is by just using this URL inside TortoiseSVN:

svn+ssh://myuser@100.101.102.103/usr/local/repos

As you can see, we dont use a saved putty session but an IP address as connection target. We also supply the user, but you might ask how the private key file will be found. Because TortoisePlink.exe (the standard SSH client for TortoiseSVN) is a modified version of the plink tool from the putty suite, also TortoiseSVN looks for a running pageant and will try all the keys stored in pageant.

----------------------------------------
Debugging / Troubleshooting
----------------------------------------

See the other articles in the SSH section of our FAQ

-------------------
Feedback
-------------------
For comments or corrections on this howto, please use the TortoiseSVN mailinglist on http://tortoisesvn.tigris.org/

This is a copy of the original at: http://www.logemann.org/day/archives/000099.html
Thanks to Marc!

SVN+SSH+public key authentication on Windows Box as server

This walkthrough on getting SVN+SSH up and running on a Windows Box was provided by Thorsten Möller
Thanks!

Hi all,

I just want to provide my solution to the community since I have found out that there might be many people struggling with the same issue.

1. Server: Install Cygwin SSH daemon as described here: http://pigtail.net/LRP/printsrv/cygwin-sshd.html
2. Install SVN on the server (as described in the Subversion doku)
3. Server: Create an account (for instance "SVNuser") which you will later use for logging in. Check that the user permissions are sufficient to read and write your SVN repository directory on the server.
4. Server (if not already done): Open Cygwin console and run mkpasswd -l > /etc/passwd
5. Client: Download PuTTY and PuTTYgen (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)
   and place it in a directory which is part of the PATH, for instance C:\Windows
6. Client: Create a key pair with PuTTYgen an save the keys.
7. Transfer the public key to the server file: /home/<svnuser>/.ssh/authorized_keys
8. Create a PuTTY session for loggin in to the server as described here:
   Subversion / TortoiseSVN SSH HowTo.
   Do not forget to activate auto login, i.e. set the user name.
9. Test whether you can log in to the server with the key.
   Server: If that works you might want to disable password authentication for SSH by editing /etc/sshd_config. Change/edit lines as follows (and restart SSH service afterwards):
   PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
10. Server: Modify /home/<svnuser>/.ssh/authorized_keys as follows. Note that every user which is supposed to use SVN uses the same login but a different key, thus you have to add one line for every user/key.

    Note: This is all on one very long line.
    

    command="svnserve -t -r c:/mySVNroot/ --tunnel-user=<SVNuser>",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa <thePublicKey> <publicKeyComment>

    The trick here is to use the slash instead of backslash to specifiy the SVN repository root:
    -r c:/mySVNroot.
    Another important thing is --tunnel-user=<SVNuser>.
    Since all users later will do a SSH login with the same login name (but different keys) you have to map each key to a SVN user - remember that SVN maintains its own users/userrights.

11. Client: Access the repository with a URL like:

    svn+ssh://<PuTTYSessionName>/<MyRepository>/trunk

In various documentations and news group postings you will read that the URL has to contain the real path on the server. But this is not neccessary if the -r parameter was set correctly, see 10. I swear, for me it works fine :-)

Thorsten

How do I get client certificates to work?

Sent to the TortoiseSVN mailing list by Nigel Green, Thanks!

The final workaround that I came up with may well be helpful to others trying to solve the same problem, so I thought it worthwhile to detail my findings below ........

What I was trying to achieve was a single server containing 2 virtual SSL hosts: The first one was for public access, with no requirement for a client certificate. The second one was to be totally secure with a required client certificate, running a Subversion that I could access with TortoiseSVN.

Adding a "SSLVerifyClient Optional" directive to the "per-server" section of the Apache configuration (i.e. OUTSIDE of any "VirtualHost" and "Directory" locks) forces Apache to request a "Client Certificate" in the initial SSL handshake. It appears to be essential for TortoiseSVN that the certificate is requested at this point. TortoiseSVN does not appear to work with Client Certificates if the SSL connection is re-negotiated. [I understand from quotes on the web that this is a bug in mod_ssl which is used by TortoiseSVN.]

However, this left me with a big problem. As the "SSLVerifyClient" directive is server-wide, it seemed that I could not make one virtual host require client certificates, and the other one not. I could not put any other "SSLVerifyClient" directives in the host configuration, as they are overridden by the server-wide directive, and I could not move the "SSLVerifyClient" directive to a "per-directory" level as TortoiseSVN would not cope with the SSL re-negotiation. A different approach was called for. In the end, the solution was quite simple; to add the following directive to the virtual host Directory that I wanted to lock down for Subversion:

SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"

This directive grants access to the directory only if a client certificate was received and verified successfully. i.e. it was just what I wanted to achieve.
So to summarise, the relevant lines of my new Apache configuration that solve this problem are:

-----------------------------------------------
SSLVerifyClient Optional

### Virtual host configuration for the PUBLIC host (not requiring a certificate)

<VirtualHost 127.0.0.1:443>
  <Directory "pathtopublicfileroot">
  </Directory>
</VirtualHost>

### Virtual host configuration for SUBVERSION (requiring a client certificate)
<VirtualHost 127.0.0.1:443>
  <Directory "subversion host root path">
    SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
  </Directory>

  <Location /svn>
    DAV svn
    SVNParentPath /pathtorepository
  </Location>
</VirtualHost>

How do I disable http access once https is working?

Add the directive SSLRequireSSL to your Subversion <Location> block in the Apache config file.

How do I re-configure the client certificate for Tortoise SVN?

Settings-Dialog, "Clear Auth Cache" button.

I am getting the password dialog over and over again

TortoiseSVN (or better its SSH client TortoisePlink) can't find a key for the current user. Run pageant and add your private key or define a putty session with a private key included.
Try saving another copy of the key after clearing the passphrase and use that new key. Putty no longer prompts for a passphrase.

PuTTY keeps showing 'Invalid port number'

When trying to log in, I kept getting an "Invalid Port Number" from putty.

The message comes up if the user has already made an SSH connection using the Putty saved session. To avoid the error, you need to use a "Saved Session" that has never been used before.

If that doesn't work:

• leave the SSH client field blank (which makes TortoiseSVN use TortoisePlink)
• when you enter the URL of the repository, use the name of the saved session. For example, if your session name is MyConnection, use MyConnection instead of e.g. www.example.com

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

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

The reason for this error is either:

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

or

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To solve this issue you have the following options:

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

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

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

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

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

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

Unknown hostname abc.net

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

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

Working copy is out-of-date

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

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

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

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

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

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

Apache Error Messages

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

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

These error messages hint at configuraton problems:

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

SVN+SSH Error Messages