Intro to Version Control with SVN

Apache Subversion (SVN) is version control software that’s been around a long time and is still in wide use today. It became standard in the world of programming, though today more people use Git. But in order to make effective use of or learn Git, it’s very helpful to get to know SVN first—and not just on a basic level. This series on SVN is meant to serve as a precursor to a series to come on Git.

SVN is first and foremost a version control system. But what is a version control system anyway? Today it’s a standard part of software development, but I’ll give a brief explanation. Version control grants us flexibility when coding through the entire lifetime of the software. You could say it supports writing code. For example, let’s say I’m writing some program in PHP that prints… oh, let’s say ‘Hello World.’

$var = 'Hello World';
print $var;

I’ll put this file into the version control. The version control will remember it and the code inside. Let’s say there is a change to the software specs and now they want an exclamation point at the end:

$var = 'Hello World!';
print $var;

I’ll put the change inside the version control as well, and it will then remember both versions of the program: the previous version and the current one. What do we need this for? Imagine the change was no good and we need to revert to the previous version—how could we do it? In this little example, I could just hit Ctrl+Z, but what if the program was even slightly more complex? Or if a little time past between the versions? Or what if another programmer made the change and they messed up part of the program?

This is exactly why we have version control which allows us to move between versions and see the differences between them. When I put some code in a new version, the entire development team can examine whatever changes I’ve made and make sure everything was done correctly and according to the specs.

Here’s a chart of the basic use of SVN:

^{Commits of one version in SVN}

In this diagram we can see our program—each arrow represents the change of one single programmer. This is version control as simple as it gets. Version A turns into version B, which turns into version C.

But we can add real versions. In SVN the main version is called the trunk. Let’s say I want to add a develop version that has a feature that’s still in development. What I’ll do is split the trunk, making a new version that becomes the main version of a new branch—a new version called develop. I carry out the changes in the new branch, all while I or any other developer can still make changes to the trunk. In the develop branch I put my new code, and each new change goes into the version control. When I’m done, I’ll merge the develop version with the truck. Here’s how it looks:

^{An example with two branches in SVN. A split, changes to both branches, then merge}

That’s nice and simple in a theoretical world and it’s well accepted that software has a main version for distribution to customers, or in the case of a webpage, the one on the server.

So now we have a few terms:

Branch - the name of a version. We always have the main version of the software. In the case of SVN, it has the traditional name of trunk, but it could be called anything. We can add a new branch to our version at any time. For instance, you could have a stable, working version, and you can easily make a new branch for a new feature. This would be a copy of the main version at the point you make the new branch. Now they are two separate versions and you can put separate code in each one.

Merge - the process of combining versions when you’re finished working on one branch and you want to add its code to the main version. For example, after I made the new develop branch, I worked inside of it and developed a new feature. If I want the feature in the main version, I’ll combine the code of the develop branch with the trunk. This process is called merge.

Commit - when you update code, you can check it locally. If you decide that it’s ready, you can add it to the version control. Every time you type some code into the version control, this is called commit. So you can continue to add code through commits to a new branch before you merge it with the truck.

The basic process of SVN works like this: I make the main version called the trunk. Then I make the develop version, add some code into it with a few commits, and then when I’m satisfied with the results, I merge the develop branch with the trunk and distribute it to the customer, or upload it to the server. Then everyone is happy, right?

Yeah, not really but we’ll get to that in the next article where we’ll talk about conflicts.

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.