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.
statusThe 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.txtRapidSVN 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.
diffThe 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 @@
4
+test line 3diff 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.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>.
logThe 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.
------------------------------------------------------------------------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.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.
commitThe 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.txtcommit. 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 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.
updateThe 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.The update command is comparable across these three clients.
addThe 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.txtIn 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"
donemoveThe 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.txtInterestingly, the move command is equivalent to doing a copy followed by a
delete.
move command 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
features.
deleteThe 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.txtAll 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.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.
|
Related Reading Pragmatic Version Control Using Subversion |
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.