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.
1 Like
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.
1 Like
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” 
Edit:
For example one could say that merging is not possible in video editor. See https://elements.tv/wp-content/uploads/ELEMENTS-Media-Storage-Davinci-Resolve-16-Compare-Timeline.jpg for example of support for collaboration in DaVinci resolve video editor
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.
1 Like
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.
It is true that Git “likes” text diffs but that does not mean that you can not see the changes visually, edit them visually and create the final textual diff in the background… But I do understand that it would be a massive task for KiCad… But the question was “how would the merging support in KiCad look like”…
So basically use Git in the background but do visual diffing/merging in KiCad…
That does not have to be such impossible task however… You do not have arbitrary 2D data but they have some sort of structure - footprints, traces, shapes, etc…
And a person can describe the changes and do the merge so the machine could be able to do it also… For example I can imagine KiCad detecting and visually presenting changes “U1 moved from here to there and pad 5 has been reconnected to GND from VCC. Do you want to move it or keep it? Do you want pad 5 be GND or VCC?” So for example one color for U1 at one position, second color for U2 at second position and you would click and select the position that you want. And KiCad would automatically use traces from the relevant file so that they would be connected correctly…
Sounds great on the forum! Now try to code it in C++
2 Likes
Heavens forbid someone re-annotate. 
I’ve said that it would be a lot of work to implement it. But the question was
but I’m not sure what kind of “support in KiCad” would actually make merging possible. Diffing/comparing, sure, but not merging.
KiCad has timestamps as one way how to solve this… It can happen already with the binding between schematic and PCB layout…
And ofc if someone re-annotates then maybe he/she wants to change it the way he re-annotated
I didn’t mean “possible in theory” I meant “possible with a level of effort likely to be taken on by a real developer” - I don’t mean to sound snarky, but if this PCB merging technology were as realistic as you make it sound, don’t you think all the expensive commercial tools would have it already?
I also do not want to sound snarky and I do not have enough experience with all the expensive commercial tools but for example the visual diff tools mentioned by @John_Pateman are a good start
You may wish to follow https://gitlab.com/kicad/code/kicad/-/issues/2151
A visual diff tool is far more tractable and is in the plans for KiCad’s future
1 Like
They do. I use Altium at work and we use the collaborate and merge feature all the time so that more than one of use can work on the layout at the same time. We I get done I do a merge and see the areas that others have changed and committed visually. There is a grid overlayed that you can change the resolution of. I than accept or reject each block to be brought into my version of the layout. Then I save and commit my layout and it becomes the new head.
The funny thing is that it doesn’t work on schematic pages which should be the easier problem.
I know that Expedition and Cadence have even fancier collaboration feautures.
Good point, I haven’t used that feature much but you reminded me that it does exist. I suspect schematic pages are actually a harder problem rather than easier due to the links between schematic sheets in a multi-sheet or hierarchical design, but there could be other reasons. Anyway, if we add a transaction log to the file format as Tom alluded to, it makes it more possible to do things like this as you can track the ancestors of actions.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.