Working with Logs in SVN

In the last articles, we moved past the theory a bit and saw real operations in SVN. So far, we know about operating SVN and a few of the basic terms—branch, commit, merge, and of course our favorites: conflict and resolution.

In this article, we’ll do a little theory and a little practical work as well, and focus on one of the main reasons that version control exists—the ability to go from version to version and run test on the changes between the versions. Let’s see just how we do this. The first thing we need to look at is the log. The log shows us the changes made to our version. We find the log using the command svn log which we run in the parent directory of the project. The output looks like this:

$ svn log
------------------------------------------------------------------------
r7 | ran | 2015-10-10 21:28:48 +0300 (ב', 12 אוק 2015) | 2 lines

Making it decisive 

------------------------------------------------------------------------
r2 | ran | 2015-10-10 20:33:16 +0300 (ש', 10 אוק 2015) | 4 lines

Adding echo

M    trunk/index.php

------------------------------------------------------------------------
r1 | ran | 2015-10-10 20:13:17 +0300 (ו', 9 אוק 2015) | 5 lines

Initial

A    trunk
A    trunk/index.php

------------------------------------------------------------------------

We can see here the recent commits to the project and the various files. For instance, we see that on Oct. 19th I changed index.php. My comment was “Adding echo.” Notice that each commit has a serial number—r1 or r7 for example. If there was a merge, SVN considers the merge a commit that is no different than any other commit. For example, r7 is a merge of two branches but we don’t see that in the log. At least, not in SVN.

The last version is r7, in this case the version begin represented. So this is pretty cool and we can see all the recent commits. But what about comparisons?

The basic comparison is done using the diff command. If I want to see what the changes are between the latest version saved in version control and my local version—the version on my computer that hasn’t been pushed to version control yet—I run this command:

svn diff 

I get something like this in return:

$ svn diff 
Index: index.php
===================================================================
--- index.php (revision 11)
+++ index.php (working copy)
@@ -1,6 +1,6 @@
<?php

//Printing Hello World!
-print "Hello World :)";
+print "Hello World :O";

This can look confusing and a bit scary, but if we look a bit closer it’s actually pretty readable. We get a list of the files to which changes were made—in our case index.php. What’s next to the @@ are the lines in which there are differences. In our case, lines 1 - 6 in both files.

At the beginning of the diff it shows a few lines that don’t have changes, this is the <?php and the comments. Next to the minus, it shows the line that was erased (hello world with a smiley). This line is one that is found in the latest version in the version control but not in the local version. Next to the plus sign, it shows lines in the local version that are not found in the version control (the surprised smiley).

All we learned from this diff is that I switched the simley. That’s it!

I could do a check-in to the code on my local machine and push it to version control as the latest version. If I do, two things will happen. The first is that in svn log I’ll see the check-in. The second is if I run svn diff, I won’t get any results since there wouldn’t be any difference between the two versions.

I can also do revert, which will erase all the changes in the local version and go back to the version that is in version control. Running revert is easy. We just need to use the name of the file:

svn revert index.php

This operation erases the changes made to index.php and compares the local file to the latest version of the file in the source control. If there are more than one file, we can do revert to everything:

svn revert -R .

This revert to everything is called revert head. When we say ‘revert head’ we mean a return to the latest version.

In the same way that we run diff on the local version and the latest version saved in SVN, we can also run diff on the local version and a previously saved version in SVN. We identify the version according to its serial number found in the log. We see above r1, r2, and r7.

This is how we can run a comparison between the local version and r1:

svn diff --revision r1

We can also compare r1 and r2:

svn diff --revision r1:r2

You get the same type of output that we got from running the diff above.

In order to return to a specific version, r1 for example, we run the following:

svn update -r r1

And to return to the current version saved in version control, we can use this command:

svn update

We’ve seen this command before. This is the update command used at any time to pull the changes from the version control to our local version. It’s standard practice to run this before we run commit as to not copy of over other programmers’ changes.

We learned a few important things here:

Log - A list of changes made in the version control—every commit and merge.

Version number - each change in a version, be it one or many, is recorded with a version number.

Diff - the command we use to see the differences between versions. This can be between the local version and any version saved in SVN (the latest or an older one) or between two saved versions on the server identified by their version number. We find the version number with log.

Revert - a command run on the local version that returns it to a certain point before changes were made. We can change a single file to the latest version in version control, or an older version according to its serial number.

We can see that SVN gives us powerful tools to use with internet sites or software. If we messed something up by accident and discovered it at a later time, we can return to a previous working version (even if it’s not the latest version), verify that it’s working, and see which changes caused the bug. This is an aspect of version control that is useful even if you are working alone on a project.

In the next article, we’ll learn about additional tools in SVN.

About the author: Ran Bar-Zik is an experienced web developer whose personal blog, Internet Israel, features articles and guides on Node.js, MongoDB, Git, SASS, jQuery, HTML 5, MySQL, and more. Translation of the original article by Aaron Raizen.