Version control for hardware projects?

Tim O'Reilly asks about the equivalent of a version control system for hardware: http://www.itconversations.com//clip.php?showid=716&start=23:04&stop=23:38 (full talk here: Tim O'Reilly | The O'Reilly Radar)

It seems to me that there's also a need for simpler ways to create and extend PCBs/hardware designs in general. Eagle is cool (and free), but still very complex for someone who just needs to make a few changes. Are there better ways?

On the most basic level, any version tracking software like CVS can help with this, even if the files are a binary format. The hard part about a board design as a opposed to a software program is that there is basically just one file, AFAIK, while a program is generally made up of many files. Having everything split up into distinct files encapsulates the project into modules, which can be separately edited at the same time.

I know quite a bit about version control, but not much about board or chip design. What are the formats? What are the specific barriers to using existing version control software?

In the same line. It would be very neat for the main site to have a page containing a change log of the different board versions (and their revisions). I guess each "type" (Mini, BT, etc) would need its own changelog. The circuit for each revisions and maybe even steps that can be taken to upgrade or partly upgrade each boards (like how to make an NG support soft-reset – Diecimila). It would definitely remove some confusion. I know there is the Hardware page, but it seems to be more of a gathering of hardware information rather than a specific changelog.

What do you guys think?

P.S. This sort of brings the question, couldn't the Arduino project benefit from moving to a Trac environment? Wiki pages can easily link to Subversion entries for the IDE or schematics, are versioned. It's easy for people to enter tickets.

N.B. Maybe this entry would be better placed in the Dev. board :?

My 2 cents (for what it's worth :wink:

There's something of a changelog for the hardware here: http://www.arduino.cc/en/Main/Boards, though it doesn't yet have any links to more information about each version.

The hard part about a board design as a opposed to a software program is that there is basically just one file,

Not really. In my experience hardware design tools are even more verbose than compilers about spewing intermediate files around. Just like software, a hardware design tool will use libraries and can have multiple files to build a single device.

I know quite a bit about version control, but not much about board or chip design. What are the formats? What are the specific barriers to using existing version control software?

None at all. I use subversion on both my Arduino directory and my eagle directory. With a large project, or with multiple people, I would likely put one project with both hardware and software branches into one or two repositories, but just maintaining control of the Arduino and eagle directories works for my personal stuff (where I'm mostly concerned with having my various machines at work and at home synced up, less so with the revision history).

-j

None at all. I use subversion on both my Arduino directory and my eagle directory. With a large project, or with multiple people, I would likely put one project with both hardware and software branches into one or two repositories, but just maintaining control of the Arduino and eagle directories works for my personal stuff (where I'm mostly concerned with having my various machines at work and at home synced up, less so with the revision history).

-j

could you elaborate on svn with eagle usage?
My guess is, when you do an update, schematics and board layouts will be replaced as a whole, as they are binary files. Wouldn't the files get chopped otherwiese?

Shure there is file splitting e.g. as eagle libs, but as I understand eighthave, there is no way to split up a certain schematic or board layout in hierarchically consistent files. Thus, every sheet in an eagle schematic could represent an own file etc. This would be required for really collaborative work on an open hardware project.

Does anybode know how the internals of the open source schematic & layout projects gEDA/PCB (http://www.geda.seul.org/) would allow file versioning?

Well, BTW, there is now www.fritzing.org, als mellis annouced on the arduino blog: Fritzing: supporting the transition from prototype to product. | Arduino Blog.
They hopefully consider a collaboration feature...

Does anybode know how the internals of the open source schematic & layout projects gEDA/PCB (http://www.geda.seul.org/) would allow file versioning?

Personally, I prefer gEDA. The gschem capture program is actually more intuitive than EAGLE, and it's open source. To answer your question, I submit the following quote from the gEDA documentation (view online)

Schematic files are pure ASCII and will always be pure ASCII. gEDA does not support any binary file formats. The file format for schematics is described in the gEDA file formats document.

This means that version control systems should work flawlessly with gEDA tools, and allow developers to work simultaneously on the same file, easily verifying and merging their changes.

Tim

could you elaborate on svn with eagle usage?
My guess is, when you do an update, schematics and board layouts will be replaced as a whole, as they are binary files.

Yes, that is apperntly the case. When I goofed and made some changes to an eagle schematic on my laptop, then made some different changes to the same schematic on my desktop, I ended up tossing one set of changes as part of the resolution process.

Sounds like the gEDA tools are worth another look - I just took the path of least resistance in choosing eagle.

-j

Honestly, as a complete newcomer to electronics I decided to give both EAGLE and gEDA a try simultaneously. I spent an entire weekend following the tutorials for both products. I was far more impressed with gEDA. At the end of the weekend, I felt more comfortable with gEDA. That's not to say I'm any good with either suite!

Tim

I guess I'm pretty late coming in on this conversation.

The problem with traditional version control for HW CAD files is that there's no easy equivalent of "diff" to see what the differences are between two checked in versions of a file (or between your currently checked out working version and the last checked in version.) You're at the mercy of this being adequately described manually, or being able to look at two versions "wholistically" and tell what's different. In theory, there are a couple of things that ought to be helpfully diff-like: EAGLE (and other can programs) can export scripts that describe the design in text format, which IS diff-able. The check EAGLE does between board and schematic to see if they are consistent might be helpful when run with "old schematic" and "new board" (or vis versa) renamed to the same prefix. EAGLE could easily output a "text" version of a board/schematic listing component, coordinate, etc, in a way that might yield useful comparisons with diff.

Meanwhile, I've been reverting to ancient practices that predate most version control software. I've defined a new layer "Edit History" that I put text on whenever I do something significant. Hopefully. For instance, the Edit history of the through-hole "Freeduino" board looks like this:


(The gaps represent significant editing in other versions. ie, Daniel entered the schematic with SMT parts defined, and there was some work done, terminating with "V1.15", then everything was converted to TH parts and now-irrelevant (?) parts of the edit history were deleted.) The tough part is figuring out when you've done something that really needs an entry in the history. (Periodically, the version changes a new file gets written, giving me the simplistic backup capability.)