Within the database, Repository partitions each version graph into branches. Each branch contains object versions that are especially likely to share property values and target object versions with each other.
A branch of a version graph is a sequence S of n (n > 0) object versions such that:
S = x1, x2, x3, …, xn
and x1 is the creation predecessor of x2
and xk is the creation predecessor of xk+1 (1 < k < n-2 )
and xn-1 is the creation predecessor of xn.
According to this definition, each object version can be in the same branch with at most one of its creation successors. For example, in the following version graph, Version 3 and Version 4 cannot be in the same branch, because they are both creation successors of Version 2.
In fact, this version graph has four branches, as shown in the following figure.
Every version graph has at least one branch — the branch beginning with the first version of the object.
Each object version is a member of exactly one branch; branches do not overlap.
When you create a new version of an object, Repository tries to add the newly created version to the same branch as its predecessor. If that branch already includes a successor to the creation version, however, Repository creates a new branch. The newly created object version is the only element of the new branch.
For example, if you create a new version from Version 8, Repository creates the new version and adds it to the branch containing Version 8. But if you create a new version from Version 3, Repository creates a new branch for the new version, because Version 3's branch already includes a creation successor of Version 3.
Each branch represents a set of object versions that are especially likely to share property values and have identical relationships. If two object versions exist on separate branches, Repository does not save any space in the database even if those versions share values for all of their properties and have identical collections for all of their collection types. For Repository to save space, the similar objects must exist on the same branch. For this reason, Repository tries during CreateVersion to assign the new version to an existing branch. The fewer the branches, the higher the likelihood that Repository can save space in the database.
Repository never moves an object version from one branch to another. After Repository assigns an object version to a branch during the CreateVersion method, that object version remains on that branch until the object version is deleted.