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.