yorik wrote: ↑Tue Apr 20, 2021 10:52 am
In that light, storing a FreeCAD file as an unzipped folder is a start, it would address (very partially) problem 2) (I say partially because if you change a vertex of a brep file I think almost all the file is rewritten so very little gain there) but it doesn't really solve the issue.
What do you think about some "sparse", or maybe better: "lazy", variant of the file format: It stores only those brep-files which
cannot be regenerated by recalculating the model. This could shrink the file size at the expense of processing time when opening it.
When combining this with the idea of storing a FCStd as unzipped folder, we can take it further: brep files for shapes that
can be restored by recalculation could get a different naming scheme (e.g. "*.g.brp" or "*.generated.brep"). This would make it easy to .gitignore them, if desired. This gives you the best of both worlds: fast local opening and a reduced storage footprint for the VCS' history. And a less cluttered diff as by-product.
I agree that a textural diff on such an unzipped FreeCAD document is as meaningful as a diff on a SVG: depending on what has changed, and how careful the writer is at preserving the original DOM, the user experience may vary. And the user requires deeper understanding of the underlaying representation, for sure.
I think the role of a graphical diff tool (e.g.
what github offers for SVGs) would best be implemented in FreeCAD itself, independent of the VCS used for storage. Usually, an VCS allows to to configure different diff tools for different file types. I don't know how nicely this plays with unzipped documents (eg. whether you can configure git to use a hypothetical "freecad --diff $1 $2" on "*FDStd/"-
folders)
Let's not talk about merging, though
Here multi-file assemblies can mitigate the problem and for real collaborative editing
Ickbys prototype seems better suited.