A new version of the CommitMonitor is out.
It contains some bugfixes and also some new features.

You can get it from our Tools download page. The changelog is also available at the bottom of the download page.

A lot of people asked on our mailing lists how they can "unversion a working copy", "detach/unlink a working copy from the repository", "remove files from version control" or something like that. All those questions lead to the users wanting to remove the hidden .svn folders inside every Subversion working copy.

Usually, you want a "clean copy" of your versioned files for zipping, archiving, ...
The command in Subversion to do that is "Export". Exporting a working copy or a repository url will create a copy of all your files, but without those .svn folders. But the export command creates a copy, it does not remove the .svn folders from an existing working copy. Which is what most users want.

But some users really want to just make a working copy unversioned. Searching the web you can find a lot of users posting scripts which scan a path recursively and delete all those .svn folders. But if you have TortoiseSVN installed, that isn't needed:

TortoiseSVN has a little known feature built in which can do exactly that: it removes all .svn folders automatically. So where can you find that feature?
Use the "Export" command! But hey, didn't I just tell you that the export command creates a copy of the files in your working copy and doesn't change your original working copy? So how can the export command remove the .svn folders from an existing working copy?
Simple: when you right-click on a working copy and choose "Export..." from the context menu, a folder browse dialog is shown where you can choose the folder where you want the working copy exported to. If you now select the very same path that your working copy is on as the target (i.e., you're exporting the working copy onto itself), TortoiseSVN will remove all .svn folders of that working copy.

Another way to do this is by right-dragging the working copy onto itself. The Explorer doesn't allow dragging items onto themselves in the same window though, so you must either use a second Explorer window or drag onto the tree view as shown in the animation below:

Hi Folks,

We need people that help to translate the GUI of TortoiseSVN into the following languages:

Macedonian: Srdjan was too busy to do much for the Macedonian translation this year, which is the reason why I'm looking for additional help. The translation is 75% complete, so it's easy to catch up. Volunteers please :)

TortoiseSVN 1.5 allows using plug-ins for specific issue trackers.

They're implemented as COM-objects using the IBugTraqProvider interface and allow for example to show a list of open issues directly from the commit dialog.

Gurtle is the first open-source plug-in available, which integrates TortoiseSVN with the issue tracker for projects hosted at Google Code.

If you have a project hosted there, you should give Gurtle a try. Even though its version number is at the time of this writing 'only' at 0.2, it's already stable enough for everyone to use.

Subversion repositories served with Apache have the nice built-in feature: the repositories can be browsed with any webbrowser at no additional cost.

For Subversion repositories served via svnserve, this is not possible because browsers don't understand that protocol.

Until now:
The SVNProtocolHandler for Internet Explorer allows browsing svn:// urls from within the Internet Explorer. No need to install a Subversion client, just use IE. This also adds the benefit that you can click on svn:// links and quickly the URL you received from a colleague via email.

Note: the protocol handler only works in Internet Explorer. Firefox users either have to switch back to IE for svn browsing or hope someone will create an svn:// handler for them.

The installer for the SVNProtocolHandler can be found on the download page.
Note: even though the SVNProtocolHandler is developed by Stefan Küng, it is not part of TortoiseSVN and won't be included in TortoiseSVN either. It will remain a separate download, and it has its own project page.

Fetching the log for slow or very big repositories can take quite a while. And of course, it requires you to be connected to the repository. You can't show the log messages if you're not online - very annoying if the network is down or you're in a place where you don't even have network access.

To at least partly solve this issue, TortoiseSVN 1.5 can cache the log messages from Subversion repositories. The feature is implemented transparently, which means you won't have to do anything to make this work. All you might notice is that once you showed all log messages for your repository, the next time the log dialog is a lot faster.

If you want to test this, you can show the log for the TortoiseSVN repository (username: guest, leave password empty). Click on the "Show all" button in the log dialog to get all log messages. You will notice that it takes a while to fetch all messages. If you then close the log dialog and start it again for the same URL, you can click the "Show all" button and all messages are fetched from the log cache.

In case you can't connect to the repository, the log dialog will show you a dialog where you can choose to "work offline", i.e., it won't try to connect to the repository anymore but only use the cache:

However, there is one problem: the log cache relies upon all your repositories having different UUIDs assigned to them.
You can see the UUID of your repositories if you have a working copy of them in the properties dialog (Explorer context menu 'properties'):

The log cache needs the UUID to distinguish between different repositories which of course have different log messages. The reason the log cache can't use URLs alone to distinguish between repositories is that URLs just don't provide that information.

For example, an URL like

http://example.com/svn/trunk

would clearly indicate that the repository is located at http://example.com/svn. Because we can assume that 'svn' is not a project name.

But an URL like

http://example.com/svn/project/trunk
could mean that it points to a repository for 'project', but it could also mean that there's only one repository at 'svn' and 'project' is just a folder inside that repository. So the two URLs
http://example.com/svn/project/trunk
and
http://example.com/svn/otherproject/trunk
could be pointing to the same repository, or to two different repositories.

That's why the log cache must rely on the repository UUIDs to be different for every repository.

Now, some people made the mistake of creating new repositories by simply copying a default (empty) repository. By doing that, all repositories have the same UUID! Yes, this is a big mistake: it's called UUID for a reason: the 'U' stands for "Unique". This will confuse the log cache completely and you will get the crash report dialog showing up a lot.
To fix this, you have to set a unique UUID for every one of your repositories. Get the svnadmin tool from the official Subversion package and run:

svnadmin setuuid REPOS_PATH

on every one of your repositories.

In case you don't have direct access to your repositories or you can't change the UUID for some other reason, you can disable the log cache in the TortoiseSVN settings dialog:

In the above screenshot, you may notice the option "Allow ambiguous URLs". Now that I've told you that the cache relies upon the UUIDs being different, why does it also rely on URLs?
Comparing URLs (i.e., simple strings) is much faster than asking the repository or the working copy for the repository UUID. So the cache uses URLs too if possible. For example, if the cache knows that the URL
http://example.com/svn/project/trunk
points to a specific repository, it also knows that the URL
http://example.com/svn/project/trunk/subfolder
points to the very same repository, since it's not possible to have a repository inside a repository.

The option "Allow ambiguous URLs" is for situations where the same URL is used for different repositories - those situations are very rare of course. One situation we ran into problems was with svnbrigde. That's a nice tool which allows you to access MS Team System repositories with an svn client. But older versions of that tool made all repositories accessible for svn clients at the same URL.
Once we discussed the issue with the svnbridge developers, they had a version ready in almost no time which provided different URLs for the different Team System repositories. So with the latest version of svnbridge, you should not run into that problem. But if you can't update your version of svnbridge for some reason, you have to activate the option "Allow ambiguous URLs".

During the last few weeks, I got a lot of crash reports for TortoiseSVN which indicated that a certain date API returned bogus data, which either lead to a crash (hence the crash reports) or garbled date strings in various TortoiseSVN dialogs (these were reported on our mailing lists).

Monitor your repository with the CommitMonitor:

The CommitMonitor is a small application which sits in the system tray or runs in the background, checking Subversion repositories for new commits.

There is a new tool available on our tools site called grepWin, a regular expression search and replace tool for Windows. Of course, it can also do normal text searches :-)

More details about grepWin are available here.

TortoiseSVN won the SourceForge.net community choice award 2007 in the category "Best Tool or Utility for Developers: The project most likely to help you make the best of your precious coding time".

Thanks for voting for us!

Some people say that these awards are the 'open-source Oscars'. So that means we're expected to give a