Published on (
 See this if you're having trouble printing code examples

Subversion UI Shootout

by Jeremy Jones

Subversion is a revision control system intended to be a better CVS. The three "featured projects" on the Tigris page under the SCM category are Subversion, TortoiseSVN, and RapidSVN. This article compares some of the major features of Subversion among the three featured clients (the CLI, RapidSVN, and TortoiseSVN) and some principles around the usability of tools that have both CLI and GUI incarnations. As it discusses a feature where either the CLI or GUI is superior to the other and a general principle is apparent, it points out the principle of superiority.


TortoiseSVN integrates with Windows Explorer and makes all of its features available there. All commands are available through context-sensitive right-click menus in Windows Explorer. Here are the options available on a file that a user has changed in the local repository:

Thumbnail, click for full-size image.
Figure 1. TortoiseSVN features in Windows Explorer. Click for full-size image.


RapidSVN is "a cross-platform GUI front end for the Subversion revision system written in C++ using the wxWidgets framework." This is a standard standalone application with all features available through main menus and right-click menus. Here are the options available with a right-click:

Thumbnail, click for full-size image.
Figure 2. RapidSVN features. Click for full-size image.

Standard Command Line SVN Client

The command line SVN client is a command line utility that can perform all SVN commands.


Here are the Subversion commands I use most frequently with a comparison among each of the three SVN clients.


The status command provides information about the local repository relative to the server repository. It will show any modifications, additions, or deletions to a file or directory since the last commit.


This status command shows one file having been modified:

[jjones@cerberus cli_co]$ svn status
M      folder1/tttt.txt

RapidSVN shows the status of files and directories by way of color coding and overlaying images over the icons for files and directories. For example, changed files will be red, and new files not in the repository will have a blue question mark image overlying the folder/file icon. Here is an example of Rapid showing a modified file:

Thumbnail, click for full-size image.
Figure 3. RapidSVN showing a modified file. Click for full-size image.


Like RapidSVN, TortoiseSVN shows the status of files and directories by way of images overlaying the file and directory icons in Windows Explorer. Up-to-date files and directories have an image of a green circle with a white check mark in them. Modified files and directories have an image of a red circle with an exclamation point in them. Here is an example of Tortoise showing a modified file:

Thumbnail, click for full-size image.
Figure 4. TortoiseSVN showing a modified file. Click for full-size image.

It is less "work" to see the status from the GUI tools if you are only interested in the files in your current directory. All you have to do is look, with no typing and no clicking. If you are interested instead in the status of all files and directories under a specific directory, the GUI operations grow more complicated. The CLI client command is recursive by default, and as such, is perhaps more helpful in this regard. There is no way (at least that I have found) to see recursive statuses in RapidSVN. In Tortoise, you have to start a commit to show this information; more on that later.


The diff command shows what has changed (or the difference) between two versions of a file, most commonly between the current version being worked on and the version most recently committed to the repository.


Here is the CLI command and result for a diff between the current working version and the most recently checked in version of the file tttt.txt (diffing between the current working version and the most recently checked in version is the default):

[jjones@cerberus cli_co]$ svn diff folder1/tttt.txt
Index: folder1/tttt.txt
--- folder1/tttt.txt    (revision 3)
+++ folder1/tttt.txt    (working copy)
@@ -2,3 +2,4 @@

+test line 3
In order to perform a diff in RapidSVN, right-click on the file and select diff from the menu. As with the CLI, the default behavior is to diff the current working version against the most recently checked in version in the repository. One item of note is that you have to configure a diff utility manually. On the Linux laptop I am writing this article on, gvimdiff comes through in a pinch.
Again, as with RapidSVN, TortoiseSVN provides diff functionality with a right mouse click on the file to diff. As with both other clients, the default behavior is diffing the current working version against the most recently checked in version.

The ease of performing the default diff is, arguably, comparable among each of the three clients. However, when it comes to complicated diffs, such as between two versions in the repository, it is easier to do in one of the GUIs (and both are equally easy). All you have to do is select a file, view the GUI SVN log, select the versions to diff, and select diff. With the CLI, you have to view a log first to find the versions, then remember what the parameters are to diff two versions (-r <old>:<new>), remember the versions, then plug the two versions into the command line. It's not a tremendous hassle, but having the versions right in front of your face makes it a little easier.

GUI Principle #1

GUIs are superior when graphical representations add clarification. A good example of this is a standard GUI diff utility. While it is possible to figure out what has changed with a unified diff output, it is very helpful to have a split-framed diff utility (such as vimdiff or Tortoise's built-in diff) and see the old file and new file side by side with changes color coded.

GUI Principle #2

GUIs are superior when they make performing a specific task more obvious. An example of this among the SVNs is diffing between revisions of a file. In Tortoise, it is just a matter of looking at the log, selecting two log entries, and selecting "Compare Revisions." In the CLI, I had to do a svn help diff first before figuring out that the syntax I needed was svn diff -r <old version>:<new version>.


The log command displays commit messages for specific revisions of a file.


The command to show all log entries for all revisions of a particular file is as follows:

[jjones@cerberus folder1]$ svn log tttt.txt
r3 | (no author) | 2004-12-08 14:43:19 -0500 (Wed, 08 Dec 2004) | 1 line

test test test
r2 | (no author) | 2004-11-27 18:27:21 -0500 (Sat, 27 Nov 2004) | 1 line

had to move some stuff around.
r1 | (no author) | 2004-11-27 18:26:18 -0500 (Sat, 27 Nov 2004) | 1 line

This was another test.
The mouse right-click and Rapid "query" menus contain the log command. Rapid has a limitation in that it does not appear to show the verbose log output that includes all the other files that changed in that particular commit.
As with all its other major features, the mouse right-click menu in Windows Explorer contains the log command. Unlike Rapid, Tortoise provides the verbose log output when the user selects a revision.

It is comparatively simple to obtain the desired log messages in any of the three SVN clients (with the obvious missing functionality in Rapid). As with the diff command, it is easier to retrieve log information for previous revisions using GUI clients.


The commit command updates the SVN repository with changes made to a local repository.


The following command updates the remote repository with changes made to test_cli.txt and tttt.txt:

[jjones@cerberus cli_co]$ svn commit
Adding         folder1/test_cli.txt
Sending        folder1/tttt.txt
Transmitting file data ..
Committed revision 6.

CLI SVN test.
--This line, and those below, will be ignored--

A    folder1/test_cli.txt
M    folder1/tttt.txt
In order to commit changes from within RapidSVN, right-click on the desired file or directory and select commit. A window will appear requesting a log entry for this particular change.
Make a commit in Tortoise by right-clicking on a file or directory in Windows Explorer and selecting commit. Unlike the other two clients, Tortoise does not automatically assume that you wish to commit all files pending commit. (Selecting a directory to commit in any of the clients implies that you intend to commit changes made to all files under that directory.) A log message window appears in order to track changes made to the selected files. However, a checklist of changed files also appears, so that you can select (or de-select) individual files to commit. Further, double-clicking on a file in the checklist will diff the file and show the changes made since the last commit.

Committing files is equally simple among the three clients. However, Tortoise added some features that are really useful. It's really nice to be able to select a top-level directory, start a commit, and then hand pick the files you want to commit. It's also nice while trying to determine which files to commit to be able to diff them with a double-click. These features were well thought out and have helped me along the path of programmer virtuosity by making me just a bit lazier.

GUI Principle #3

GUIs are superior for executing an action against a subset of a list of items that requires a human brain for its creation. If you have a command, such as svn status, that will generate a list of items and need to commit some, but not all, of the files in the resultant list with a criteria that you cannot easily programmatically derived (such as "Oh, I was only fooling around with this file; it doesn't need to be committed," or "The changes in this file are for next build, not this build, so I'd better not commit them yet"), it is easier to have a list of items to select or deselect with a mouse click rather than, in this case, performing a commit one file at a time.

GUI Principle #4

GUIs are superior when you want to perform a limited number of functions on a list of items. An example is: "What do you want to do with a list of files in a potential commit operation?" The only things that I can think of are to diff the files with the latest repository version to see what changes have been made locally, and revert specific files back to the repository revision. Tortoise includes these options, as well as the ability to open the files. Doing a diff on a specific file is available (as mentioned in this article several times, because that is an awesome feature!) with a double-click on the file.


The update command synchronizes a local repository with the server repository.


In order to update the local repository to the current SVN version (using the CLI), issue a command like the following:

[jjones@cerberus svn]$ svn update cli_co/
At revision 3.
Updating a local repository (or a specific directory tree) in Rapid involves right-clicking on a file or directory and selecting "update." In the update dialog that immediately appears, an "update to specific version" option is available, as well as the ability to choose whether to perform a recursive update.
Updating in Tortoise involves right-clicking on a directory or file and selecting Update. No options are available in that menu. However, there is an Update to Revision function in the a TortoiseSVN menu, which should overcome that shortcoming.

The update command is comparable across these three clients.


The SVN add command adds a file, directory, list of files or directories, or a recursive directory tree to a local repository. The changes made to the local repository will not be made to the server repository until they are committed.


The following command adds the file test_cli.txt to the local repository:

[jjones@cerberus folder1]$ svn add test_cli.txt
A         test_cli.txt
Add a file to the local repository from Rapid by right-clicking on the file (or directory) and selecting "add."
Add a file to the local repository from Tortoise by right-clicking on the file (or directory) from Windows Explorer and selecting "add." Tortoise does have the extra bonus feature of providing a checklist to select which files to really add.

In all three clients, it is simple to add files and directories. The CLI does have the advantage that the full power of the shell is available.

CLI Principle #1

CLIs are superior when processing the result of something with another utility is helpful. For example, to add all .txt files recursively, do something like this:

for f in `find . -name "*.txt" -print`
    svn add "$f"


The move command relocates a file or directory in the repository. One of the benefits of a Subversion move as opposed to an attempt to perform the same thing in CVS is that Subversion maintains the revision history of the moved files. There are ways to maintain this history in CVS as well, but when I last looked into doing it (a year or so ago), it seemed painful.


The following command moves the file test_cli.txt up one directory level:

[jjones@cerberus folder1]$ svn mv test_cli.txt ../
A         ../test_cli.txt
D         test_cli.txt

Interestingly, the move command is equivalent to doing a copy followed by a delete.

Perform a move command in Rapid by right-clicking on a file or directory, selecting "move," and typing in the desired destination.
Move a file in Tortoise by right-dragging it to the desired destination and selecting "Move files in Subversion to here" from the resulting menu.

The two easiest options for moving files are the CLI and Tortoise. With the CLI, a good shell that supports tab completion makes it a snap to find the desired destination. With Tortoise, navigating to the desired destination is just a matter of expanding directory trees. Rapid, though, is just not terribly friendly in this regard. Maybe I've just grown lazy over the years, but having to type a full directory path to somewhere without the crutch of auto-completion is just a little more tedium than I care to needlessly inflict upon myself.

CLI Principle #2

CLIs are superior when they support time-saving features of the shell. Tab completion is an amazing time-saving feature of many modern shells. Some SVN commands (such as move) in Rapid can benefit from such features.


The delete function schedules a file or directory for removal from the repository. The actual removal will occur with the next commit. The history is still in the repository; the file or directory will just not be present and readily available in any subsequent repository versions.


Delete a file from the repository using the CLI like this:

[jjones@cerberus cli_co]$ svn rm test_cli.txt
D         test_cli.txt
Right-clicking a file in Rapid and selecting "delete" from the menu schedules the file for deletion from the server repository.
Right-clicking a file in Windows Explorer and selecting "delete" from the TortoiseSVN menu schedules the file for deletion from the server repository. Unlike some other operations in Tortoise (like add and commit), there is no prompting or verification with a checklist of which files to operate on.

All delete operations are simple and work similarly. All perform a recursive delete for any specified directories. They all schedule files and directories for removal pending the next commit. The CLI does have the advantage of allowing a scripted delete. See the add command for an example of scripting a SVN command.

Tortoise has another advantage in that it's possible to perform SVN operations from within a search results window. To remove all *.txt files from a directory structure using Tortoise, perform a search from Windows Explorer, wait for the files to appear in the list, select them, right-click, and select TortoiseSVN -> Delete. Tortoise has more advantages for a user not proficient with the find utility (and fewer advantages for a user more proficient with the find utility).


Checking out a repository copies a specific version (usually the latest version) of the files from the server repository to a local directory.


A CLI checkout of a very simple repository looks like this:

[jjones@cerberus svn]$ svn co http://<server>/<repository> cli_co
A  cli_co/folder1
A  cli_co/folder1/tttt.txt
Checked out revision 3.
Checking out a repository from RapidSVN involves selecting Repository -> Checkout from the RapidSVN client, filling out a couple of fields, and clicking OK.
Checking out a repository from TortoiseSVN involves right-clicking in a directory in Windows Explorer, clicking Checkout, filling out a couple of fields, and clicking OK.

The GUI clients may be more convenient to check out a repository from because the forms and fields offer a visual clue regarding what data to enter. Tortoise is especially helpful because it remembers previous values of the fields.

GUI Principle #5

GUIs are superior when fields and forms provide visual "clues" regarding input. The GUIs both provide fields to enter the repository location, the directory to put it in once it is checked out, and which revision to check out. This is a simple example and anyone who has checked out a project more than a couple of times with the CLI will have no problem remembering which parameters to put where. The principle, though, still stands. Sometimes having a form to fill out makes it easier to enter input.

CLI Principle #3

CLIs are superior when a large number of options are available in order to perform a single command. (This is a general principle and not really relevant specifically to checkout.) Sometimes in such a situation it is helpful to script the different options. If there are only a few options you ever use, just remember them. A GUI tool with tons of options can tend toward a cluttered GUI. Then again, a CLI tool with tons of options can tend toward a cluttered CLI, but scripting is definitely helpful in such a situation.


Overall, the CLI is a very functional tool. It can perform any SVN command. It needs no GUI display, which is a requirement for some folks. Its usefulness extends to include the full power of the shell being used. You can chain together find, grep, awk, and other commands with the SVN command line utility. However, two features of Tortoise that have grown on me are 1) file checklists and 2) diffs at commit time by double-clicking the file to be committed from the diff window.

RapidSVN has great potential. The idea and goal is that of a cross-platform GUI SVN client. Its usefulness at this point does not quite compare with Tortoise and, in some cases, not even with the CLI. Specifically, it lacks checklists for selecting which files to commit out of all that have changed, drag-and-drop copy and move operations, and diff at commit time with just a double-click. While there are some shortcomings with Rapid, there is absolutely no reason that it cannot have all the niceties that Tortoise has. I hope as time passes on, that it will.

TortoiseSVN is, overall, my favorite of the three. The biggest drawback is that it only works with Microsoft Windows. Tortoise mostly provides quick and easy access to the functions you need to perform (by integrating into Windows Explorer through the right-click menu). It also provides some courtesy functions to help facilitate your work (such as double-clicking on a file in the commit dialog to get a diff window). Anything that I have negative to say against Tortoise is petty (with the exception of platform limitations). For example, it would be nice to provide a recursive status function with diff functionality without having to begin a commit operation. Overall, it's a great tool.

Jeremy Jones is a software engineer who works for Predictix. His weapon of choice is Python.

Pragmatic Version Control Using Subversion

Related Reading

Pragmatic Version Control Using Subversion
By Mike Mason

Return to

Copyright © 2009 O'Reilly Media, Inc.