My apologies if you speak the Queen’s English since that title probably has a whole different meaning to you than I intended. In fact, I’m talking about Git, the version control system. Last time I talked about how the program came to be and offered you a few tutorials. If you are a dyed-in-the-wool software developer, you probably don’t need to be convinced to use Git. But even if you aren’t, there are a lot of things you can do with Git that don’t fit the usual mold.
Git is one of those tools that is so simple to use, that you often don’t learn a lot of nuance to it. You wind up cloning a repository from the Internet and that’s about it. If you make changes, maybe you track them and if you are really polite you might create a pull request to give back to the project. But there’s a lot more you can do. For example, did you know that Git can track collaborative Word documents? Or manage your startup files across multiple Linux boxes?
Git belongs to a family of software products that do revision (or version) control. The idea is that you can develop software (for example) and keep track of each revision. Good systems have provisions for allowing multiple people to work on a project at one time. There is also usually some way to split a project into different parts. For example, you might split off to develop a version of the product for a different market or to try an experimental feature without breaking the normal development. In some cases, you’ll eventually bring that split back into the main line.
Although in the next installment, I’ll give you some odd uses for Git you might find useful, this post is mostly the story of how Git came to be. Open source development is known for flame wars and there’s at least a few in this tale. And in true hacker fashion, the hero of the story decides he doesn’t like the tools he’s using so… well, what would you do?
We love Git. We know everyone has their favorite version tracking tools. But even those that don’t care for Git should see the value of getting meaningful Diff data from tracking Eagle layout files.
Was that last sentence just gibberish to you? Let’s take a step back. A few years ago it was impossible to use version control with Eagle at all because the schematic and PCB layout software used to save its files as binaries. But then Cadsoft transitioned to saving Eagle files as XML. This opened the door for things like scripting to rename parts en masse and to track the files under version control. One problem with the latter has been that performing a Diff on two different versions of a file results in XML changes that are probably not human readable. [Patrick Franken] wrote this script to add at least a glimmer of meaning.
We’d love to see some kind of side-by-side highlighting on the schematic or board renderings themselves. But that’s quite a ways off if we ever actually see it. For now his script will take the Diff and print out the tables seen above denoting which types of changes were made from one version to the next. It’s a start, and we hope it inspires even more work in this area.
There’s a fine line between solving problems that don’t exist and solving problems that no one recognizes until a solution is found. The former shows up with housewares peddled on late-night infomercials, while the latter is summed up by [Henry Ford], “If I asked people what they wanted, they would have said faster horses.” [Dave]’s method of storing microcontroller code in the cloud definitely falls into the ‘useful’ category.
[Dave] first realized the problem when he was digging around the IDEO Toy Lab and came across an orphan project, a Barbie credit card swiper. [Dave] had no idea if the firmware for this project was saved on the server, or even if the current version was available. One solution to this problem could be burning a copy of the source onto the Flash or EEPROM on the board.
There’s a problem with this idea, though: storing the source in an Arduino’s memory takes space. Thinking laterally, [Dave] realized that editing source happens on a computer, computers are connected to the Internet, so why not keep the source “in the cloud?”
[Dave]’s solution is to host the source on GitHub, and tie every piece of code to a board’s unique USB serial number. This gives every Arduno a unique ID, allows for version control, and libraries of multiple files.
As the Open Source Hardware movement gathers steam, it has become clear that the tools to work collaboratively on hardware are in the dark ages when compared with slick frameworks like Git used to work on software projects. We’ve read a fair amount about this lately, but the idea of visual difference generation for PCB layout is one of the better proposals we’ve seen.
Of course the big difference when it comes to version control is that software is text, but hardware is graphic and only represented by text for the computer to use. It’s easy to use the ‘diff’ command to show you what text is out and what text is in, but that doesn’t translate to a schematic. [Windell] is using command-line utilities to produce a schematic that colors changes differently for easy visual detection. This means exporting before and after schematics as PDF files or images, then using ImageMagick to process them. He also points out that there’s a package out there called DiffPDF that will let you compare differences in PDF files automatically.
Check out what he has to say in his article, and make sure you get to the bottom where he suggests ways you can help. We agree that it shouldn’t be hard to roll visual diff functionality into open source software packages used for hardware design, and to integrate that into version control systems. It’ll just take some time for the concept to proliferate.
