Does Kicad need version control integration, or is it just me?

Schematic
21

I didn’t take it as at all aggressive, and sorry if my response made you consider that possibility. I was just very surprised that git’s submodules was frowned upon as it’s the only mechanism I’ve ever seen used for managing code dependencies which are in another git repo. I don’t claim to be an expert at all and wondered what the alternatives are, as I’ve not encountered them. I’ll have to look at subtree.

I agree with that statement, but I can’t image that 100% of Kicad’s users are focused on that set of requirements. I’d assume that’s the high end Hardware design shop and I think probably a significant percentage of Kicad users don’t design PCB’s for blue chip HW venders.

I must try to both find and follow an open Hardware development project as I can’t see how the tools are available for a smooth workflow. That’s my perception with very limited knowledge, or imagination. Perhaps my initial message documented a problem which doesn’t exist, but given the effort that people seem to be making to get around the non existent problem, writing bash or Python scripts to do image diffs, or using git smudge there seems to be an issue.

I’ve obviously got little idea of the internals of Kicad, and perhaps I’ll make some time and start looking at the code, but it seems that Kicad contains all the information that it needs to specify a schematic. (I’m going to concentrate on just the schematic for the moment.) So Kicad processes and saves all the data which is needed for the schematic I just wonder could that data be redistributed in files so that some files contain the essence of the design but other files contain implementation details, which change on a regular basis and are project specific. So I hit a snag with component references, perhaps they are project specific not part of the core design. So in my example two project share a LM5088 SMPS, the circuits are exactly the same but component references are specific to the individual projects, not the circuit design.

22

Seeing as I have been working on an open project keeping the kicad files in step with the eagle files, I feel I have a good sense of exactly how you would need version control to work for a veiwer for minimal complexity creating,

  1. Footprint Locations and Rotations, Kicad already can export this Info, but currently unsorted (I have made a report on this) https://bugs.launchpad.net/kicad/+bug/1793764
  2. Netlist differences between the Board, Summerised to different footprints, different nets on pads, and different values,
  3. Different zone polygon outlines and properties, ignore the fill data and just look for the shape and settings,

This would cover most increments giving the most surmised form of changes on a board, yes there is much more that can change, but trace data would make it much harder to merge, keep track of, etc,

2 Likes
23

I second that. I fullty agree that some form of version control would be very nice, but it does not need to be “integrated” into kicad, whatever people think that means.
m

24

I have been dreaming of light integration so that with some key combination KiCad would do git commit with automatic message. It would be nice if the message would be human readable, but it would be difficult to generate meaningful message which would tell what was changed since last commit.

1 Like
25

Maybe this has changed in 5.0, but at least in 4.0.7, KiCad did not always follow this rule:

  • Entire sections of the .pro file would move around when just one setting was changed.

  • If I change a footprint in CvPCB (say I change R2 from R_Axial_DIN0207_L6.3mm_D2.5mm_P7.62mm_Horizontal to R_Axial_DIN0207_L6.3mm_D2.5mm_P2.54mm_Vertical) and then sync the PCB to the new netlist, any changed footprints move to the end of the .kicad_pcb file, rather than R2 maintaining its position within the file.

26

Sorry, I haven’t been enough precise: my experience is restricted to eeschema. It’s unfortunate that CvPCB does not behave similarly.

27

Hi John, can you share that similar script in Fossil with me please? Thank you.

28

@jwhitmore: In the software world how do you resolve a GIT merge conflict? Well with a diff tool and your (IDE) editor of course. What you use to resolve the conflict are the very same tools you use to generate the work (code) i.e., you work within the same confines and context as during normal work (code) generation. Not so with CAD. Though the KiCAD files are text based and therefore easy to put into GIT, I would never in my wildest dreams want to resolve a merge KiCAD schematic/board conflict on a regular basis with my text editor.

Though a GIT submodule is a natural for a code library to pull in and plug into for software, not so for a CAD system. If I pull someones library in through GIT in my code, I just get myself familiar with its API so I can make intelligent calls - the submodule largely stays a black box to me. I would never accept this method for a schematic that goes on a commercial board. I need to know and understand far more about what it is I plunk on the board from that library. I.e., there is an interaction between my schematic and the part I just pulled in - that needs to be quantified and qualified. This is very different from a black box sofware module. So though GIT submodule “sounds like” CAD submodule - they are completely different ideas. Not to say they cannot be combined, but the need/nature is different.

Btw, reference designators can be hugely important in some designs; I have been part of modular designs whereby a significant part of schematic A was the same as schematic B (think of a microcontroller design with different analog interfaces). To make repair and test much easier (manual job), keeping all the components around the microcontroller the same with the same layout and the same reference designators makes a difference.

All that isn’t to say we should/couldn’t have revision control in (Ki)CAD. Just that it isn’t the same as in software. At first face it looks the same/similar but dig a bit deeper and it isn’t.

My 2ct anyway!

1 Like
29

Hi joost, thanks for your response, but a few thoughts…

You mentioned that a Software library is a black box to you, only familiarising yourself with the API calls you need. You’d never work that way with electronic design for a commercial board. That’s great I’m not asking you to change the way you work. I only suggested that information be stored in files in a more flexible manner, so that if people wanted to use a more collaborative process, assisted by version control, they could.

I don’t think that 100% of Kicad users are creating commercial boards, but even if I was, if there was a SMPS hierarchical schematic sheet which I could treat as a black box which exported 3 symbols (Vin, Vout and Gnd) I’d be happy with that black box as well. I have no problem that people might want to spend time rolling their own SMPS. I’ve actually done that, but I now want a more flexible way of including that “module” into a number of other designs. On that note I’m not sure where you draw the line with what a component/library/module is. I’ve used an LM5088 for my SMPS, and it’s got maybe 10 or so components around it. If a company took those components and put them into a package with three pins, (Vin, Vout and Gnd, a bit like a linear 7805) which I could place on my schematic like a 7805, would that be philosophically different?

Maybe it’s my SW background. Every time I create a new project which needs a linked list I don’t write a linked list from scratch. That would be a waste of effort and is not the focus of the new SW project. I’ve written one in the past and I’ll just reuse it. Likewise for my SMPS. I’m happy for people out there who want to rewrite a linked list for every project, as I’m happy for people to redesign a SMPS for every project. Everybody works different. Maybe I’m just lazy, or don’t get the same kick out of designing an SMPS.

And your point about Designators being important. Did I say that they weren’t important? I’m sorry if I gave that impression. I merely suggested that they be moved to a different file. So that rather then contaminating a hierarchical schematic sheet they be stored in a project specific file. I’m not saying that designators have to be different in every design, If you have two related designs and want to harmonise designators I’m not suggesting impacting that possibility.

I think I’m advocating flexibility here not trying to constrain how you work. On that last paragraph on how SW and HW are very different. You don’t have to tell me :wink:

On that note I recently watched an EEVBlog video [1] where Mr. Dave was doing a mailbag video in which he reviewed a USB Oscilloscope which somebody had sent him. Mr. Dave had a bit of a melt down when he saw the Eagle schematics for the product. It’s open hardware but the schematics, according to Mr Dave, were a Dog’s dinner, (bit of a mess) He (Mr. Dave) wondered about that fact and suggested that if this was an Open Source SW project somebody would have cleaned up the schematics in the file and issued a Pull Request back to the project. That does not appear to be the philosophy of Open Hardware. (Well that’s the impression I took from Mr. Dave). Maybe there’s a chicken and egg thingy where the tools don’t lend themselves to that philosophy because Hardware Engineers don’t practice that philosophy, or vice versa. Software tools are designed with collaboration in mind. They don’t have to be used in that manner. I’m sure there are a multitude of SW project which don’t use a collaborative philosophy at all. It’s not compulsory. But even if your doing your own personal SW project in isolation I’d still suggest Version Control be a good thing.

I’m going to try and take time this weekend to look at the code for Eeschema and ponder about how information is stored for a hierarchical schematic sheet. I’ll probably run away again but who knows.

[1] https://youtu.be/2Z3URu9vQBk (It’s at about 42:30)

30

I pushed a list of some commercial examples to the bug tracker some time ago:

What’s notable is that they do not only show graphic diffs but also textual ones to show people what has actually changed. This allows people to actually look into things which would otherwise not be easy to detect on a graphic diff.

3 Likes
31

I would also add that they (the commercial tools mentioned by pointhi) are also generally ‘tree’ like. i.e. they associate the change with a particular component on the design. e.g. If you alter R1, the diff interface generally identifies R1 as the source of the change and by progressive disclosure, the specific change to its position, rotation, footprint, thermal attachment etc. It doesn’t simply say

+++(pad "" smd rect (at 7 8 90) (size 0.5 0.5) (layers F.Cu F.Mask))
---(pad "" smd rect (at 7.5 8 90) (size 0.5 0.5) (layers F.Cu F.Mask))

Similarly, with changes to a track, it should be possible to view that in association with its attached net, not simply in isolation.

281×544 7.96 KB

32

I attempted to make the point that GIT submodules != to revision control in CAD software. There are similarities, they are not the same.

Yes there is a need for some means of moving parts of a schematic into a library. (I am actually more interested in doing this with PCB design, but that thats inconsequential). Forget about revision control for a moment and just think of how a schematic/board parts library could work. … then add revision control … to that workflow. I am putting it to you that revision control works different than GIT (or similar RCS systems).

I applaud your interest in this and the fact that you are going to spend this weekend (and perhaps many more :slight_smile: ) to look into the guts of KiCAD. My reply is just a friendly nudge towards starting from the UX (workflow) rather than existing tech that looks/feels similar (but isn’t).

2 Likes
33

I too would love to see GIT support integrated. It can save some manual steps. Even better if I could do a “diff” between revisions. I use other software packages with integrated version control and I’ve found it to be rather useful. Git would be especially nice because so many libraries and whatnot are hosted by GIT.

34

I have to strongly disagree about that assertion. Git is only a (clever) system for taking snapshot of a bunch of files. It is quite workflow agnostic. When using more complex workflows (team working), the default assumption is that the files are text based and can be merged on a line by line strategy.
But this default strategy can be replaced by whatever merging system you propose. This merging system is the responsibility of the application, which has the knowledge of the structure of the file. Using the default text strategy for Kicad yields not so bad results.

Now if you’d prefer to not develop a specialized tool for managing the merges on your specific file format, you can take the option of making this format and the behavior of your application more compatible with the default strategy. That can be simpler for the developer, but makes things more difficult for users in case of conflicts, because you force them to have a knowledge of the file format to correctly resolve them.

Adding a three-way merge driver for libraries would be a great step forward for better interaction with nearly all VCS.

35

Indeed, we’d need a dedicated merging tool, and a large part of the problem is that there is no way to format a schematic (two-dimensional) or PCB (three-dimensional) as a text file (one-dimensional) without imposing a purely artificial ordering to reduce the number of dimensions.

If you order PCBs by layer first, then X coordinate, then Y coordinate, moving a trace to another layer will give it a new position in the file. You could avoid that by sorting (X,Y,Layer), but then it gets a new position when it is moved, e.g. by the PNR router.

The best for automated merging with the fewest conflicts would be to give every element, not just components, a timestamp that uniquely identifies them over their lifetime, but that means that traces you delete and redraw get a new identity, and it also doesn’t work if the PNS router introduces a new bend into a trace and splits it in three.

A good diff/merge strategy would probably throw away all the information from the position in the file, or the coordinates, and instead generate a netlist, diff/merge the netlist by matching components and their pads, and then backtrack from there to the schematic or PCB.

This is a massive undertaking, and will require lots of new UI for conflict resolution.

3 Likes
36

So it sounds the best you could really do is make the ‘save a copy as’ into a little more automated feature? Disk space is cheap.

37

I agree even if it could not do merging. Atleast a trail of revisions and a way to flag what nets and components had changed between them. As routing traces/nets is cheap most times.

38

That is the exact point I attempted to make - but I guess my writing isn’t as self explanatory as I thought (grin)

39

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.