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:
- 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.
- 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).
- 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.
- 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
For those who are interested and for an online resource I can frequent to compensate for my poor memory, I have listed a few of the common commands I use on a day to day basis below:
Note: For the purpose of these commands I will express the path the repository as $REPO
svn log –revision 55:90
Shows the log history from revision 55 to revision 99
_____________________
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.
