Getting collaboration right with any ECAD tool can be rather challenging. For most of us we tend to stick with the “old school” methods:
This method not only clutters up your inbox but it also forces you to work in a serial fashion. The solution to this is Version Control. Life started to get much better, though more complicated, once Version Control entered the ECAD landscape.
Version Control Systems (VCS) have been around for decades and popular among the software folks for just as long. Version control systems allow users to commit their design to repositories and collaborate with others without writing over each other’s files (which typically occurs when working off of a shared network folder). Altium Designer® supported version control systems, such as SVN, for quite a few versions. tools within Altium Designer, such as the Storage Manager, gave users a greater capability to collaborate with their team. Starting with version 18 Altium integrated Git into Altium Designer. This was a huge step forward for the ECAD community.
So why are we so wild about having Git support in our ECAD tool? In a previous blog we discussed the importance of writing meaningful Git commits and how that gets tied into a larger ecosystem. Git has become a popular VCS that integrates nicely with workflow systems and we want to leverage that as much as possible throughout all of our design tools. With Git support we can now bring our ECAD tools into modern workflow systems widely used and popularized by the software community.
Resolving conflicts is hard at the best of times. Luckily Altium has built a tool for that. The Storage Manager contains a feature that enables users to compare your commits with others and resolve conflicts should any exist. Unfortunately the Storage Manager won’t resolve all conflicts. You’ll still have to intervene when your team starts having it out with each other but at least this is a start!
Take an example of two people working on the same schematic file. Person A commits and pushes their changes to the server. Person B makes changes to the same file locally and then attempts to pull Person A’s changes. This will now result in a conflict because they both made changes to the same file. Person B can merge his commit with Person A’s cleanly by using the Storage Manager tools. Note that any change to schematics or other Altium Designer files will result in a conflict because they are binary files and Git does not know how to cleanly merge non-text files.
Another useful tool for PCB design collaboration is the Collaborate, Compare and Merge tool. This is extremely helpful when multiple people are trying to route a board together. Keep in mind that there are a number of objects/features that are not supported by this tool’s merging capabilities.
Imagine a scenario where an engineer has completed schematic capture, initial placement, and some routing. The engineer now wishes to perform some experimental routing to determine the optimal layer stackup. When the engineer does both the schematic capture and board layout, this process is fairly trivial: the engineer will save a local copy of the layout and just rename it to something like “experimental.” What happens once the PCB has been introduced into the mix? What if both the engineer and PCB want to experiment with some routing in parallel but leave the “agreed upon” routing intact? Consider the following two scenarios:
Scenario 1: The engineer and PCB have agreed to leave the initial routing as the latest and greatest in their VCS. The engineer starts to experiment with some routing on a copied version of the design (renamed as a new file) and so does the PCB . Emails with attachments start to fly back and forth and by the time we know it we’ve appended “_v92e” to the latest version. Shame on you both for using the despicable alpha-numeric filename versioning scheme. This can easily get confusing for the two and even more so when others are copied on 100+ e-mails filled with these attachments.
Scenario 2: The same engineer and PCB have had a change of heart. They’ve decided to take turns committing their experimental routing to the repository and reviewing together. Now that’s teamwork! Well, not quite. It’s inevitable that we will start to create conflicts and spend countless hours trying to resolve things that should have just been experimental in the first place.
The ideal scenario: Imagine a world where all three designs can exist within the same repository and switching between designs can happen just by a click of a button. No, this isn’t some futuristic system we are describing, in fact, it already exists. This concept is known as “Branching” and is used in Git all the time. Each user can experiment in their own “sandbox” (or branch in this case) without disrupting the main, agreed upon, design. In this branching example we depict the engineer and PCB branching off into their own experiments and then taking a new direction.
Figure 1. Experimenting and then taking a new direction
In another example both the Engineer and PCB experiment with the routing but they decide that the PCB ’s experiment makes the most sense to proceed with. That branch, Branch B, is “merged” into the master branch and some final tweaks are made thereafter.
Figure 2. Experimenting and going with Branch B
Unfortunately this “branching” method is not natively supported in Altium Designer (yet?). One will have to use external Git clients such as Git BASH, TortoiseGit, or Sourcetree to take advantage of this feature.
Version control systems have become popularized among not only software engineering disciplines but also across all engineering disciplines. These collaboration systems, such as Git, have enabled users to work together without blasting away each other’s designs. With the integration of Git into Altium, collaborating with your ECAD team has never been easier. Hopefully this article has shed some light on the importance of tools like Git and how you can get started with them. Talk to an Altium expert today to learn more.