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.