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:
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:
Figure 2. RapidSVN features. Click for full-size image.
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.
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:
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:
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.
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
[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 @@ 4 +test line 3
diffin RapidSVN, right-click on the file and select
difffrom the menu. As with the CLI, the default behavior is to
diffthe current working version against the most recently checked in version in the repository. One item of note is that you have to configure a
diffutility manually. On the Linux laptop I am writing this article on,
gvimdiffcomes through in a pinch.
difffunctionality 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
diff two versions (
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
diff) and see the old file and new file side by side with changes
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
svn diff -r <old version>:<new version>.
log command displays commit messages for specific revisions of a
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. ------------------------------------------------------------------------
logcommand. 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.
logcommand. 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
diff command, it is easier to retrieve log information for previous
revisions using GUI clients.
commit command updates the SVN repository with changes made to a local
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
commit. A window will appear requesting a log entry for this particular change.
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
diffthe 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
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
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
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.
update command synchronizes a local repository with the server
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.
update command is comparable across these three clients.
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
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
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` do svn add "$f" done
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
move command is equivalent to doing a copy followed by a
movecommand in Rapid by right-clicking on a file or directory, selecting "move," and typing in the desired destination.
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
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
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
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
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.
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
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
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
Overall, it's a great tool.
Jeremy Jones is a software engineer who works for Predictix. His weapon of choice is Python.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.