Add file versioning and change history to QET projects

[ispyisail]

Problem: Once you save a diagram, there's no way from inside QElectroTech to see what changed, go back to how it was ten saves ago, or tell who on the team made an edit. Git can do this — .qet files are plain XML, and #754 made saves reproducible so diffs are clean — but it means knowing Git, installing it, and thinking in commits. That's a big ask for someone who just wants their drawing back the way it was this morning.

Proposal: Store a compressed snapshot of each saved diagram alongside the project, with the date and who saved it. Show a version history browser in QElectroTech where you can:

• See who saved each version and when
• View what changed between versions (wires added or removed, elements moved, properties edited)
• Go back to an older version in one click
• Optionally add a note when saving ("fixed wire routing", "ready for review")

Example: Halfway through a job you realise something went wrong three saves ago. Instead of undoing and redoing by hand, you open the version list, pick the version from this morning, and you're back. What you had before that is kept too, so nothing is lost.

Trade-off: disk space, plus another dialog to maintain. Measured on the 24 example projects that ship with QElectroTech, a compressed snapshot is 6–9% of the project file for most of them, and about half the file size for projects with embedded images. So a 2 MB project costs roughly 150 KB per save, or around 1 MB if it's image-heavy.

Questions:

1. Would you use this — for your own work, for team review, or not at all?
2. Snapshot automatically on every save, or only when you ask for one?
3. Is the disk cost a problem for the way you work?

[arummler]

"Last saved by" is easy, cheap and should not have any side effects. I would be hesitant to add non-optional (ie with opt out option) snapshots in the xml file. Just some thoughts:

• The main issue is the "View what changed between versions" which is true for all complex files whatever the implementation. Just building a "git diff module" would pose the same challenge. Software like CAD programs, drawing programs, LABVIEW, etc. rarely implement a persistent history for that reason. Stressing that this is not impossible and certainly useful - but really hard.
• The advantage of working within the program is that one could implement a persistent undo list. Issues with that is that one would need serialization of undo operations which is not implemented at all. And worse: handling of evolving data structures across program versions becomes impossible to manage.
• If one just looks at XML it is to a certain extend just re-implementing git like you mentioned. One could also implement an optional git interface menu as many similar programs do (under "File" a versioning sub menu). This could be either directory based or "packaged" in a file.
• One idea I wanted to bring up in another discussion is an alternative file format related to the issue of embedding binaries like pictures which require base64 encoding which blows up the file size. Modern approach like with Libreoffice and KICAD is to define basically a zipped .qetz which contains the XML and adjacent binaries. That could also support versioning in snapshot form; avoiding having to load big XMLs.
• Another idea I wanted to bring up at some point is intergations with PLM software - in that case the that software takes over versioning and one should have again an opt-out of snapshotting.

TLDR: not against it but different options and future extensions should be considered resulting in at least it being optional to avoid boxing us in.

[scorpio810]

One idea I wanted to bring up in another discussion is an alternative file format related to the issue of embedding binaries like pictures which require base64 encoding which blows up the file size. Modern approach like with Libreoffice and KICAD is to define basically a zipped .qetz which contains the XML and adjacent binaries. That could also support versioning in snapshot form; avoiding having to load big XMLs.

I"m very ok for that see Joshua note for https://qelectrotech.org/wiki_new/refonte_du_code_de_qelectrotech
Storing large images, as well as repeatedly encoding and decoding them in Base64 format, places a heavy load on the processor and takes a long time when managing and processing large-scale projects. Navigating through a large project can cause significant slowdowns.