Edit Rename Upload Download Back to Top

MC versioning algebra

in this syntax we're making up as we go....

Using a merge tool that can highlight conflicts they select 1 of many solutions to express two changesets as one:

and then apply and versions the resulting state: Note that the ancestry of D is now (C, Change.2).

To continue the example above: say

The system isn't going to go back to B to compute the necessary changes, since that's no longer the closest common ancestor: D is annotated with two ancestors C and Change.2.

So is one preferred over the other?

C is very slightly preferred over Change.2, but that preference rarely matters in practice. The "closest common ancestor" is determined by a min-max algorithm: taking both G and Change.3 as roots of an ancestry graph, consider the longest possible non-looping paths to each other shared ancestor in the graph, and pick the one with the shortest such path. The main reason for this algorithm is to ensure that if there's a relationship "X is an ancestor of Y", Y will always be considered closer than X.

So it will compute the changes between Change.2 and Change.3, and apply only those.

The ancestry of G' is (G, Change.3)

On the other hand, if someone else has an old image with only C loaded, and they apply Change.3, the system will compute the changes from B instead. That's what I mean by the start point changing depending on what you are applying the change to.


Edit Rename Upload Download Back to Top