Log cache and repository UUIDs

Posted on Autugst 17, 2008

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. 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, a URL like https://example.com/svn/trunk would clearly indicate that the repository is located at https://example.com/svn. Because we can assume that 'svn' is not a project name.

But a URL like https://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 https://example.com/svn/project/trunk and https://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 https://example.com/svn/project/trunk points to a specific repository, it also knows that the URL https://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 Microsoft 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".