The 8 most useful SVN commands

I love the command line, and it is my primary interface for version control. When using Subversion, I appreciate the advantages of TortoiseSVN and Subclipse, and I use them on particular occasions. But the speed and precision offered at the CLI are too much of an advantage for any SVN user to ignore.

Some of you are snickering already. “Subversion? It’s almost 2012, past time to move to Git or Mercurial.” Sure, and we’ve all left Java behind, and spend our days coding in Clojure or Scala. The fact is that if you don’t work at a startup, you are unlikely to actually use a DVCS at work, so Subversion is still relevant to more developers than any other version control system, and will be for the next five years, regardless of how you feel about that.

If you are one of those that uses Subversion, read on, and I’ll detail the commands that you should know and use regularly.

Basic workflow

The following commands are your bread and butter:

$ svn up[date] Updates working copy from repository.
$ svn st[atus] Shows how working copy differs from last update (large view).
$ svn di[ff] Shows how working copy differs from last update (line-by-line).
$ svn add [path] Adds new files/directories to SVN.
$ svn c[omm]i[t] Checks in changes.

I find all of these faster the the various clicks involved in the IDE or GUI SVN client. Note that all of these can take a file or directory name as an argument. For commits, I typically type:

$ svn ci -m 'Commit message here'

to avoid the context switch involved with a text editor opening. If you currently aren’t using the command-line client, start with these commands, as they will handle 80% of your interactions with SVN.

Less commonly used commands

Of course, we make mistakes, and sometimes we want to return a file or files to a pristine working copy. So the next command you need to learn is:

$ svn revert [file or path]

You’ll be glad to know that revert only works when a file or path is explicitly given, so you can’t inadvertently wipe out half a days work by hitting enter before typing the file name. But whatever you do revert is gone forever, as it was never in the repository. In particular, revert cannot return your code to the state of that precedes the most recent update or checkout.

It often happens that you want to understand how your source code has changed in the larger picture, not just since the last update. In this case log and (again) diff are useful.

log gives the list of commit numbers along with the commit messages. Handy enough, but things can scroll past you pretty quickly if your project has any real history. My preferred way of examining the history is:

$ svn log -l 10 [file]

which displays the most recent 10 log log messages for the given file or path, and for the current directory if none is specified. Once you have located where the changes that you are interested in, diff can be used to determine the code differences:

$ svn diff -r 578 [file]
$ svn diff -r 578:592 [file] [--summarize]

The --summarize flag only displays the high level changes — files added, deleted, modified — which is often what you want first, since a full diff over a number of revisions and multiple files can be a lot of data.

Even more infrequent commands

There are other commands that are useful, when creating branches, merging, or returning to an older version of the code. I might write another post about these later. In the meantime, don’t forget:

$ svn help [item]

which explains the command given. And if you don’t know what command you are looking for, there is always the book, which explains everything anyone needs. But don’t dig too deeply in the book first, maybe your GUI client or IDE can accomplish what you want with a right-click and selecting “create tag” from a menu.

The reason for using the command line for these infrequent commands is different from the reason for using $ svn up. With infrequent commands, I’m driven to the command line not for speed and efficiency, but for precise control. If you find that you are unable to understand with certainty what sort of merging options your GUI client gives you, for example, you may want to do that merge from the command line, so you can know exactly what you are doing.

I hope some of this is helpful to others. Let me know what I missed.