A Great Musician has left us – Small Tribute to John Barry

 Music  Comments Off on A Great Musician has left us – Small Tribute to John Barry
Mar 092011

On January, the 30th 2011 the composer John Barry died at the age of 76 years.

As great fan of his music and as a tribute to his works I present here an article I found many years ago in Film Score Monthly (#74, October 1996):

The 1996 Cinemusic Award was presented to John Barry by his old chum, Michael Cain. The following is Mr. Cain’s brief but touching speech at the second cinemusic Award Gala Night held on 9 March 1996. Mr. Cain flew to Gstaad direct from a four month shoot in Miami just for this event:

If you’re a lucky actor, you make your first film. And if you’re very, very lucky, you get great composer to write it. I was very lucky. I made a film called Zulu, and the music was brilliant and helped to make the film a success.

If you’re a slightly older actor, and you ‘re very, very, very lucky, you get to star in a movie. And if you’re very lucky, you get a great composer, which was John Barry, and the film was The Ipcress File, and when suddenly things don’t go right, and you have nowhere to live, he puts you up in his flat for eight weeks. And that’s John Barry.

Kooking back on it, the thought of having me as a house guest for eight weeks must have been an absolute nightmare. But for me, the first night was a nightmare. I’d just gone to bed. We’d been out to dinner, John and I and whoever – we were single at the time, both of us – I’d just gone to bed, and the piano started. It was one o’clock in the morning, and the piano kept on all night, and it just kept going, and I thought “To hell with this! I’ve got to find somewhere else to live.” You know, you hear about these musical geniuses who sit up all night writing, and that’s how John was.

At seven o’clock in the morning, I staggered out. I couldn’t sleep, so I decided to get up. And just sitting there, sweat pouring off him, much thinner than he is now, he [John] really reminded me of Franz Liszt. I said to him, “What the hell were you doing all night?” And he said, “I’ve written this song.” And I said, “What’s it called?” And he said “Goldfinger.” And so I was the first person ever in the world to hear “Goldfinger,” and ever to see how John Barry works.

Once, I went to a rough cut of a Bond film, without the music on it, and I sat there. It’s a unique experience to see a Bond film without any music. And at the end of the film, I sat there and thought, “That’s the end of the series. It stinks. It’ useless.” And I hadn’t even realized there was no music in it – I just watched it. And then, of course, John puts the music on, and it works. If you could ever see some of those great movies that you’ve seen without music on them, you’d think to yourself, “How the hell does anybody ever think they’d be a success? It’s rubbish.” I’m not saying that Bonds are rubbish; they’re quite well-made films.What I’m trying to say is that the importance of music on a film is quite extraordinary.

Think back on all the hit movies that you can think of. Practically every single one will have some song or a piece of music associated with it. I just want to point out the importance of the film composer. When I finish a film, the last thing I say to the director with my dying breath at the end of the picture party is, “And who is going to write the music?” And if he’ll say “My sister-in-law,” I know we’re dead.

The importance of music, especially to someone like me, who has no real musical talent whatsoever. But I adore music, and I adore film music, and the importance of music in films – and the importance of this festival – which is concentrated on this really important side as film music, is really incredible.

The reason I’m here not just because I’m great friends with John Barry, which of course I am, and have been for a long, long period of time… It’s because I think that John Barry is one of the greatest movie composers in the history of the movies. I just got off a plane from Miami… I wasn’t about to arrive here and give an award to someone who I didn’t think was great, I’ll tell you that!

The problem with John is that John is very retiring, very quiet, very shy. He’s not a gib man, and so when you see him, he doesn’t sort of look great, so if’re not very careful, you may miss the fact that you’re in the presence of a probable genius, and I don’t want you to do that, because I’m going to invite him up here not to take this award. This is probably the first time in the history of awards that the award is heavier that the person receiving it.

Ladies and gentlemen, don’t be fooled, this is a great, great man – John Barry.

How we Came to Hudson/Jenkins CI as Continuous Build System

 Development Process  Comments Off on How we Came to Hudson/Jenkins CI as Continuous Build System
Mar 082011

During our phase to installing the SCRUM develop I read the book “Scrum – Agiles Projektmanagement erfolgreich einsetzen by Roman Picher” and there was recommended to use a Continuous Integration (CI) system. The reasons stated there persuaded me at once that we need such a system. So I started to looking for such a thing.

The very first system I set up was CruiseControl, because an other department in the company already used CruiseControl .Net. The setup of the server was pretty easy. But I did not like the way of configuring the jobs. Too many settings had to be done in an “XML grave”.

So I took a look onto the commercial Cruise by Thoughtworks. The setup was easy and support by the help desk was great during our evaluation phase. But still it was necessary to configure the job details with XML files. It may be that this has changed with a later revision.

I think XML is a good way of defining settings or transferring data – for machines. But I don’t think for humans.

I liked very much the pipeline concept that Cruise has implemented! But I did not had at that a budget of about 7000€ for buying such a license. So I found a great comparison list.

Only one system which offered all features that I would like to have: Hudson CI. The installation was as easy as it was for all the other systems. But there was no need to configure anything within an XML file. Everything could be set via a web interface. Great! Everything was translated to German. Wow. (Even I prefer today the English layout, because this eases the possibility to search for solutions of problems in the net.)

Continue reading »

Mar 062011


At the very beginning I should start with some background information: I am working in a small software company in a team with 13 developers. We continuously developing a software for the medical domain with Qt as UI framework and Visual C++. Our platform is MS Windows. Until autumn 2009 we were developing with the V-model.

As the requirement and priorities of our customer changed many times, we decided to change from the V-model to SCRUM. At the same time we changed from developing all features on the trunk of our SVN repository to feature branching.

As it is recommended in the literature we updated all the feature branches every day and merged the features back, after a story was done. And here the pain stared. SVN is a great SCM repository software, but it is not made for regular merging. So we started to look for alternatives. We put an eye on Git, Hg, Bitkeeper and Perforce. With four colleagues we made a list of requirements, use cases and started an evaluation phase for several weeks. At the end  Git and Hg were the most preferred ones. During this time I looked in the net and searched for pros and contras for both of them. From all the blogs, articles and our own experience i came to the conclusion that Git and Hg offer nearly the same functionality. At the end we decided to go for Hg because of the better support with TortoiseHg, the Windows Explorer integration and the less confusion interface.

In the next chapter I try to describe our way to convert the SVN repository.

SVN Preparation

Our source repository had at that time about 90.000 revisions and its size was about 7GB and the source code had about 500,000 lines of code.

It is recommended in the Mercurial book that one should start the migration from a repository clone. I strongly can recommend to follow that way. As I am more used to Windows I started to to create the mirror within Windows XP. But Subversion does not work stable under Windows XP. The socket layer crashed several time during the cloning process and I had to reboot the system. So I tried to perform the process on a Windows Server 2003 installation. The creation of the mirror was now going well, but later the needed SVN-Dump did not went through. So I installed an Ubuntu in a virtual machine and re-did the complete process.

So if not available in the Linux installation, install svn with

sudo apt-get install subversion

Now create an empty repository

 cd {where ever one want to create the mirror}
 svnadmin create svn-mirror
 echo '#!/bin/sh' > svn-mirror/hooks/pre-revprop-change
 chmod +x svn-mirror/hooks/pre-revprop-change

Now initialize the mirror. Be aware if one does not restrict the path to a certain repository path, one gets the complete repository. The repository had about a size of 60GB. So it would need time and space to set this up.

 svnsync init file://`pwd`/svn-mirror https://{svn url} --source-username {svn user name}

The first time one is asked to accept the certificate and one has of course to enter ones password. Use the correct apostrophe! So not a ‘, but a `!

Now we initiate the sync.

 svnsync sync file://`pwd`/svn-mirror --source-username {svn user name}

This command can be repeated as often as one like. It always checks then the source repository for updates and appends them. The history and its version numbers are preserved. It is not known if copy from or copy to from outside of the given path are used in the repository.

Migration from Subversion to Mercurial

During the last years we had stored many binary files in the repository which caused the repository to grow to a size of about 7GB. So I decided that we transfer the complete file history of the last three major releases  into Hg and filter with svndump all not needed binaries from the repository. So we wanted to be able to build all versions since the last major release.

The following assumptions are made:

  • The Subversion mirror repository is here /data/svn-mirror
  • The location for the new Mercurial repository is /data/hg

Patching Hg conversion module

The Subversion conversion tool must be patched because of deficiencies inside the code. Be aware as soon one updates the Subversion packages one has to re-apply the changes! The files is under /usr/share/pyshared/hgext/convert/subversion.py

Line 353
This line must contain all branches that shall be converted. All others are excluded.
Lines 354-363
These lines must be indended by 3 spaces.
Lines 366-368
These lines must be commented, otherwise the conversion will abort.

Execute the actual conversion command in a shell:

 hg convert --debug --verbose --filemap /data/svn2hg.txt --branchmap /data/branchmap.txt \
   --splicemap /data/splicemap.txt --datesort --config convert.svn.trunk={trunk path}  \
   --config convert.svn.branches={branch path} --config convert.svn.startrev={start revision} \
   --authors /data/user.txt file:///data/svn-mirror/ /data/hg | tee convert.log

Here is the description of the command in detail:

This file contains all paths which shall be excluded during the conversion, because they contains either binary files or branches, etc. that are not needed any more.
This file helps to rename branches to different, better names.
This file contains a description of additional parent and child connections. (Currently not working correctly, or I was not able to get it work)
{start revision}
This is the first revision that is taken from the Subversion repository.
A file that contains a mapping from the Subversion user names to real names that are used in Hg.


Now it is strongly recommended to do a binary comparison of the head of the Mercurial repository against the latest revision of the Subversion repository to ensure that no conversion errors happened. Be aware that the DVCS do not support empty directories and the DVCS does not support file property makros as Subversion.


We did a training over several sessions for all users about the differences between SVN and Hg before we used it in production. Then we made a cut from using SVN and started using Hg between two SCRUM sprints and no major issues came up after that. Only once we had the problem that one user used the merging functionality as it is in SVN. So he just wanted to pick a single change set and transfer it to a different branch. So at the end it was a training issue. Today everybody is really satisfied with Hg.

In the next article I will described why we use Hudson / Jenkins as build system and how we get there.

At the end I want to apologize, English is not my first language and this is my very first blog. So any kind of critics or advices to improve is welcome.