Interval Construction within Partially Ordered Object Versions

Revisions of objects (or files, respectively) have always been managed by using labels attached to the revisions. Yet, typical version managers assume that the revisions are ordered totally or at least in a tree-like order. The ordering of labels reflects the semantical dependencies of revisions of a single object, therefore the labels should be able to represent a revision R inheriting properties from multiple predecessor revisions. Multiple preceding revisions typically reflect concurrent development of updates. Total orders and trees are not useful for version labels, because they do not allow for multiple preceding revisions, at least they do not describe multiple predecessors. Thus, it is our belief that there should only be a single restriction to the ordering of versions: