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, whether the modification touches
    • 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: 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: conflicts (touches same property / touches property in same group (X vs. Y, X vs. Angle) / touches adjacent vertex or edge or face / touches same object
    • 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
    • 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).
• https://sourceforge.net/projects/komparator/