Monday, March 21, 2011

Using git for revision control

As a hardware engineer, I spent most of my career designing chips using CVS for version control. It was free, simple, and workarounds for its more obvious warts were well-understood. It left me with a few side-effects, such as a pathological fear of branching, but was otherwise OK.

A couple years ago, I decided to try "git", the revision control tool used by the Linux kernel development team, and see if it had any benefits over CVS. Two years down the road, I don't think anyone on my design team would switch back if they had a choice. Fear of branching has been abated, although likely we will carry the scars of CVS for some time, and we no longer need to muck with the respository or have detailed meetings about directory structures due to a directory rename. In short, it's a good thing.

The biggest problem we have had with git migration is that git is relatively unstructured. It does not force a central repository to be used, and allows engineers to pull directly from another engineer's repository. For a small design team, we found that this was a drawback rather than an advantage, because it broke the central-repository model we were familiar with, and created confusion about what the "master" version of the code was. We tried electing one member of the design team to be the master, but this caused problems if the team member was unavailable for some time, due to travel, etc.

So we changed to using a central repository for git. Now everyone pushes and pulls from the central repository rather than from each other, and there is no confusion about what the mainline source code tree is, or who has to resolve a merge conflict. The CVS model may not have been fair (he who commits first, wins) but it was understood, and the central git repository brings us back to that same place. By looking at public repositories such as Github, it seems that this is now recommended practice for small teams.

It turns out setting up git to work like this is not straightforwards. Just as for CVS, there are some magic commands which must be issued to get a properly-functioning central repository. The main requirement for using a central repository is that all members of the design team must be members of the same group. With that in place, the repository can be created by doing (as root):

mkdir proj_name
cd proj_name
git init –bare –shared
cd ..
chown -R nobody.group proj_name


Replace proj_name by the name of your project, and "group" by the name of the group which all engineers are part of. nobody is a predefined user on Unix, so that repository files are not owned by root.

Monday, March 14, 2011

Don't put near hard disk

I just read a teardown article on the new iPad 2. Apple has integrated a bunch of magnets for its "smart cover", which made we wonder how this new version would fare in the cockpit.

The iPad has recently been certified as an EFB (for those non-pilots, this means it can replace the briefcase of printed charts you see airline pilots pulling around behind them in the airport). However, magnets are not a good thing in this environment. Already the iPad has a strong enough field to cause a compass to mis-read when it is within a foot of it; magnets could make this even worse (then again, maybe they are no worse than it is already. Someone want to loan me an iPad 2 so I can find out? :).