I have a question. I am developing a PCB in Kicad. I need to collaborate with a coworker.
Since we want some version control we started to put the project in git. We work mostly as software developers but that very occasionally we need to make a PCB.
We believe we cannot work on the same project at the same as generated files like Kicad’s are un-merge-able with git. It is not a big disaster as we don’t have to do that much work on it but still.
Are there good version control tools available which are ment for cooperation in developing PCBs which can be used in combination with Kicad?
This has been discussed many times over. The base problem is that any 2D (or 3D) data is inherently incompatible (or very difficult to combine) with distributed development. The only solution is to have isolated areas (design blocks, subcircuits or something like that with well defined connecting interfaces) wich KiCad doesn’t support ATM. It’s possible to divide the PCB to different projects and then cut&paste together, but it’s cumbersome.
The core of the problem is that a change you make with the UI in the 2D view isn’t necessarily local in the file and a even one character or number you change in the file isn’t necessarily local in the view. This is totally different than in programming where you see what is really changed, line by line, character by character. That’s why plain text files are fitting for version control and especially distributed development (merging) if they are edited with a text editor, but not necessarily if the data is somehow mapped to something else.
EDIT: cadlab or other fronted can’t solve this problem of distributed development. Otherwise KiCad files are well fitting for VCS, but merging is the problem.
I believe it was @craftyjon who mentioned that work was being done to improve the way the files were saved to improve its compatibility with versioning control tools, very small changes were changing almost all the content of the file making a some kind of diff useless. But for the life of me, I could not fine the link to the appropriate post.
We have made a bunch of changes in V6 to reduce “unnecessary” file changes that result in large diffs, or in files being marked “dirty” by the version control system when no real change has taken place. These changes are all done now for V6 (unless anyone discovers a critical bug).
This is not really the same as making it easier to merge design files. @eelik has it right here; merging 3D data (you can think of boards and schematics as 3D data at least, because they have graphics in 2 dimensions and a third dimension of layers/metadata) is really different from merging 1D data (code, prose, etc).
While people have developed some third-party tools for comparing (diffing) KiCad design files, this still doesn’t give you an easy way to merge different revisions of a file into one file. If both you and your colleague make changes to a schematic file, I haven’t seen any nice way of resolving the resulting conflict other than looking at both the sets of changes and deciding how to (manually) combine them together. The tools that present visual diffs can help that process, but they still can’t do it automatically.
That said, this problem occurs at the single-file level and projects generally contain multiple files. It is usually no problem to have multiple people working on a multi-sheet schematic, as long as they communicate and coordinate so that only one person works on one sheet at a time. And as @mxa mentioned, it is quite easy to have one person work on the schematic while another person works on the PCB layout.
There is also an entry about collaboration in the FAQ part of this forum concerning collaboration:
And now this &^%$#@! forum robot &^%$#@! is complainging because my post is “too similar” to another post. Duh, for some *&^%$#@! reason what I wanted to post here got posted in the wrong thread so I copied that and posted it here.
Imagine you move a single resistor with the traces attached. In the view, it’s a very local change. In the file, it affects several entities that are not necessarily in the same place: component and at least two tracks connected to its pads.
What Tom said is the first case, local in the view / not local in the file.
The second case is for example a graphic line which goes through the board from top left to bottom right corner. If you change one character in the file, namely one digit in one endpoint of the line, the whole board view is changed, from top to bottom and left to right.
Git (or any other ‘classical’ VCS) is therefore useless for versioning any large PCB/schematic projects. It was made for text, where the contents of the file are their own 1:1 graphical representation - the VCS engine sees the same thing the user sees on the screen, it’s just text. It isn’t the case in the PCB world, so making a pure git-based visual diff (or merge) can only work in a very small set of cases (e.g. merging changes in component names on a PCB with git seems to be possible, but forget about even modest routing changes being tracked without a lot of conflicts).
I wouldn’t say git is useless for versioning PCB projects, just merging them. It is very possible to use Git in a way where you just never merge things together, and we use this successfully at my workplace for managing hardware designs.
Git is very useful for versioning of almost any type of files. Of course that merging is almost impossible without the support in KiCad but you still get file history, branches, submodules, automation, sharing the project across multiple devices, …
People keep saying this but I’m not sure what kind of “support in KiCad” would actually make merging possible. Diffing/comparing, sure, but not merging.
Merging is taking two or three versions of the project and combining them into one. Some differences can be merged automatically and some create conflicts…
So for example KiCad could detect that one commit changed R1 from 4K7 to 10K and the second commit changed C3 from 100nF to 10nF. Or that pad has been connected to different net… You still may need to review the final merged files but with support from KiCad it could be much easier…
I know that that would be a massive undertaking for KiCad but you asked what I mean by “support in KiCad”
Actually that seems to be merging 1D data, i.e. timeline. Not merging different edits made for example at time 1:12:23 in one frame. So it’s comparable to merging programming source code, not 2D or 3D data.
Well, that timeline has multiple layers, so it is not strictly 1D. And there can be multiple effects on clips, etc…
And for example schematic can be represented as netlist so that is not so different from source code…
@craftyjon My bad. I meant diffs/merges/collaborative work on a PCB project using git/another text VCS are not very useful. Just for versioning, it’s fine, but it’s not what I love git for
@Kedarius I don’t believe piggybacking on top of any existing VCS will allow for easy merge/diff functionality. Classical VCS just compares lines of text without knowing any higher-level structure of the data that is managed. A trivial move of a big component (with a lot of pads) results in an enormous diff, even though from the user’s point of view the change is minimal. PCB/SCH files alone do not have enough information to allow such large textual diffs to be ‘squashed’ down into elementary graphical changes.
IMHO the way to fix this is to include high-level VCS functionality inside KiCad. In brief - use a text VCS like git for low-level storage/keeping commits, but aside from saving the current snapshot of the project to .kicad_sch or .kicad_pcb files, also store high level metadata about all changes between the subsequent revisions.
There are already a few projects that compare version controlled layouts (which include programs other than git)
Whilst closer integration within KiCad might offer some benefits, these projects do provide some insight into how version control can already be used with EDA projects. KiCad-Diff also has a text diff which identifies simple swaps . However, merging is a different problem - it is not a matter of how KiCad files are structured, it is a fundamental issue of how to compare 2d data.
