What’s the Difference Between Version-Control Systems for Software and Hardware?
When working in any application, we typically make changes of some kind. But what happens when we save a file after that? Basically, the old version of a file gets overwritten with a new one.
Unfortunately, no one is perfect and some mistakes may happen. To find out what exactly has gone wrong, it can be useful to get back to the previous state of the file.
In earlier days, to keep track of all your changes, you had to save your file as separate versions even after small changes. Eventually, you would end up having multiple “versions” of the same file, stored locally on your desktop, which isn’t very convenient: Over time, some files can become difficult to find, or might even be completely lost if something ever happens to your device.
In software (SW) or hardware (HW) development, multiple people often work on the same files. Unless they have a close face-to-face collaboration, it can be very hard to make sure that everyone is aware of the changes done by the others.
To keep collaboration work organized, various version-control systems (VCSs) are used to help manage your project changes. VCSs may vary greatly, depending on requirements and the area of application. Because they’re mostly used for SW and HW development, in this article, we’ll look at the differences in how this technology is used for these two industries.
What’s the Difference Between SW and HW?
SW and HW are two different worlds. SW is, in fact, just information, recorded and stored as the lines of code. HW implies the presence of a physical object, e.g., a printed circuit board (PCB) that has been created with the help of design files, sent out for the fabrication of a final product
Most VCSs are oriented to work with pure “information” and support the textual format, as they were originally created for SW development. That seems to work just fine for SW developers, who basically can do all of their work in a text editor. But how about HW?
In HW development, “information” is typically wrapped up in design files, produced with the help of EDA tools. Some of them (e.g., Altium, OrCad, 3ds Max) support only binary file format that’s not even optimized for use in VCSs.
Despite some differences, they’re similar from the perspective of versioning. Both require managing file versions, produced either with the help of some proprietary tools or as the result of direct interaction with the source code.
Some Common Problems with Using VCSs for HW
As has already been mentioned, in many cases, it’s the binary file format that’s not optimized for use in most VCSs. Unlike many other VCSs, Git doesn’t restore the whole file but only updates the pointers (that contains the record about changes) to the original file (Fig. 1). If no changes were made with new commits, Git keeps everything the same way to avoid redundant files and increasing the size of repositories.
1. Git records and stores changes done to the original file. (Source: git-scm.com)
However, this isn’t the case with the binary file format. Due to decentralized nature of Git, any changes in huge binary files can make Git repositories grow by the size of their files after every commit, and eventually cause problems while cloning them.
Using a Large File Storage (LFS) extension that allows for storing large files on separate servers, and pointers can be kept inside Git along with Git attributes. Still, it’s only a partial solution to this problem. A second problem is that most VCSs are optimized for the textual format, and the Direct File Comparison (diff) feature they provide is textual, too, and that doesn’t always work that well for HW engineers.
The diff feature is an integral part of any VCS that compares different versions of the same file and provides a quick report of what’s been changed or modified. This feature can show you the exact lines of code that have been affected, which is really convenient for SW developers.
But when looking at the diff in textual format, it’s not always clear how certain elements have been changed in HW design files. Furthermore, viewing diff for binary files only allows you to see how certain properties have been changed (e.g., size or image dimensions). For example, can you learn exactly how the position of this Autodesk Eagle PCB trace has been changed from looking at the Git diff (Fig.2)? Unless you have really outstanding calculating skills, the answer is likely “no.”
2. This is an example of the textual diff, done with the help of Git for Eagle PCB.
However, that’s exactly the kind of information that HW engineers are interested in seeing while looking at the diff. Therefore, because there’s no decent way to present it may be the reason why we see so little open-source HW (OSHW) collaboration.
Some Lessons from the World of Open-Source Software (OSS)
At the core of any open-source project is the concept of sharing information with the others to create better products. GitHub is probably considered the industry standard for OSS development. It’s a Git-based platform that has plenty of great collaboration features, like “fork” and “pull request”.
Since pull request requires comparing proposed changes with the original file, it is, essentially, a diff operation. Thus, it would probably be fair to say that diff functionality is the foundation of any open-source collaboration. It’s also very helpful for code review purposes, helping to decrease the possibility of bugs in code.
So, What Have We Got for HW?
CADLAB.io is another Git-based version-control platform, but more user-friendly for HW development, and it supports visual diff.
It’s important because unlike SW-development tools, CAD applications rely heavily on the graphical approach for creating designing objects. Therefore, to make the diff work for HW developers, it needs to be visual as well, so that the information presented is easy to grasp and digest (Fig.3).
3. Using the same file as that in Fig. 2, here’s an example of the interactive visual diff done with the help of CADLAB.io.
Just like GitHub, it also serves code review purposes, or, more specifically, design review if speaking in the context of HW development. Design review is important here, because any design mistakes might result in the production of malfunctioning product.
The reworking of a prototype might require a significant investment of time and money. It’s the design review that helps to decrease development costs and time to market.
What We Might See Coming Next
To truly enable HW collaboration, a cross-platform solution is mandatory. In HW development, we often must deal with multiple CAD formats, which potentially limits further expansion of OSHW collaboration.
The other problem is communication between the HW producer and manufacturer. A HW producer needs to create many detailed specifications that are subsequently sent to the manufacturer, which is time-consuming and gets out of date very quickly. Therefore, streamlining of communication is another improvement that should be looming on the horizon.
Dmitry Vavilkin is Marketing Manager and Dmitry Zhgenti is CEO of CADLAB.io.
