Git-based Collaboration - conflicting fields (UUID, version) after every save

Hi, please is there any recommended best practice for git-based collaboration of multiple developers on one kicad(6) project? Upon every save operation Kicad generates new sheet UUID in the .kicad_pro file and references it in the .kicad_sch file. That in principle leads to conflicts in every git pull --merge or --rebase if another developers makes any change meanwhile, even a tiny one (e.g. changing a resistor value). Please is there any way to solve this? Can perhaps the UUID versioning be disabled in the project, or something like that?

Thanks a lot for any help.

First make sure you all have the latest 5.99 nightly build and keep it up to date. (There’s no KiCad 6 or files for KiCad 6, only 5.99 at the moment.)

Yeah, the exact kicad version is stored in the files too, so all developers have to use the very same version too, and update the 5.99 nightly releases synchronously.

E.g.

(kicad_sch (version 20210621) (generator eeschema)

(uuid bbd8e6c2-7dd6-467f-b668-29e6414f55fc)

But that will not help as the next line has the UUID which changes with every saved change.

I understand it may be a difficult issue now but perhaps some solution could be considered in the long run. Collaborating on git projects is not an unusual situation.

Please report an issue for this so that someone can follow up on it. The UUIDs are not supposed to change on every save (the generator version is supposed to change whenever we change the file format, so it is important that your team always use the same version of the nightly)

Thanks a lot. I checked the sheet UUID with same version and I apologize for lack of testing, the UUID does not change when storing a change of resistor value, only the resistor part of the file gets changed. Such change could be merged without conflicts.

I tried dragging a connected resistor just a bit to check the difference in the stored schematics file. The connecting wire ended up listed in a different order among the wires, the same for the resistor symbol. Both sections had only the wire/symbol co-ordinates changed, the rest was identical, including their UUIDs. Perhaps if the respective blocks (wires, symbols) used some fixed sort order (e.g. their UUIDs which did not change), the overall changes could be minimized, again allowing merges of small schematics changes. Do you think it would make sense to open a discussion about something like this with the kicad developers now? Thanks a lot.

I am certain that developers are aware of this. There have been efforts to reduce diff noise in schematics and layout files.

But in the end diffing graphics is not trivial. If you search this forum, you should find a lot of debates on this topic.

From what I’ve found is that schematics is quite malleable for team work. In my/our workflow the root schematics consists of links to hierarchical sub-pages and then different people work on different subpages. Thus you avoid diffs/merges.

As for the layout it really comes down to constraints. If you don’t have hard constraints on the area then you can also layout each hierarchical page, and save the layout via Save/restore layout action plugin. The merge is done manually via the same plugin.

Tools for cooperation? is quite comprehensive. Diffing is not the problem; merging is.

2 Likes

Thanks for your replies.

I am well aware that merging complex graphical changes to a text description file is basically impossible. What I meant are simple changes - e.g. moving a component without creating new wires.

IIUC the current internal representation of the schematic uses a spatial-aware RTree which orders items based on locations of their bounding box corners https://github.com/KiCad/kicad-source-mirror/blob/master/eeschema/sch_rtree.h#L58 . When storing to a file, the tree is traversed, items sorted by their ‘<’ operator, and stored in the order of the sort https://github.com/KiCad/kicad-source-mirror/blob/master/eeschema/sch_plugins/kicad/sch_sexpr_plugin.cpp#L632

1 Like

I had to split my post to 2 pieces due to the max. allowed links limit for new users.

E.g. the wire (SCH_LINE_T) bases its ‘<’ operator on its spacial position https://github.com/KiCad/kicad-source-mirror/blob/master/eeschema/sch_line.cpp#L757 . This explains why a tiny drag of a component changes order of the wires in the stored file of a complex schematic.

I assume when loading the stored file the items are inserted into the rtree again by their spacial position (using the above linked method rtree.insert(x, y, item)), therefore the actual order of items in the file may not be critical. Maybe if the items were ordered by their fixed UUID and not the variable position when being stored to the file, small changes would not reshuffle the items and the resultant format could be more friendly to merging.

But I would be surprised if such approach were not discussed many times before.

Best regards,

Pavel.

1 Like

The official justification is that items are ordered by position on purpose in order to simplify collaborative editing noise. It isolates a person’s changes to a section of file rather than the entire file.

1 Like

That does make a lot of sense, thanks for the explanation.

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