A collection of changes to a repository is called a changeset. A changeset that has been placed in a repository is said to be committed. We can list changesets that have been committed. For example, if we would like to know what the last changeset that was committed to this part of the repository is, we would issue the following command:

$ svn log -r PREV:HEAD

The -r subversion switch allows us to specify revisions—numeric representations of each change. PREV and HEAD are special references, being the previous version and latest version, respectively. Sometimes, we might be instructed to test or use a specific version, called a revision. In that case, it is possible to retrieve it by issuing this command:

$ svn up -r 1234

Replace 1234 with the revision number you are told to use. This will update the whole checkout to that revision, and you should now rerun the commands discussed previously, repeating the same process used after just having checked out.

But sometimes, we might need to update only one or a few files to a specific revision—that can be done by specifying the path, like this:

$ svn up -r 1234 frontends/php/history.php

You can specify both of the directories and files, and get different revisions to test behavior changes or find the specific change that introduced a problem for you.

So you have tried out a development version—maybe several revisions. Some time later, you decide to find out what changes have been made to the trunk. First, you need to determine the current revision. While in the checkout directory, run the following command:

$ svn info

Look for the line that looks like this:

Revision: 60013

With that number in hand, it's now time to update the local copy to the latest and greatest. From the local copy directory, run the following:

$ svn up

This will proceed to update everything that has changed, compared to whatever copy you have. As only changes are pulled, this will result in much less data being downloaded, compared to downloading daily snapshots over and over again. Now, you can proceed with building Zabbix as discussed before, or you can choose to view the exact changes developers have committed:

$ svn log -r 60000:HEAD

This command will display the exact changes pushed to the code repository, along with any comments that the developers decided to add. This can be used to determine what exactly was changed. But all this was about the forward-looking development version, that is, the trunk—what if you want to see a particular bug fix for some problem in the stable version applied to that particular branch? Just as we grabbed the trunk from the code repository, we can also grab the branch:

$ svn checkout svn://svn.zabbix.com/branches/3.0

Instead of the trunk, we are now specifying the subsection branches. After that comes the specific branch, which can be any valid branch. What branches are there? We can list them:

svn ls svn://svn.zabbix.com/branches

While installing a branch version is pretty much the same as installing the trunk, there's one more use case with branches. If a particular bug is fixed in the branch and you want to benefit from that before the next stable version is out, it is possible to apply this single change to the installed copy. To do that, though, the change has to be first extracted in a format that is easy to reuse. Here, another command comes to the rescue. Remember svn log, which we used to look at changesets before? It showed the revision number for each changeset. If we now have this number, we can take a look at what files a particular commit modified:

$ svn log -v -c 60013

Here, we use the -c switch to specify a single changeset, and -v to increase the verbosity level. In the changed paths section, one or more files will be listed, for example:

M /trunk/ChangeLog
M /trunk/src/zabbix_server/escalator/escalator.c

When creating a patch, we might want to omit files that don't affect actual software behavior—the changelog in this case. Creating a patch would be done as follows:

$ svn diff -c 60013 src/zabbix_server/escalator/
 escalator.c > /tmp/zabbix.patch

Notice how we used subversion's diff subcommand, specified a single file, and redirected the output to a file. Now, the patch should be applied to our Zabbix installation. To do this, change to the Zabbix source installation directory, and execute the following:

$ patch -p 0 -i /tmp/zabbix.patch

The patch utility is instructed to use the zabbix.patch input file, and use the full path information as specified to apply the changes. After patching, we should evaluate areas the patch applies to—if it's the server, we should recompile and reinstall our server binary, the same with the agent daemon. If changes were performed on the frontend only, we'll usually want to apply the patch to the installed frontend directly, by changing to the frontend directory and applying it as root with the following command:

# patch -p 2 -i /tmp/zabbix.patch

Note that in this case, we are instructing the patch utility to strip the first two directories from the path inside the patch. When we are patching the frontend, no recompilation is necessary, and all changes will be visible immediately. What if we applied a patch but it only made things worse? Thankfully, that is easy to undo by applying the same patch in reverse:

# patch -R -p 2 -i /tmp/zabbix.patch

If using this command for the frontend, again, no further action is required. If it affects binaries, we have to recompile them.