Version Control Support in FreeCAD

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
timmwille
Posts: 17
Joined: Sat Jan 23, 2021 12:41 am

Re: Version Control Support in FreeCAD

Post by timmwille »

realthunder wrote: Fri Mar 19, 2021 3:38 am I plan to create some simply external module for version control using git as a demo.
this would be great. I think I also saw the other approach mentioned above but in any chance, can someone point me to the exact source code references? I know my way just enough through code to understand it.


A Colleague from us at Open Source Ecology Germany also tried an interesting approach a some months back might be of help with this?
https://github.com/hoijui/ReZipDoc
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Version Control Support in FreeCAD

Post by Zolko »

timmwille wrote: Fri Apr 09, 2021 11:52 pm A Colleague from us at Open Source Ecology Germany also tried an interesting approach a some months back might be of help with this?
https://github.com/hoijui/ReZipDoc
I think I disagree with the premises of this problem, for several reasons:

1) yes, FreeCAD files are zipped text files, but they're not sequential source files where you can do a useful diff on. You probably can do it on the XML files, but not the BREP files.

2) I would completely distrust to give my important project to a unzip-diff-rezip action, and I think that any project would rather increase the storage size of a repo than try to optimize some minor gain, that you'll loose at the first occasion (because ***** happens, Murphy is your friend).

3) the *real* problem I see is that FreeCAD files are marked as changed even if the user only changed some visibility state, or even if the user only recalculated it: this means that a huge assembly will be marked as 100% changed even if you modify a single small file down the hierarchy. One solution would be to open files as read-only, or even entire assemblies, and only files that are explicitly tagged by the user should be saved.

4) FreeCAD doesn't respect the file-systems read-only permissions: even if one opens a read-only file, FreeCAD changes its attribute and saves the changes.

All-in-all, as a conclusion, I don't think that trying to integrate a git-based version control system is going to solve anything, because the problem lies elsewhere.
try the Assembly4 workbench for FreCAD — tutorials here and here
timmwille
Posts: 17
Joined: Sat Jan 23, 2021 12:41 am

Re: Version Control Support in FreeCAD

Post by timmwille »

Zolko wrote: Sat Apr 10, 2021 12:40 pm
timmwille wrote: Fri Apr 09, 2021 11:52 pm A Colleague from us at Open Source Ecology Germany also tried an interesting approach a some months back might be of help with this?
https://github.com/hoijui/ReZipDoc
3) the *real* problem I see is that FreeCAD files are marked as changed even if the user only changed some visibility state, or even if the user only recalculated it: this means that a huge assembly will be marked as 100% changed even if you modify a single small file down the hierarchy. One solution would be to open files as read-only, or even entire assemblies, and only files that are explicitly tagged by the user should be saved.

4) FreeCAD doesn't respect the file-systems read-only permissions: even if one opens a read-only file, FreeCAD changes its attribute and saves the changes.

All-in-all, as a conclusion, I don't think that trying to integrate a git-based version control system is going to solve anything, because the problem lies elsewhere.
I agree, this is why we could not implement it yet and it is considered a nice draft that works with other zip contexts but still is not a working or even final solution. So it also needs the combination of understanding CAD and Code and the workflow of both. So yes, the issue is real and very interesting. I would love to try any approach regarding this :)

What else would be needed to help with the general development of this feature? I can try finding the resources, people, connections as I have a good network but I'm not a software dev myself. Simple but passionate FreeCAD user though and I bet the Open Source Hardware community is full of support regarding this :)
user1234
Veteran
Posts: 3345
Joined: Mon Jul 11, 2016 5:08 pm

Re: Version Control Support in FreeCAD

Post by user1234 »

Hello!

Just said, that normally in the construction world the version control are made via revisions (or baselines) per hand. They are also often marked on the drawings. Often when you want a specific state for people like costumers, colleague, supplier , ...... or milestones, calculations states, loop states, ..... . All suggestions of a continuous version control i have seen in this way failed. A continuous version control like git is for CAD unworkable.

https://en.wikipedia.org/wiki/Revision_ ... s_and_tags

Greetings
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Version Control Support in FreeCAD

Post by ickby »

Personally I think the version control as done for code like git is not feasable for CAD data, and never will be (or only with massive investment into research). The problem is concurrent independent manipulation of a shared origin state and later unifying those modifications back to a shared state which fails. My personal solution would be to limit the scope a bit and remove the "independent" from the last sentence. Than the problem becomes easier: concurrent manipulation of a origin state into a new shared state. With this you can easily implement versions of parts in the document itself, or even of the whole document, as than all they are are "tags" to a certain shared state. But you never need to merge things back together, hence do not have the issue of unmmergable parallel modifications. For this I started coding some experimental workbench, which later can be extended to iinclude the versioning and online sharing (way to go of course): https://forum.freecadweb.org/viewtopic.php?f=8&t=57028

Of course with this there are drawbacks, like the requirement to stay always online while manipulating the shared document.
lambda
Posts: 91
Joined: Sat Feb 25, 2017 3:10 pm
Contact:

Re: Version Control Support in FreeCAD

Post by lambda »

Two ideas, because I'm thinking about this from time to time and somebody is resurrecting this issue:
1) I'd recommend to base CAD revision control onto the semantics of darcs instead of git. This would be much more natural for the problem at hand. Though you might need to fix topological naming first, to implement darcs semantics. (Or was it the other way: Implementing darcs semantis automatically would fix TN?)
2) Some FreeCAD objects (at least anything from Arch IIRC) have a GUID. Any CAD revision control should use GUIDs instead of line numbers. Maybe you should GUIDify anything, you want under version control.

I hope, at least the second point is obvious once you think about it.

I have no idea, how to handle BRep data (if it isn't generated from a fully parametric model). It seems, this doesn't have any history pretty much per definition, so maybe there just is nothing to record.

Having version control even for a limited subset of FreeCAD would be awesome.
sww1235
Posts: 32
Joined: Thu Mar 21, 2019 5:12 pm

Re: Version Control Support in FreeCAD

Post by sww1235 »

I can see 2 separate issues here that can be resolved separately.

One: display of version control status similar to an ide. Showing which files are checked in to a version control system, ignored, modified, etc. Also showing things like branch name and a system to add/check in files and push from the UI.
Ideally this would be implemented in a generic way to allow use of multiple version control systems without having to add support for each individually. Maybe some kind of plugin system.

Two: making freecad files easier to support in a version control system. One way to do this (which I would love to see implemented anyways) is to provide a way to save fcstd files without zipping them.

I am currently using a git hook to unzip the fcstd files before commit, and it has at least resolved the issues with git detecting massive binary file changes.

I think providing these two things will go a long way to helping users who want to use existing vc systems with freecad.

A third issue is identifying a better version control system for cad and freecad in general, maybe some first party support for collaboration etc, but that should probably be its own thread
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Version Control Support in FreeCAD

Post by yorik »

I also see 2 problems here:

1) It's hard to see a real, meaningful difference between two files. ie: WHAT has changed between version 31 and version 32?
2) FreeCAD files are treated by almost all VS systems as fat binary files, meaning the repo size inflates quickly over time.

Most VS systems especially for code have a very clear way (both for humans and machines) to identify what has changed in a file. So this solves both problems at once, 1) you as a human have a clear view of what has changed and 2) only the changes need to be stored, not the whole file over again.

So basically the problem would be to have a kind of diff tool for FreeCAD files that could 1) give output that is meaningful to users and 2) that output would also precisely identify what needs to be done by a machine with file 31 to make it become file 32. I don't know if those two operations absolutely need to be one same tool, though. I believe they could be two distinct operations/tools

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.
sanderobdeijn
Posts: 1
Joined: Wed Mar 10, 2021 8:11 am

Re: Version Control Support in FreeCAD

Post by sanderobdeijn »

Regarding the brep files in the context of version control. Do you need to store them in version control. My understanding is they are generated from the Document.xml.
So when comparing it to code version control you could compare them to compiled binaries that you don't store in version control.
But when opening the project you generate the brep if this isn't done before.
This will probably require somehow knowing if the brep files need updating.
User avatar
jonasb
Posts: 162
Joined: Tue Dec 22, 2020 7:57 pm

Re: Version Control Support in FreeCAD

Post by jonasb »

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.
Post Reply