When writing software a key part of the development workflow is looking at changes between files. With version control systems this process can get pretty advanced, letting you see changes between arbitrary files and slices in time. Tooling exists to do this visually in the world of EDA tools but it hasn’t really trickled all the way down to the free hobbyist level yet. But thanks to open and well understood file formats [jean-noël] has written plotgitsch to do it for KiCAD.
In the high(er)-end world of EDA tools like OrCAD and Altium there is a tight integration between the version control system and the design tools, with the VCS is sold as a product to improve the design workflow. But KiCAD doesn’t try to force a version control system on the user so it doesn’t really make sense to bake VCS related tools in directly. You can manage changes in KiCAD projects with git but as [jean-noël] notes reading Git’s textual description of changed X/Y coordinates and paths to library files is much more useful for a computer than for a human. It basically sucks to use. What you really need is a diff tool that can show the user what changed between two versions instead of describe it. And that’s what plotgitsch provides.
plotgitsch’s core function is to generate images of a KiCAD project at arbitrary Git revisions. After that there are two ways to view the output. One is to generate images of each version which can be fed into a generic visual diff tool (UNIX philosophy anyone?). The documentation has an example script to help facilitate setting this up. The other way generates a color coded image in plotgitsch itself and opens it in the user’s viewer of choice. It may not be integrated into the EDA but we’ll take one click visual diffs any day!
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.
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.