What's New in TortoiseSVN 1.2
- Optional locking ("reserved checkouts")
- New, much improved overlay cache
- Better use of overlays when co-existing with TortoiseCVS
- Many improved dialogs
- Many bugfixes
- Implemented all new Subversion 1.2 features
- Linked against SVN 1.2
TortoiseSVN 1.2 is compatible with 1.0 and 1.1 servers. Of course, some of the new 1.2 features may not be available unless the server is upgraded to the latest version.
If you access a BDB repository using
file:// access you will need to update that repository to BDB 4.3 format. Instructions on how to do that can be found on the Subversion FAQ page
Subversion 1.2 introduces an alternative history storage mechanism known as xdelta differencing. Reconstructing older data from repositories stored in the new format is much faster, resulting in a noticeable speedup for operations such as blame, checkout, diff and merge. Although converting repositories is not required, you may wish to do so in order to gain faster access. To do that you need to perform a dump/load cycle using the command line svnadmin tool. Look at the Subversion Manual for instructions on how to do that.
The Windows 98/Me and Windows NT 4.0 operating systems are no longer supported in TortoiseSVN 1.2. That's not because we want to be unfriendly, but because there are just too many incompatibilities in these older OS versions which we have to work around, and as none of the developers use these systems it is impossible to test and debug properly. If you want to use TortoiseSVN with these systems, you should use the 1.1.x line which is still available from our download page.
File Locking (also requires updated server)
"Locking" is a long-requested feature, often known in other systems as "reserved checkouts". While Subversion is still primarily a copy-modify-merge system focused on parallel development, there is widespread acknowledgement that not all files are easily mergeable — binary files in particular, such as artwork, compressed files, proprietary binary formats, or any other non-line-based data.
The goal of the new locking feature is twofold. First, provide a means to force serialized write-access to a file. Second, provide a communication mechanism to prevent users from wasting time on unmergable changes.
The first goal is accomplished using file locks. TortoiseSVN has new context menu entries to
Get Lock and
Release Lock. When a user locks a file, no other user may commit a change to the file or delete it from the repository.
Locks can also be stolen or broken, say if the person who locked a file goes on holiday and forgets to unlock. New lock hooks are available to system administrators to set their own locking policy. Refer to the Subversion documentation for details on repository administration.
The second goal — preventing a user from wasting time on an unmergable change — is accomplished via a new property,
svn:needs-lock. Users (or administrators) are encouraged to set this property on any file that is unmergeable. When present, this property causes the file to be read-only unless the working copy holds a lock-token for the file, in which case the file is read-write. TortoiseSVN uses a new status overlay to indicate when a file is in the read-only state, which warns you that you need to acquire a lock before editing.
Warning: if you have a team of users all accessing a repository via
file://, then all users must use 1.2 clients. Pre-1.2 clients will unknowingly ignore locks.
New External Status Cache
TortoiseSVN has always had a recursive overlay feature whereby overlay changes in lower level folders are propagated up through the folder hierarchy so that you don't forget about changes you made deep in the tree. However, in previous releases this feature was only useable with very small working copies due to the delay in getting the status information.
In release 1.2, a new
TSVNCache program is used to maintain a cache of your working copy status, providing much faster access to this information. Not only does this prevent explorer from blocking while acquiring status, but it also makes recursive overlays workable.
Note: Explorer is much more responsive with the new cache because it displays pages before the full information is available and refreshes as required. This means that the status you see immediately may not be recursive but the non-recursive status. Depending on the size of your working copy it may take a second or two for the recursive status to filter through.
Subversion has always suffered from a speed problem if the timestamp on a file changes and the content doesn't. This forces subversion to do a byte-by-byte compare of the file with BASE to check whether it has really changed. In this new release, you can fix such timestamp mismatches using the
Cleanup menu entry. If your WC has become slow to check, try doing a cleanup.
Better Use of Overlays
Windows supports only 15 icon overlays, and uses 3 of these itself. If both TortoiseSVN and TortoiseCVS are installed there are simply not enough overlays for both applications.
In this release, TortoiseSVN checks to see how many overlays are required by other apps, and only installs essential ones if there are not enough for everyone. It also displays an alternative overlay if the preferred one is not available. For example if the
Added overlay is not available, the
Modified overlay will be used instead.
Enhancements and Bugfixes
This is a major new release, and almost all the main dialogs have been improved in some way, either to add new features or to make them easier to use. Some of the main ones are mentioned below, and there have also been many minor bugfixes. To see the full list of changes check the ChangeLog
This has been changed considerably to make the difficult subject of merging easier to understand and use. You can now select revisions to merge using the revision log dialog, without trying to work out the correct numbers to insert in the revision boxes.
New filters allow you to search within the log messages, or restrict to a date range.
The new Subversion 1.2 API allows you to fetch a given number of log messages rather than the log messages for a given number of repository revisions. This makes it much easier to display a useful number of messages, and to get more messages as required.
Note - this feature works best with Subversion 1.2 servers. It will work with earlier servers, but will be slow. The server does not understand the new parameter and returns all log messages, which the Subversion client then filters. This results in very slow response. TortoiseSVN has a setting which allows you to use the old API in case you need to work with an older server.
You can now compare two revisions of a folder. TortoiseSVN will list the files which have changed, allowing you to diff each one individually.
You can now resize the 3 panes of the log dialog individually.
The log dialog has a number of other new context menus, allowing you to do more.
Autocompletion now picks up some language-dependent keywords (usually class/method/variable name) using regular expressions.
Bugtracking integration has been extended using regular expressions, making it easier to pick out your issue IDs. Read about this in the Issue Tracker Integration Spec.
Comment history is now inserted at the current cursor position, rather than always at the beginning of any existing message.
Several new context menu entries, allowing you to export or checkout directly from the browser.
Open files using the Windows file association, or a program of your choice.
Subversion 1.2 adds extra functionality to the Cleanup command so that it now makes more repairs. If the timestamp of a working copy file does not match Subversion's recorded timestamp, but the file length does match, Subversion does a byte-by-byte check to see if the files really are different, and that can slow down status checks.
Cleanup now checks these files and if the content matches, it resets its record of the timestamp so that future checks will run faster. If your working copy is very slow to produce the list of files in the
Check for Modifications and
Commit dialogs, try running
Cleanup on your working copy. If you used the
Use commit timestamps option, you should definitely do this.
The settings dialog now has an updated interface which is less crowded and easier to use. The options are also grouped in a more logical manner, so you know where to look for things.
You can opt to ignore case differences when viewing file difference. This is useful for VB source, which sometimes gets changed by the IDE.