In his article, Chris introduces the big ideas (using our article for an example) and discusses a couple of the current efforts towards “source code” repositories for hardware.
Instead of such expensive and closed commercial systems, we need open Web-based repositories for design files, filling the role that GitHub, Sourceforge, and Google Code have for software. (You can already use the existing code repositories for design files. And some, like GitHub, already have good ways of comparing images. But none of them were designed for CAD or PCB design, so you can’t understand the contents of the files and manage them the way you’d manage text.)
I’m not sure to what extent the latter part is truly relevant. Version control for software projects isn’t necessarily context aware, so why should we expect hardware to be?
That is to say, when you commit a new revision of your code to GitHub, do you expect it to recognize— and tell you in a diff —that a given block of code represents a loop or class definition? (Likely not— just as it doesn’t understand that another loop draws an integrated circuit footprint.) And, version control is already used on files that are not particularly human-readable, whether those files are ultimately used in a hardware or software context.
One might even argue that hardware is more amenableto simple diffs than software, because our eyes can take in so much information, so quickly.
But in any case, he’s right on the big points: we need those visual diff tools. And yes, as version control tools do evolve to become more context aware, we’ll increasingly need them to be aware of the differences between hardware and software.
Link: Wanted: Version Control for Stuff @ Wired