User:Suzanne.soy/Version control

• Forum topic: Storing FreeCAD files in a git repo
  • Research paper: Nonlinear Revision Control for Images (2011 SIG)
    • Summary: a GIMP plug-in which offers a history DAG, a visual diff, a merge tool, a replay tool.
    • From paper: it compresses steps (e.g. brush strokes) into a single DAG node, and use a "visual importance filter"
    • Idea: Similarity metrics based on distance, whether the user used pan & zoom and rotated the view, which object was touched (operations touching different objects are less similar)
    • Idea: let the user choose the metrics used to filter and group operations, and choose the weight / relative precedence of these metrics
    • Idea: allow expansion of the DAG nodes, just like one could expand the function call nodes in a [nodal interface]
    • Idea: non-parametric operations (e.g. changing a property) should use the same objects (or nodes in a [nodal interface]) as the equivalent parametric operation (translate, rotate, colourise… or a generic "change property" that takes a quoted node (as in LISP / Scheme quotes) and edits its properties (in a sense it's a macro, as opposed to functions which need the user to explicitly wrap their objects and decide on arguments and return values). In the history the transformation objects/nodes are stored as such, but are inlined so that the user works with the result without seeing the intermediate steps.
    • Idea: semantic conflicts are conflicts which cause a model or program to break, even though different lines of code or properties were touched. Instead of having a black & white conflict/no conflict, highlight parts of the model more strongly the more likely it is that there is a conflict (e.g. two operations may conflict if they touch the same property / touch properties in same group (X vs. Y, X vs. Angle) / touch adjacent vertices or edges or faces / touch the same object, touch objects in the same compound/fusion/part/file / touch objects in tightly-coupled files)
    • Idea: selection should be a parametric operation (e.g. select all filleted faces, except for the ones touching the top face: that's two selection/filter nodes in a chain)
    • Idea: soft lock (highlight or warn for future conflict) parts of the document which have been modified in other branches (real-time sync of history, detect conflicts with every branch at every step)
    • Idea: when the pending operation would cause a conflict with other branches, offer to merge now, or to do a "shadow merge" (as if there were three computers: person A on their computer, person B on their computer, a common computer, and each person was doing every operation both on their own computer and on the common computer; conflicts are detected on the common and can be resolved instantly, but each person normally work on their own copy which doesn't include the other's changes)
    • Idea: allow reorderings of operations and separating sequences of operations into parallel branches (so that similar operations can be clumped together), even if the reordering/split would normally cause conflicts. Draw smaller arrows to indicate the ordering dependencies (Hierarchical Edge Bundles: Visualization of Adjacency Relations in Hierarchical Data for really large graphs] for improved legibility). That way, operations which are semantically related can be clumped together for visualization, even if the actual ordering differs a bit. Manipulation (e.g. removing some changes or solving conflicts) should still be possible, if after the modifications the operations cannot be applied then it will be necessary to resolve the conflicts (highlight these in the small arrows or highlight the nodes with a different colour on hover so that it's clear they cannot be removed without causing conflicts), but a lot of operations can be performed on a temporarily-inconsistent DAG of operations if the DAG can be reordered before actually applying the operations.
    • Idea: branches in parallel are useful not only for versioning, but also for product lines (optional features). With the conflict-detection it is possible to highlight which features are incompatible, and even to record resolutions so that incompatible features can be merged by applying the resolution, this is akin to storing these "shadow merge" operations, and takes from the idea to allow reordering operations so that the desired groups can be enabled/disabled as a whole (internally, it's a boolean causing a bunch of operations to be individually applied or not, in the desired order).
    • Idea: use the "product lines" approach to auto-detect when some changes to a parametric model aren't compatible with some of the possible values for the input parameters (sweeping over the entire space requires some serious math, a starting approach would be to randomise values withing the allowed bounds).
• https://sourceforge.net/projects/komparator/
• Idea: custom diff operations (e.g. one might want to see which parts were moved w.r.t another version, without paying attention to small features like fillets which were added or removed, or the opposite; one might want to ignore scaling of shapes or other operations (filter those out and replay the graph before doing the diff, or at least place an = attribute on the shapes before and after e.g. scaling, and eliminate the parts of the diff which are only mentioning shapes marked as =))