TortoiseSVN 1.2 Release Notes
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
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
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 (user 'guest' as username and '' as password)
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
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