« How'd you make it do that? | Main | Looking back: dynamic server appliances with Xen »
October 11, 2008
Looking back: discovering git
While the rest of the world tends to use git for version control, Reactrix has been using it for content management and distribution since around September 2005 and only recently for version control.
When I started in 2004, the system used CVS for content management and RPM files for content distribution. CVS made sense as all content changes were managed in a CVS repository; but as the network grew, the use of RPMs for distribution became problematic. Every time a new version of a channel was pushed out, the server created a new RPM file which each display transferred and installed. In most cases, channel updates involved changes to a small subset of files, but the displays had to transfer all files as part of the RPM file even if they already had a copy from a previous version. This was especially annoying when the display's network connection was slow or intermittent and the transfer failed at 95% and had to restart from the beginning. So it was time for something new...
Before working at Reactrix I'd spent about 4 years at Yaga, where we developed a backend based on a content addressable filesystem. The filename for each file in the system was its SHA1 hash, so the system could quickly locate any content on disk by knowing the content hash. As I started making plans to implement something similar for Reactrix, my coworker Russell Belfer suggested that we might be able to use git to handle some of the content management and distribution.
I found that git already had most of the functionality we would need. We could use it to store multiple versions of content in a repository on the server, to transport content files to each display, and to install new and updated content in the filesystem on each display. There was one thing missing though - our displays communicated to the central server using HTTPS, and the git HTTP transport didn't support some of the SSL configuration we needed. Since git is open source software, I set foot on a very slippery slope and started submitting changes. In the beginning, it was just additional SSL settings. Later I delved into the internals of HTTP transport and added other features that Reactrix would need, some that I thought Reactrix would someday need (I was wrong...) and some that just seemed cool. In the end, we were able to swap in a new content management and distribution system that performed well, used much less bandwidth to each display, and was much more tolerant of periodic network hiccups.
Since then we switched from Perforce to git for the projects my group worked on (other engineering projects stuck with Perforce, and the content folks still use CVS.) We also incorporated git into a CMS redesign as a more generic mechanism for moving data between the server and displays. Another coworker, Scott Chacon, got a little crazy about git and has since become involved in related software development and training. If you're interested in learning more about how git works, I'd highly recommend watching his presentation from Railsconf 2008.
Posted by nickh at October 11, 2008 02:08 PM