Craig Strong

Over the past few months I have been switching between operating systems which have included, Cent OS, Fedora, Vista and Mac OS X. When switching through these operating systems I am very aware of cross compatibility when using OS dependent software. Other than the obvious differences which include such things as file systems, one thing I have been quite frustrated with is interacting with SVN whilst moving between these operating systems. Why this has been frustrating it’s because for each of the OS’s above there is dependent software such as Tortoise SVN on windows. This is a great SVN tool and really does make things easier. However this is a Windows SVN tool so I can’t use it on other OS’s. Although there are tools available on other OS’s, I don’t want to keep switching between OS specific software as it can be time consuming and takes you a step further away from the source/task.  

Why use the command line ?

As a result of the restrictions imposed when moving around different OS’s, I have reverted my svn interaction back to the beloved command line for most svn tasks. Now I know some of you reading this may see this as a step backward in the world of modern UI, but there are a few good reasons why I have made this decision:

1. With the exception of running putty on Windows to interact with my svn repository which sits on Linux, the command line makes you closer to being OS independent when it comes to svn.

 

2. Running svn commands on the command line is much quicker as it doesn’t have to go through the rendering process or additional layers of the OS or a series of extensive third party code. There is much less clutter, it’s just plain and simple (WYSIWYG).

 

3. I have had problems with the OS network cache, such as when ‘subclipse‘ or ‘Tortoise‘ tell you that you are working within a branch when you are actually on the trunk! As you can imagine, this can have problematic knock on effects and this is where the command line doesn’t lie. You don’t need to click refresh on your working copy directory to get the truth, you simple ask it once and it tells you there and then, no caching involved.

 

4. You don’t have to learn how to use each OS’s svn tool’s navigational menus and can therefore spend the time learning the commands plain and simple, saving you time in the long run.

 
Now I’m not saying that UI svn clients don’t have a value, the visual advantages can be extremely significant, especially when merging and looking at diff’s etc. You might find yourself going back now and again to use these tools for these advantages alone. The point is for general usage the command line has a significant value for me and for general svn interaction entering simple commands can be a time saver.

Everyday SVN Commands

Note: For the purpose of these commands I will express the path the repository as $REPO

_____________________

svn log -r 66:44

Shows the log history from revision 66 to revision 44 in reverse order

_____________________

svn log -r 81

Shows the log specifically for the chosen revision 81

_____________________

svn log $REPO/branch1234

Shows the log history for a specific branch

_____________________

svn log -vr 1234

Shows the modifications for a particular revision

_____________________

svn log –stop-on-copy | grep-i “update”

This will show the commit history up until it finds the phrase ‘update’ in the commit log

_____________________

svn list $REPO/branches/branch-123

lists the directories/files within the selected branch-123

_____________________

svn switch $REPO/branch/branch123/siteA

If you are in your working copy site directory, this command will switch your current location to the branch you require. For example if you are in my/working/copy/siteA which is checked out to the trunk, this command with switch you over to your selected branch. Note : You can also enter this command as “svn switch $REPO/branch/branch123/siteA /path/to/your/siteA”.

_____________________

svn mkdir $REPO/branches/branch333

Creates a new directory within the repository. Within my example I have created a new branch.

_____________________

svn cp $REPO/trunk/siteA $REPO/branches/branch456/siteA

Checks out the site ’siteA’ to a selected branch ‘branch456′.

_____________________

svn diff –summarize –old=$REPO/trunk/site –new = $REPO/branches/branch333/siteA

Shows the list of files that are different between the two versions selected.

_____________________

svn merge –dry-run -r123:200 $REPO/trunk/siteA

carries out a dry run of a merge between the head of branch ‘r123′ and the head of trunk ‘200′. (A merge can be between any two revision numbers)

_____________________

svn commit -m “A brief, but informative message here”

This will commit any changes to your trunk/branch accordingly and record a message in the commit log. Remember you will be reading these log messages often. If you are working within a team ask yourself if someone else looked at the commit log could they work out what your commit involved from your message. Although sometimes seen as a repetitive task entering messages, these are there for a reason. It might be good practice to employ a message standard within your workplace to keep messages consistent.

_____________________

svn info /path/to/site/in/workingcopy

This will output the information for the file/directory within your working copy. You can know exactly where your working and the current status from this. Example :

craig-strongs:~ craigstrong$ svn info ~craigstrong/working_copy/

Path: /Users/craigstrong/working_copy/

URL: svn+ssh://craig@repo/my/path

Repository Root: svn+ssh://craig@repo/my/path

Repository UUID: 12345-12345-12345-12345

Revision: 875533

Node Kind: directory

Schedule: normal

Last Changed Author: craig

Last Changed Rev: 875533

Last Changed Date: 2009-03-25 16:46:59 +0000 (Wed, 25 Mar 2009)

_____________________

svn status /path/to/working_copy

This will list the current status of your working copy. If you have switched any files/directories, you should be seeing these listed within the results back. Other information such as if you have any uncommitted files will also be listed here.

_____________________

I’ll restrict the list to the above for now as these are what I consider to be the most common commands that I use on a day to day basis. If I find myself often writing other such commands regularly I’ll add them to the above.  If you feel you would like to add to this list, please feel free to reply to this post.