[PaulGaspardo]

Oh, I used to work on this :)

For keeping track of power use and interfaces specifically it turns out doing it all with SysML diagrams wasn't so great. Aside from all the pointless futzing around with boxes and arrows the model eventually became so huge the authoring software could barely handle just opening it up. So it must have been shortly after these slides when all the power use tracking was shifted to a custom tool with a more tabular user interface that we were already using for tracking electrical interfaces (slide 15) with version control in git.

[crocal]

Unrelated question: how did you manage tabular data in git? It’s always a struggle to diff and merge changes.

[PaulGaspardo]

Yeah, like 'baq said the data wasn't stored in a tabular form, it was actually XML. So sometimes you could just look at the textual diff and it would make perfect sense, although it wasn't expected users would work with XML at the source level.

There was also a semantic object-level diff we got for "free" by virtue of building on top of the Eclipse Modeling Framework. It was integrated into the Eclipse git UI and could help resolve merge conflicts without having to touch the XML directly, but merge conflicts were still annoying to deal with so generally engineers coordinated with each other to not touch the same part of the model at the same time.

Normally for review though I think users tended to compare reports generated from the model rather than trying to diff the source model files directly. There was a sort of automated build process that took care of that once you pushed your branch to Github.

[baq]

not OP but the usual applies - data is not actually stored as a table in git, tables are an UI thing. git would store standard issue json, xml or whatever custom git-friendly format is used by the tool.