Today at Wired, Chris Anderson draws attention to one of our favorite problems: Version Control for Stuff. We wrote about this last fall in our article, Improving open source hardware: Visual diffs.
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
We have used visual diffs at work for decades, but then I do work for a major RIP software company so visual differences are our raison d’être.
Having said that, we’re as concerned with how many pixels changed and by how much, as we are with exactly what element changed.
Very interesting! Is there any well-known software (for RIP software, or in other contexts that we haven’t come across) that does this?
Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/
The Collada file format seems a strong contender for 3D files, and there do seem to be comparison tools for it. Being XML it should play with SVN/GIT without problems.
That PCB tool and visual compare are very good.
I keep getting shot down for s p a m. Even when trying to email you via your contact page, what gives?
Sorry about that; 90%+ of posts here are spam, so our filters are very strict. Please try regular e-mail instead.
Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/
Thank you, I also created an account so hopefully that helps.
I just wanted to point out that there is some open source PLM/PDM software out there for 3d parametric modeling. http://www.openplm.org/
It works with FreeCAD (http://sourceforge.net/apps/mediawiki/free-cad/index.php?title=Main_Page), which I think could/should? be the standard for open hardware design. It is still a little rough around the edges but it has grown leaps and bounds in the last 2 years.
I think your concept of automatic diffs is really great but for 3d it wont always tell the whole story. I worry that If you have to move or re-size a view it will show that you changed everything, when in reality all you may have changed is add a note etc. Still a great tool, I will be looking into how to implement the DiffPDF in the future.
PS Dont underestimate the power of a good revision block and Coordinate system (H1 – added detail view, added 0-80 Through hole for set-screw). Though this does require a person documenting what they did and why.
> I think your concept of automatic diffs is really great but for 3d it wont always tell the whole story.
It’s still possible with 3D– using boolean differences with surfaces and color coding. You may need to add cross sections and/or true 3D visualization to make it compelling, of course.
No, it won’t always tell the whole story, just like it won’t for 2D. These kinds of diffs are "dumb," just like they are in software, and won’t reflect the big picture or the "why" of changes.
>PS Dont underestimate the power of a good revision block and Coordinate system
>(H1 – added detail view, added 0-80 Through hole for set-screw).
This is just like adding comments to revisions on software source code. It’s (for better or worse) up to the humans to actually add these notes. *However* if the human does add those notes to the drawings, they will automatically be highlighted in visual diffs.
Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/
If you have not seen it before, qi-hardware has done some cool work with producing graphical diffs of kicad schematics where the versions were stored in git: [link:http://projects.qi-hardware.com/schhist/atben/ example]
You can read the announcement about it on from their mailing list [link:http://lists.en.qi-hardware.com/pipermail/discussion/2010-October/005677.html here]
Doing a simple comparison of two images is trivial on a computer! Just scale them correctly and overlay, then flick the images back and forth at about .7 Hz. The eye can easily see the changes in a few moments.
Another way to do it would be to have a sliding fader that changes the top layer image opacity, though that’s not as useful in general.
Simple to do this in either Javascript or Flash.
Yes, and that’s one of the best methods for data beyond 2D as well– 3D models that fade between two versions would be very helpful, too.
Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/
“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.) ”
The problem, from my point view, is the following:
people who develop software create a structure of folders with a bunch of textfiles in them. The text which represents the software is written by the developers themselves – at least they may “read” most of the files their software is comprised of.
In contrast, most mechanical engineers don‘t have the slightest idea how their designs are represented in the computer. Typically, designs are manipulated using a neat GUI that displays appealing pictures, but doesn’t show, what information is “behind“ these pictures (i.e. exact dimensions, tolerances, materials, constraints etc.) let alone the file formats for storing this information.
The mechanical engineers that I know wouldn’t agree with that– they *know* what primatives are used, how features are defined, and what surfaces the different dimensions are defined with respect to.
(There are also software authors who have no idea what they’re doing– I wouldn’t dismiss the issues on the basis that some people are clueless.)
Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/