Navigating Versioned Version Trees

While version trees usually serve as a data structure to organize different versions of a code repository or workflows, we are not restricted from applying operations to the tree itself. When we create a new version, we create a new node in the version tree and attach it to the parent version with edge. The actions of adding a new node and edge are mutations to the version tree. Usually, these are the only actions; the version tree is monotonic and no versions are deleted or moved. In version control systems, even when we merge two versions, the effect the creation of a new node. However, there are times, especially when we want a change to affect multiple versions, that editing the version tree may be more efficient then creating new versions for each of the affected entities. For example, if we introduced a bug in a commit that is included in multiple branches, it would be nice to fix that bug in the original commit and propagate it to all of the other branches. Or, if we wish to upgrade a specific module used multiple workflows to use a new algorithm, it would be nice to replace the action where that module was added rather than create a new workflow (and version) for each workflow.