Tropo is part of CiscoLearn More

The making of the Tropo USB Drive

Posted on November 7, 2010 by Adam Kalsey

Part of the Tropo meetup kits is a solid metal 2 GB USB drive that has a bottle opener on one end. They’re laser engraved with the Tropo logo, and people we’ve given them to think they’re pretty nifty.

As part of the drive, we wanted to load some Tropo samples and software, so that people who get them have some Tropo code to help them get going. Like most promotional USB drive makers, the manufacturer of our drives offers a data load service for a pretty tiny fee. But we wanted more.

We’re constantly adding new samples, updating existing ones, and adding features to our code libraries. We wanted to make sure that people who get our drives have the latest and greatest software, and loading something a few weeks ahead of time simply wasn’t good enough for us.

Perhaps you’d like to try the same thing, so here’s how we create the software load for our USB drives.

The whole system relies upon git, the distributed version control system. Git has a concept called submodules that allows you to essentially embed one git repository inside another, while still maintaining the original repository for updates, history, branches, and all the other goodness you get from a SCM.

By using submodules and git, we can create a process that ensures we always update to the latest version of the various packages prior to loading them on the drives.

The first part of this describes how to set up your git repository and use submodules to construct your software pack. The second part will describe the installation process and how it’s streamlined to make it easy to load the software on the drives.

I created a git repository called “usb-pack” and inside it created the directory structure we wanted to use. The USB pack is up on Github if you want to follow along.

git init usb-pack

Our sample code would go in a directory called “examples,” our WebAPI libraries in a “library” directory, and some various applications that use Tropo in an “applications” directory on the drive. I even wanted to include the Phono SDK and some sample Phono apps.

I wanted a directory structure that looked like this…

The “examples” directory will be a clone of the Tropo samples git repository, so I didn’t actually create that directory yet. It will be created in a minute when I add the submodules in. The other directories are mostly containers for a collection of submodules, though, so they need to be created up front.

mkdir applications

Nothing special about that. Just create the directories.

I then went and added the git modules that we wanted to include as submodules in the appropriate directory using a command like this…

git submodule add git://github.com/tropo/tropo-webapi-php libraries/tropo-webapi-php

This creates a linkage between the repository at github.com/tropo/tropo-webapi-php and a new directory called tropo-webapi-php in the libraries directory. I did the same thing for the various applications in the applications directory and the Phono directory.

It’s not necessary for all the git repositories to be in the same place, or belong to the same github account, or even be on github. They can be any git repository anywhere that’s accessible to you. For example, Zhao Lu’s Openvoice, the Ruby on Rails clone of Google Voice, is in his own git repository, but is included as a submodule inside applications.

For the examples directory, since I wanted it in the root, but called “examples” and not “tropo-samples” like the repository is named, it was as simple as this:

git submodule add git://github.com/tropo/tropo-samples examples

Some of the other directories like “logos” and “bin” contain files that aren’t submodules at all. The only place they exist is in this repository. You can mix and match submodules and your own files. In fact, in the phono and other directories, I’ve added README files to explain what they are.

I also created a README that would appear in the root directory so when someone pops the USB drive in, they can see what it’s for.

One thing we discovered when setting up the modules is that it’s best to
use the git://github.com/{username}/{repository} format to fetch your submodule repositories. Using the http access or the git@github.com:{user}/{repository}.git access to the repositories caused various sorts of permissions errors for some users.

In a future post, I’ll describe how we built the installer and how to get the software on the drives.

4 Responses

  1. Oh so geeky! I like the git repository idea 😀

  2. Dan York says:

    Adam, that’s VERY cool! I didn’t know about the “git submodule” trick… very nice!

  3. […] that, I appreciate learning new ways to do cool things with git. Here was a new one to me – using git “submodules” to build a package consisting of other git repositories. In this case, Adam Kalsey wrote about how he used the “git submodule” command to […]

  4. Want a Tropo.com USB Bottle Opener?…

    I have to say this is one of the coolest giveaways I’ve seen for bit… yes, it’s for a service of my employer, Voxeo, but regardless, it’s a cool piece of schwag (and I had nothing to do with it):……

Leave a Reply