Usefulness of Commit Emails from Version Control Systems

A few days back I found this link on Hacker News about a blog post that talked about best practices for using version control systems. I also thought about something which I think ties in very well with his blog post. I recommend setting up commit emails for every commit done, whatever the VCS may be, Git, SVN, Perforce etc. Sometimes the usefulness of this system is not completely understood, so I will talk about here. My notes on this are based on my experience with using commit emails from SVN (set up with mailer.py and svnspam), but I think it should be applicable to any version control system.

Code Review Tool: Ideally all code that is checked-in should be code reviewed beforehand. Sometimes it is not possible to do so, maybe the check-in is of two lines or there are time constraints. Then you can just say "check it in, I will review the commit email". And then based on what you see in that email you can recommend changes. Now this is not as good as code review before check-in but this still helps. This way a lead engineer can also recommend further changes in code if necessary.

Enforce Standards: Pre-commit hooks can be used to ensure agreed upon formatting, but sometimes coding conventions are harder to enforce. Having commit emails ensures that a lead engineer can request more changes in code to ensure code confirms to a standard and is consistent with existing conventions.

Watch Modules: With email filters and module names in commit email subjects, it is very easy to setup filters to track specific modules. In a large company with a number of modules in development this makes it easy watch specific modules, even ones that are being developed by other teams.

Increased Visibility: Anyone in the company can ask to be included in this mailing list. This is especially useful for managers who want to track progress on various modules and don't want to install version control tools.

Handy record of releases: Many times I have had to look up a release version I created months back. With the commit emails I can just search my inbox for the tag and thus get all the info I need. I don't have to use Tortoise Repo-browser to look up the tag.

Merge requests: Commit emails can also be used by the team to forward specific changes to one another, in order to be merged in another modules. This is very useful for small changes that need to be merged, and an email will be sufficient for that.

I am sure there are other uses of this kind of system, do you have this setup where you work? Have you found it useful in other ways? Let me know.

How to compile Android source on Snow Leopard (Mac OS X 10.6.7)

So after that relatively long hiatus I am back. I have been busy mainly working on Android, and to a limited extent, iPhone apps. I wanted to compile android from source, I had heard that it wasn't too difficult. I had recently bought a MacBook Pro laptop and dedicated a weekend to this project. Well, like many things, it took longer, and was more involved and had several missteps. I will document what worked for me here, in case anyone else wants to do the same.

Google's instructions for this are provided here. There are other excellent blog posts about this, here and here. Unfortunately they all were about Android install on Mac OS x 10.5 or older. They also didn't talk about what happens if you install Xcode 4.

My Mac environment for this exercise is Snow Leopard Mac OS X 10.6.7 and Java 6 (1.6.0_24-b07-334). I also had Xcode 4 installed. Also ensure that you have a Google account, as you will be prompted for it during installation.

(Incidentally if you want to remove a version of Java and install another in Snow Leopard, delete /System/Library/Frameworks/JavaVM.framework folder and run Software Update on your mac. This will install it again).

So as described in Google website, run Disk Utility app on your Mac to create a 12 GHz disk image, with the format being Mac OS Extended (Case-sensitive, Journaled). It gets mounted in /Volumes, you can call it any name.

Now you have to install Macports. Some of the Google group posts say that it isn't needed for Snow Leopard, but I had already installed it. Also, to install it you have to compile it from source (following website instructions). Apparently the .pkg installer needed root permission but didn't not prompt for password. But with source compile we can use sudo command to work around that. After installing Macports don't forget to synchronize with the MacPort's rsync server.

Now ensure that /opt/local/bin is added to path. Macport install automatically modifies your .bash_profile to do that. If it is not setup correctly run 

$ export PATH=/opt/local/bin:$PATH.

Next follow the instructions on Google website to install gmake libsdl etc. And then revert gmake to older 3.81 version as detailed there.

After this add ulimit -S -n 1024 to your .bash_profile file to increase simultaneous file descriptor cap.

Now download the source using the Repo tool, set it your path, by following Google website instructions. Note that when you run repo sync it will take 10 or so minutes to download all source code.

Now run the following commands to compile:

$ source build/envsetup.sh

$ lunch full-eng

$ make -j2

Now on my MacBook Pro with Snow Leopard it will error out saying MacOSX10.5sdk folder not found. So download Xcode 3.2.6 from apple developer website, install it NOT in /Developer folder but in /Developer326 folder (otherwise it will overwrite your existing Xcode 4 install). Now copy /Developer326/SDKs/MacOSX10.5.sdk folder into /Developer/SDKs folder. Run again make -j2 and the compile will run for 25 or so minutes and you are done. You can now run emulator command to launch the emulator.