Revision control hindered - sheet numbers, data fields, netlist changes all the time

Hi,

I have a hierarchical project where the same sheets occur more than once (repeated input / output stages). On the face of it, everything is working OK.

What is irritating me though is that making simple edits often seems to cause the sheet numbering to change. The only reason this matters is that my project lives in a revision control system, and the sheet renumbering clutters up the diffs between revisions. For instance:

F 0 “R305” V 5800 3675 50 0000 C CNN
has just become
F 0 “R1305” V 5800 3675 50 0000 C CNN

when all I did was change the footprint of a component that’s not even on that sheet. I call that line out as an example - there are numerous similar changes.

I have a similar problem where changes such as this occur regularly for a reason I cannot fathom:

F 2 “” H 6838 4350 50 0000 C CNN
becomes
F 2 “” H 6838 4350 50 0001 C CNN

(0000 > 0001)

I’ll say again that at every stage everything is working, but I don’t understand these changes that occur, and thus how to avoid them. When any moderately complex change happens, it makes it pretty much impossible to review the changes before committing to them.

It also means that when you come back to a half finished edit and want to check what you changed, to make sure you didn’t accidentally include experimental changes, or accidental changes, that too is virtually impossible.

Finally the net list seems to change order at the drop of a hat, making that too impossible to diff.

All of these things mean that the advantages of being able to compare revisions are wiped out, at least for similar projects.

Has anyone got any tips for being able to make revision control history useful?

regards

Wilko

I should have added I’m on 4.0.4-stable.

Looks like re-annotation going over the sheets and changing things. Do you have this selected by any chance?

The F2 field is the footprint association.
Might depend on having opened CvPCB dialog or the Component Properties dialog in EEschema…

That’s a visibility flag, 0001 means hidden.

Generally, diffing files doesn’t work well for KiCad. I suspect it doesn’t work well for data files of any CAD program. A text diff works ok on source code, which is what source code control systems were designed for.

1 Like

Thanks for the replies.

@Joan_Sparky - yes, it seems I have that option set as per your picture - which I assume is “good”. In this context though, there is no more (intentional) annotation going on. Just a foot print association change.

On further investigation, the “sheet number” near the top of the file is not changing, but the component numbers do change to one of the similar sheets.

@bobc - visibility - that’s very weird then - I certainly wouldn’t expect visibility of anything to change.

The entire sequence was (very deliberately to make sure I wasn’t doing something else)

  • open project
  • open schematic
  • open cv2pcb from schematic editor
  • change one footprint
  • close everything, saying “yes” to save.

Why that should change the visibility of anything is interesting. Might have to go back and work out what it was out of curiosity.

However @bobc, I take your point regarding source; though it works reasonably well for many things that are not a programming language. This text is, after all, the source code for a schematic and layout.

No, it isn’t, it’s completely different. It’s a data representation which is normally manipulated by the graphical interface. Just because a file contains some text, doesn’t make it source code.

1 Like

From my perspective there’s a continuum from plain text prose to programming passing through markup languages and configuration-as-code where much of it can easily be argued to be not “programming” yet is still the thing from which the end product is built, and any team not making use of tools like revision control for something they depend on for their lively hood is, usually, missing out. There’s also a continuum from cli & vi programming through IDE’s and on to GUI’s that generate code and configuration - somewhere on that is Kicad. It would be nice if the there was some stability to what it wrote, which would increase the value of revision control as a tool to help avoid unintentional changes and mistakes. To my knowledge there is no other method of seeing what has changed; an equivalent of change tracking in traditional business document tools.

Our precise definitions of “source code” (which I happily accept we differ on) is an aside from simply wanting the ability to review what has changed, which is what I’m trying to achieve. And I still appreciate the input :slight_smile: