Git SVN Workflow

For some of our projects, FreeRTOS specifically, we need to track a SVN upstream repository that is hosted on Source Forge. As we’re only interested in pulling upstream changes and not pushing anything upstream, this simplifies our workflow a bit.

The first thing that is needed is to configure the upstream SVN repository. In our case, we already have an existing git repository. Therefore, instead of cloning the actual SVN tree, we’ll only pull in the necessary changes.

$ cd freertos-port.git
$ git svn init -s https://freertos.svn.sourceforge.net/svnroot/freertos

Fetching the entire SVN history would take ages. Therefore, we’re limiting the fetch to only the more recent releases (r1611 onwards). This operation will take a little time. Time to grab a coffee break.

$ git svn fetch -r 1611:HEAD

Next, we need to merge in the upstream code. We only work of stable upstream releases, which are tracked as specific SVN branches. This can be done by merging the remote branches directly.

$ git branch -a
$ git checkout develop
$ git merge remotes/tags/V7.0.2

Periodically, new code needs to be pulled from the upstream repository. This will only be done to track a new stable upstream release. This can be accomplished using the following method:

$ git svn fetch
$ git checkout develop
$ git branch -a
$ git merge remotes/tags/V7.1.0

Otherwise, we use git-flow as usual. Once things are done, push any changes up to github.

$ git push -u origin master
$ git push -u origin develop

Git Upstream Ports

We’ve recently added a number of git repositories at github to track ports of various software tools to our platform. These are the steps that we used to get things working. We will use the binutils port as an example.

Create
For consistency, we’ll name all our upstream code as upstream for obvious reasons.
Instead of tracking everything, it might be more beneficial to just track the upstream master branch as we only want to track the main development code.
To create the initial repository, these steps are used:

$ mkdir binutils-port.git
$ cd binutils-port.git
$ git flow init
$ git remote add upstream -t master git://sourceware.org/git/binutils.git
$ git remote add origin [email protected]:aeste/newlib-port.git
$ git push -u origin master
$ git push -u origin develop

Upstream
We would like to only work off stable releases.
Therefore, instead of merging the complete upstream branch, we’ll only merge in stable code tagged as official releases.
To fetch and merge stable upstream code, use these steps:

$ git fetch upstream
$ git fetch upstream --tags
$ git tag
$ git show-ref binutils-2_22
$ git checkout develop
$ git merge XXXXXXXX

Modifications
Use the standard git-flow model to make modifications to the code. To merge the code from future upstream stable releases:

$ git fetch upstream
$ git fetch upstream --tags
$ git tag
$ git show-ref binutils-X_XX
$ git checkout develop
$ git merge XXXXXXXX

Push
Once the code is ready it needs to be pushed up to github.
This should be done as and when necessary, particularly after major releases or hotfixes.
For this example, we’ll push up two public branches and a tag (12.02).

$ git push -u origin master
$ git push -u origin develop
$ git push origin 12.02

That’s it.

The Littlest Processor

I’ve always dubbed the AEMB as the littlest processor that could, after the famous book with an engine. To figure out just how little it is? It occupies less than 20% of the real-estate in the second smallest Spartan6LX9 FPGA.


Slice Logic Utilization:
Number of Slice Registers: 866 out of 11440 7%
Number of Slice LUTs: 1167 out of 5720 20%
Number used as Logic: 1035 out of 5720 18%
Number used as Memory: 132 out of 1440 9%
Number used as RAM: 132

Speed Grade: -3
Minimum period: 9.706ns (Maximum Frequency: 103.030MHz)

In a mid-range Spartan6LX45, it occupies an insignificant amount of on-chip real-estate. There is no doubt that this is the littlest processor that could.

Unattended Upgrades

We are managing a number of Debian servers in the office, for various internal applications. Initially, it was a simple matter of upgrading the servers manually. However, as the number of servers grew, the amount of repetitive apt-get upgrade commands that need to be entered became tedious.

Unattended-upgrades to the rescue!

Fortunately for Debian Squeeze, it is already packaged in the repository and installation is a simple matter of:

# apt-get install unattended-upgrades

However, what most guides do not tell you is that there is an additional step that is required to be done before it will automagically work. We need to configure apt to actually trigger the unattended upgrades. It is not triggered by default.

To do this, just issue a:

# dpkg-reconfigure unattended-upgrades

Answer yes when prompted whether to “Automatically download and install stable updates” as in the screen below:

That does it!

PS: To make it even friendlier, I have also configured each server to send an email to the system administrator whenever a system is updated.

Internships at AESTE

Listen to one of the interns here talk a little about his internship experience at AESTE.

  1. The work we do is HARD – but fruitful.
  2. The working culture here is different – in a good way.
  3. You get to meet other interesting people – who will enrich you.

An internship at AESTE is guaranteed to push you to discover strange new things about yourself.

Read what other interns learned through their experiences here.

Apply now!