Working with Subversion, Part 1

Working with multiple client projects and keeping abreast of the industry through browsing and committing to open source and other people’s libraries means working with multiple source code control (SCC) systems.  One of the systems I use is Subversion (SVN).  It’s no longer one of the SCCs I use most often so I tend to come back to it after long pauses and my SVN fu is no longer what it used to be.  I’m sure my brain is damaged from this form of "task switching", not to mention the time I spend trying to figure out the less common actions I need to perform on a repository (repo).  I usually spend more than few minutes digging up the commands I need for the once-in-a-decade actions I need to perform. 

I don’t foresee getting away from SVN in the near future; so, I’d thought I’d aggregate some of these commands into one place.  My blog is the perfect place to do that (because it’s just for me, right? 🙂

Backing Up

Outside of adding/committing, the most common action to be performed is backing up the repository.  Unfortunately for my brain this is automated and I don’t see it for months at a time. To back up an SVN repository that you’re not hosting or being hosted by third-party software (like VisualSVN Server) then I like dump/load:

svnadmin dump repo-local-path > repo-bkp-path

This let’s you restore to the host that contains all the configuration data like permissions, users, and hooks.

If the repository is completely autonomous (i.e, just a directory on your hard drive and maybe an SVN daemon) then hotcopy is better:

svnadmin hotcopy local-path destination-path


If you used the dump method of backing up, you need to use the load command to put the backup into an existing repository.  If you’re not using a hosted repository, you’ll first need to create the repository (svn create repo-local-path) to run load (in which case I’d recommend using hotcopy instead).  To load the dump into the existing repository:

svnadmin load repo-local-path < repo-bkp-path

If you’ve used hotcopy then the backup is the fully functional repository; just make it available to users (i.e. put it where you want it :).


Migrating is basically just a backup and restore.  If you’re backing up one repository and putting into an existing repository, use dump/load.  On System A

svnadmin dump repo-local-path > repo-bkp-path

On System B after copying repo-bkp-path from System A

svnadmin load repo-local-path < repo-bkp-path

Even if you weren’t migrating to an existing repo, you could use this method; just add svnadmin create repo-local-path before svnadmin load.  The dump/load method has the added benefit of upgrading the data from one format to another if both systems don’t have the same version of SVN running.  The drawback of migrating with dump/load is that you’ll have to configure manually (or manually copy from the old repo) to get permissions, hooks, etc…

Now you’ve migrated your repo to another computer, existing working copies will be referencing the old URL.  To switch them to the new URL perform the following:

svn switch –relocate repo-remote-URL

Creating Working Copy

If you don’t already have a local copy of the repo to work with, the following command

svn checkout repo-remote-URL working-copy-path

Committing Changes

I added this section because I’ve become used to GIT.  GIT has a working directory and staging area model; so you tag files in the working directory for staging before committing.  This allows you to selectively commit modifications/additions.  SVN is different in that the working directory is the staging area so you effectively have to commit all modifications at once.  (you can stage adds because you manually tell SVN which files to start controlling).

svn status will tell you what’s modified (M) and what’s untracked (?).  To commit all modified

svn commit –m "description of changings included in the commit"

Undoing Add

Sometimes you a schedule something to add on commit by mistake or it’s easier to add by wildcard and remove the files that you don’t want to commit on your next commit.  To remove them from the next commit:

svn revert file-path

Be careful with revert because if the file is already controlled this will revert your local modifications.

Undoing Modifications

To revert the modifications you’ve made locally and restore a file to current revision in the repo:

svn revert file-path



What’s your favourite SVN workflow?

2 thoughts on “Working with Subversion, Part 1

  1. Very cool! I’ve just been doing backups by….uh…copy/pasting the directory over to a portal HD. Not the BEST way, but until now, haven’t known a better way. I’ll have to try the backup commands you suggested. Thanks.

    PS If you’re not using SVN most of the time, that begs the questions, what are you using most of the time? TFS? Git?

    If you’re using Git, is that something you can “host” or is that just hosted somwhere else? Or am I just not educated enough (and need more coffee?) :>

  2. Hi i have an recuirement….how to generate xl reports using tortisesvn i want create weekly changes in xl formate and i want create difference between two branches.these changes alo need to get xl foemate only any one helip meeeeeeeee pleaseee pleaseeeee

    send me to answer to:

    thanks in advance

Leave a Reply

Your email address will not be published. Required fields are marked *