Logical Data Model


  1. diagrams are yet to follow
  2. many aspects are not modelled correctly and will change to whatever further discussion will suggest


Repository. In this context, a mere container for revisions. There may be more than one repository and merge tracking shall work across repository boundaries. Attributes: ID (may or may not be its UUID)

Revision. A (possibly empty) set of atomic changes. They are unalterable and identified by their number within the repository. Per repository, revisions form a single, contiguous line of history. Attributes: Revnum.

Atomic Change. The smallest tracable entity of change and associated to exactly one revision. The list of atomic changes can be modified by the user. Due guarantee referential integrity, there is no way to delete an atomic change. Attributes: ID (relative to revision), change type, path, node type, optional: copyfrom path + rev

Change types:

Changes are strictly ordered within a revision. This is necessary since removals, copies and renames may replace the same path with different nodes and that may happen multiple times per revision. Q: Normalize lists, e.g. tree mods first followed by a max 1 contents change?

Merged Change. A refence to an atomic change. The list of merged changes is a sub-element of an atomic change. That list may be empty if there have been no merges in this revision for that path. As a convention, we only record the changes immediately merged, i.e. those pertaining to the merge source instead of all changes along the merge hierarchy.


Notes from Discussions

Internal Data Model

Notes from Discussions

External Data Model

Notes from Discussions