Version Control temp
DotDocs must be capable of tracking changes in an assembly over time (i.e., through different versions).
This approach involves separating the identity from the state as throughout all versions the identity remains constant whereas the state changes.
Version tracking will be implemented using an approach I found while researching this blog by Bert Radke describing how relationships with a from and to property can be used to version track a node as follows:
Specifically, this behavior is similar of that of a DoublyLinkedList where each element points to the next and previous element. Each from property is inclusive, meaning the related state node defines that version. Each to property is exclusive meaning it defines up to, but not including it's referenced version.
However, this approach results in a situation where we do not have a central collection of all versions present for a given assembly. Therefore, we would need to aggregate all from and to properties and pull out all distinct versions. What if we added a other property to the relationships between a identity node and state node to hold versions higher than the from and less than the to?
This approach may seem like a fix, however, it doesn't actually fix the problem. We now have duplication of version values in the other property as the number of relationships grow. Therefore, what is a better alternative?
In this approach we have located the other property inside the identity node as versions to act similarly to a single source of truth. With this setup, versions will only be located in the assembly's identity node and will contain all versions provided for the given assembly. To retrieve all versions for the assembly, one can simply return the array of versions in the identity node. Moreover, to track which assemblies have already been added, we can simply refer to the same versions collection to see if the incoming value matches an existing.
As shown above, the addition of other versions into the system results in the neighboring version nodes requiring updates just like a DoublyLinkedList.
Every relationship between a identity node and state node will contain a from property which will initially be set to the version used to create that relationship.
- We cannot have two different definitions provided for a single version.
- The
toproperty does not exist on the last node in a sequence.
Node Id:2 = [1.0.0, 1.0.5)
Node Id:4 = [1.0.5, 1.1.3)
Node Id:3 = [1.1.3]
But what if:
Node Id:2 = [1.0.0, 1.0.5)
Node Id:4 = [1.0.5, 1.1.0) <-- Here 1.1.3 to 1.1.0
Node Id:3 = [1.1.3]
In this modified instance of the above example, we have changed node id:4 to have a to value of 1.1.0 instead of 1.1.3, therefore, there is a gap in the version timeline between node id:4 and id:3. The system will be designed to stretch from a from version to that of the next from version to prevent this gap. Adding versions later that fall within a stretched region will use value comparisons to determine if the current definition accurately describes the incoming definition. If it does, continue using the existing definition and add the incoming version to a list of already checked versions (i.e., this could be used to prevent redundant comparisons if my system was different).
Below is an example of how a property and it's methods would be tracked:
The same idea would apply for fields, methods, and events where they have their identity node and corresponding state node.
Should identity nodes only be referenced by the corresponding state nodes as a means to linked them together as they change over time. Therefore, state nodes are to references by other state nodes to preserve which versions are associated together.