The command line is your friend

Ok, so some friends can be awkward at times but really the svn command line is the best only way to get to know this tool properly. Having said that, there are some tasks where a good desktop client is the only choice but I'll get onto that in a later post and hopefully I can also add some reviews of some clients...
For now, though, you need to get comfy with the lovely command line and all its speedy, powerful greatness.
On Mac OSX and many Linux distros it's installed by default. Windows users need to install it so you'll nee to sort that out before continuing.
So let's get started with a very simple workflow in svn: checkout, edit, review & commit.

Checkout

So let's assume there is a repository somewhere and you need to get hold of the code in order to work on it. You can use the svn checkout (or svn co for short) command:

svn co svn://my.svn.host/my-repository/trunk

Let's break it down: the first bit is the svn command itself (duh!). You can type svn --help to see a list of the subcommands and svn --help checkout to see some help text on the checkout command itself.
The next bit is the subcommand co which is short for checkout. We're asking svn to check something out. After this comes the svn repository URL. This specifies the server, svn repository and folder that we want to checkout. In this case the server is my.svn.host, the repository is my-repository and the folder we want to check out is called trunk.

Top tip!: I find that if I'm working on the same repository for any length of time that it saves time and effort to put the first part of the svn URL into an environment variable so that the above command is shortened to something like svn co $SVN_MYREPO/trunk

When you run it you should see something like this:

A    trunk/a.py

A    trunk/b.py

A    trunk/release/fabfile.py

A    trunk/release/org.sh 

Checked out revision 7788.  

What we're seeing is a list of files that have been downloaded from the remote repository and which are now ready to be worked on.
So far so good: now you can work on your source code locally...

Review

Now that you've worked on the code a bit, tested it (you do write unit tests don't you?) it's time to have a look to see what's changed (assuming you're in the trunk directory you checked out above):

svn st

This is  the svn status command (svn st for short) which should list info about any modified files:

M    trunk/b.py

The above output tells us that one of our files has been modified (yes, "M" stands for modified, well done you for paying attention). The status command doesn't list any files that are not modified.
Let's have a look now at what the actual change is. For this we use the svn diff command:

svn di

This shows the actual lines of code that were changed in our modified file in unified diff format. It's worth getting to know this format so that you can make sense of your diffs. My diff output looks like this:

Index: b.py

===================================================================

--- b.py (revision 7788)

+++ b.py (working copy)

@@ -1,4 +1,6 @@

 #!/usr/local/bin/python

+import c

+import d

 import atools

 import commands

 import os

This tells me that my only change was to add the two lines import c and import d. I'm happy with the change and now it's time to commit, but wait let's do a couple more checks before we finish:

svn info

If we many branches in the repository it's good practice to double-check that our working copy is for the branch we think it is. There's nothing worse than that feeling when you've just realised you've just committed to the wrong branch! . The svn info command lists the repository name and URL along with some other useful info. You'll get something like this:

Path: .

URL: svn://my.svn.host/my-repository/trunk

Repository Root: svn://my.svn.host/my-repository

Repository UUID: d705dabd-a861-4a22-88ae-3ffc5f551a70

Revision: 7788

Node Kind: directory

Schedule: normal

Last Changed Author: growler.man

Last Changed Rev: 7764

Last Changed Date: 2014-09-25 15:17:27 +0100 (Thu, 25 Sep 2014)

Looking at the above output of svn info I can see that my working copy is still the trunk branch and I haven't switched to another branch since checking it out.
One last thing to do is to do an svn up which goes and fetches the latest changes from the repository and applies them to our working copy. If your working copy is out of date then the svn commit command will fail since your working copy is out of date.
Top tip!: It's actually good practice to do svn up at regular intervals throughout your cycle to make sure you're up to date with other developers changes in the repository. Inexperienced svn users are often reluctant to do svn up early on since they think it'll mess up their local changes but in practice it rarely does and actually you want to see conflicts sooner rather than later since they're always easier to resolve early on rather than allow them to grow into un-resolveable messes.

Commit

Yay, so we've checked out a working copy, made our code changes, reviewed them to make sure that everything is ok and made sure everything is up to date. All we need to do now is svn commit which sends our changes to the repository and creates a new revision number.

svn commit -m "Fixed the import error logged in ticket BPE-2677"

The -m flag is used to specify the log message which will be stored against your revision for posterity. You can omit the -m and message which should have the effect of opening up a text editor (if it doesn't then you might need to set the SVN_EDITOR environment variable to point to an editor e.g. export SVN_EDITOR=nano) where you can enter your log message.
Top tip!:  Please be a good citizen and enter something meaningful in the log message. You will be grateful for it one day.
Saving and closing the file in the editor will cause the change to be uploaded and committed to the repository.
Time now to congratulate yourself on a good day's work done well and to reflect on your budding relationship with svn on the command line. It's going to be beautiful...!

Subversion is here to stay

So the cool kids are all using git? When did that happen? Pah, I would be willing to bet that most of them don't even know why they're using it other than it seems that everyone else is using it these days.
Don't get me wrong, I think distributed version control systems are good for all sorts of reasons, but this blog is about the centralised version control system called subversion (svn for short) that is still used by an awful lot of development teams and which, in the right hands, provides an extremely powerful and feature-rich toolset for all of your versioning needs.
Over the last 10 years or so I have used svn in my day-to-day work on an almost daily basis and so I'd like to pass on some of the stuff I've learnt along the way. I've used it in a very wide range of scenarios, all the way from the very simple use cases of a single branch with a few files in a small repository to scenarios involving multiple branches and merging in humungous repositories with many developers working on different branches simultaneously.

In this blog I'll start off with walking through a few simple scenarios and hopefully build up a library of usefulness for the svn user looking for help. Who know where it'll go. Be patient and thankyou for joining me on the journey...