Monthly Archives: April 2008

Use svn:externals to integrate external libraries

As projects get more complex, I came to use Subversion’s externals. This SVN property enables you to use more than one ‘checkout’ inside your architecture. For example if you are using Zend Framework as an external library, why make a ‘hard’ copy of it? It gets out of date very quickly, right? Externals allows you and your co-workers to check out a working-copy of a particular revision of it (if you want) and maintain it as ‘external’. This means you can use ‘svn update’ not only on your code but also on Zend Framework or any other external libraries you are using in your project architecture. Precondition is, you have access to a Subversion repository that contains the libraries. Externals are very well explained at:

Here is a command-line example to setup and define an external:

Let’s say you would like to use the external library ‘external-lib’ in your project. Change dir to a directory, where you have your libraries and enter the following command:

  1. Create a new directory inside your working copy and change dir into that directory:
    /home/web/projectname/htdocs/libs$ mkdir external-lib;
    /home/web/projectname/htdocs/libs$ cd external-lib;
  2. Check out a working copy of the desired external library:
    /home/web/projectname/htdocs/libs/external-lib$ svn co .;
  3. Change dir back again and declare your checkout external:
    /home/web/projectname/htdocs/libs/external-lib$ cd ..;
    /home/web/projectname/htdocs/libs$ svn propset svn:externals “external-lib″ “external-lib”
  4. Commit your changes:
    /home/web/projectname/htdocs/libs$ svn commit -m “External for external-lib set.”

Now every time you update your working copy, updates are fetched from your external(s) too.

Podcast: Java Posse

Conversations about software development and the OO-world. Even if you did not yet dive deeper into Java (like me) you can learn a lot for your work with PHP5.

“The Java Posse is a group of four veteran Java software architects that know eachother well, love to talk about Java technology (and technology in general), and happen to have a bad habit of recording audio stuff and publishing it on the web.”

Synergy – Many Computers, one Keyboard

Some days ago I saw some colleagues using more than >2 computers with one keyboard and one mouse, dragging the mouse across multiple screens with different operating systems and using the clipboard accross them. Wow!

This is done with a tool named Synergy. Here is my setup with Windows XP and Mac OSX:

4 Screens, 2 Operating Systems connected via Synergy

I did the following to make it work:

  • I installed Synergy on my windows box (the 2 screens on the left) .
  • Started Synergy and started it as the ‘server’.
  • I configured the server with screens named like the IP-Addresses of the machines I wanted to use and defined which machine with its screens are on the left and which ones are on the right. This defines where the mouse cursor transfers to the next screen. I also used alias names for the screens.
  • Started Synergy on the server (Windows).
  • Then I downloaded Synergy for Mac OSX.
  • My MacBook is also attached to a 2nd Mac-screen (no. 3 in the picture). In this setup this one is optional. I had it lying around, so I used it.
  • The configuration has to be saved manually in the file synergy.conf. I used some aliases in order to avoid trouble.
  • Now I started the Synergy-client on the MacBook with “/Users/Shared/synergy-1.3.1/synergyc -f mmm” from the command line.
  • Problems with the connection are shown on the server and on the client and can easily be fixed with the documentation on the synergy website.

You will find all you need to know on

A good tutorial:

Agile Version Control Mechanism

I came across a nice paper explaining best practices in using version control (Subversion) in multiple agile team projects. The lack of concept, clarity and existence of understandable rules often leads to confusion in teams I work in.

Regular merging down from the stable mainline (catch-up) and merge and copy up (publish) of stable features from develoment branches.

Here are some of the rules I found useful:

  • Each branch (even the trunk) has an owner and a policy.
  • Agree on a common definition of Done = releasable (means Unit tested and integration tested).
  • Trunk is the Done branch, it should contain releasable code at any time.
  • Branch policy = Unit tested code, new releasable features or bugfixes.
  • Don’t combine different release cycles on a single branch.
  • Create additional branches as seldom as possible. Only create a new branch when you have something you want to check in, and there is no existing branch that you can use without violating its branch policy.
  • Whoever touches the trunk is responsible for ensuring that the whole trunk stays releasable – including all previous functionality.
  • Synchronize your code with the work branch continuously (daily).
  • Code conflicts and integration problems should be discovered as soon as possible.
  • Resolve conflicts on the branch that is least stable. Whoever checks in first wins.
  • Merge from your work branch to the trunk on a regular basis, for example whenever a story is done. Don’t wait until the end of the sprint.
  • Merge down, copy up.

Revision flow
Flow of changes around the mainline of your project.

Taken from the paper “Agile version control with multiple teams” of Henrik Kniber which you should read if you are not already an expert in branching and tagging across teams.