What's New in TortoiseSVN 1.5
Details are described below.
TortoiseSVN 1.5 is a superset of all previous TortoiseSVN releases, and is considered the current stable and "best" release. Anything in 1.0.x, 1.1.x, 1.2.x, 1.3.x or 1.4.x is also in 1.5, but 1.5 contains features and bugfixes not present in any earlier release.
Older clients and servers interoperate transparently with 1.5 servers and clients. Of course, some of the new 1.5 features may not be available unless both client and server are the latest version. See the table below about which features require which versions:
All other features are independent of the server version and can be used without any restrictions.
For a more detailed compatibility table, see the Subversion release notes.
Due to certain improvements made to the working copy library, the version number of the working copy format has been incremented. This means that Subversion clients earlier than 1.5 will not be able to work with working copies produced by Subversion 1.5. Similarly, the repository format has changed as well, meaning that pre-1.5 Subversion tools that normally access a repository directly (e.g.
svnadmin) won't be able to read a repository originally created by Subversion 1.5.
WARNING: if a Subversion 1.5 client encounters a pre-1.5 working copy, it will automatically upgrade the working copy format as soon as it touches it, making it unreadable by older Subversion clients. If you are using several versions of Subversion on your machine, you need to be careful about which version you use in which working copy, to avoid accidentally upgrading the working copy format. This "auto upgrade" feature, however, does not occur with the new repository format.
Have a look at the Subversion FAQ about the working copy format change.
Merge Tracking in Subversion 1.5.0 is roughly equivalent in functionality to svnmerge.py, recording and using merge history to avoid common cases of the repeated merge problem, and allowing for cherry-picking of changes. It exposes merge history via properties, and allows for repository dump/load (including the ability to re-create the merge history index).
Note: Some merge tracking features can't be used for repositories served by pre-1.5.x servers.
When working on a branch, Subversion now tracks each revision which gets merged. This makes it easier to merge changes e.g., from trunk because it is possible to always merge the whole revision range without the risk of merging the same revision twice. Subversion will automatically omit the already merged revisions when doing the merge.
When showing the log from the merge dialog to find the revisions to merge, TortoiseSVN shows the already merged revisions grayed out as a visual hint. If a grayed out revision is selected, Subversion does not merge that revision again because it was already merged.
Record Manual Merge
To block a revision from being merged, TortoiseSVN provides a button in the merge dialog named "record only". This will tell Subversion that the revision has already been merged, without doing the merge itself.
When inspecting revisions with the log dialog, the messages of revisions where a merge occurred aren't usually very useful. Most people write log messages in the form "merged revisions XXX to YYY from /branches/ZZZ" or something similar. But what's really interesting when examining the log of a folder/file would be the log messages of all the revisions that got merged.
TortoiseSVN can show you those log messages if you want. The log dialog has a checkbox which when activated will fetch all the log messages of merged revisions. The log entries of merged revisions are shown a little indented.
Many users have very large trees of which they only want to checkout certain parts. In case of folders with many subfolders, some of the subfolders might not be needed.
TortoiseSVN provides the user with a combo box to choose the depth of a checkout:
- Fully recursive
- Immediate children, including folders
- Only file children
- Only this item
The depth of the checkout is remembered, so that a later update will respect that depth and not fetch everything again.
Cyrus SASL support for
In Subversion 1.5, svnserve can use SASL (Simple Authentication and Security Layer) for authentication and data encryption. TortoiseSVN has SASL implemented too. The following SASL authentication methods are available with TortoiseSVN 1.5:
SASL also provides data encryption in some of these methods, so you can secure your data while it is being transmitted over the internet. Securing your connection using SASL should be easier than setting up an SSH infrastructure.
Sometimes you are working on several different problems at once in your working copy, and it becomes difficult to track which files are involved in which change. TortoiseSVN now allows you to group files together into logical changelists. These appear in the Commit dialog and the Check for Modifications dialog. As well as giving a visual indication, you can also select groups for commit.
TortoiseSVN also provides a special changelist named ignore-on-commit. Files which belong to that changelist are not selected in the commit dialog. This helps if you have a file which you must keep versioned but which you don't want its modifications to get committed.
Fetching the log information from the repository can take a long time, especially for repositories with thousands of revisions or if the repository is not on a fast connection.
TortoiseSVN 1.5 can cache the log entries on the local drive. Only the entries which are not yet in the local cache are fetched from the repository.
The log cache improves the performance not only of the log dialog but also of the revision graph.
The repository browser has been completely rewritten and now more resembles the Windows explorer. It has two panes, with a tree view on the left and the file/folder list on the right.
Part of the rewrite also includes a performance improvement when showing very big directories.
It is also possible to drag files/folders from the repository browser directly to the explorer as a fast way to save/export those files/folders.
The revision graph has changed dramatically since the previous release. Apart from using the log cache if available, it is also much faster when analyzing the log data.
A small window on the top right of the graph shows an overview of the whole graph.
The new revision graph has much more options to tweak the output. For example, the direction of the graph, how the nodes are arranged in the graph or which nodes/paths/urls should be filtered out completely.
Client-side hook scripts
TortoiseSVN allows the execution of client side scripts before and after certain operations. The available hooks are:
- Start Commit Hook
- Called before the commit dialog is shown
- Pre-Commit Hook
- Called after the commit dialog is shown, but before the actual commit
- Post-Commit Hook
- Called after the commit is finished
- Start Update Hook
- Called before an update, before the repository is contacted
- Pre-Update Hook
- Called before the update, but after the revision to which the update is done is known
- Post-Update Hook
- Called after the update has finished
- Line endings
- inconsistent line endings are handled properly, including MAC line endings
- Changes made during conflict resolving can be reverted one by one
- The target file can be edited directly in TortoiseMerge without the need to use a text editor
The SubWCRev tool now has a COM interface for easy access from scripting languages. This makes it possible to embed the revision information in e.g., Microsoft Word documents.
If you're using other Tortoise clients like TortoiseCVS you might know about the problem with the limited overlay slots in Windows. With both TortoiseSVN and TortoiseCVS installed, some of the overlays won't show up anymore. This is due to the fact that Windows only has about 12 slots available for overlays and with both applications installed, that limit is exhausted.
To solve this issue, we've implemented a common overlay handler for all Tortoise clients to use. With this handler, all Tortoise clients will show the same overlay icons and use the same overlay slots. That way we won't hit the Windows limit so easily anymore.
TortoiseSVN 1.5.x and the TortoiseCVS unstable releases already use this new overlay handler.
Due to this new overlay handler which shares the overlays, TortoiseSVN gained two new overlays: for unversioned and ignored files there is now an overlay too.