Two different worldviews of version control systems
I've come to think that there are two broad ways of viewing the world that are used by most common version control systems. Although the end result can be the same, these worldviews lead to different places and can give people different attitudes, and I happen to think that one is a better representation of reality than the other.
In the first worldview, the version control system manages snapshots of a tree. When you make a new snapshot, you generally provide a freeform textual description of how it relates to one or more existing snapshots. Naturally, the VCS provides a variety of convenient tools for creating a new tree state from existing snapshots, but these are in a deep sense just chrome; the VCS's core view is mostly indifferent to how a tree state comes to be. Git is the classical and practically canonical example of this worldview.
(This worldview expresses an abstract situation. The actual underlying storage of trees may use various forms of deltas.)
In the second worldview, the version control system manages a series of changes from an initial state. Additional states are at least conceptually reconstructed by replaying the changes. The VCS usually tries to be aware of specific semantic changes, like renaming files, and new changes can be created through VCS operations in addition to by manually editing files. VCSes of this nature usually consider it important to capture the intent of tree changes (hence their explicit support for file renaming) and sometimes talk about a patch algebra, which can be badly summarized as a formalization of logic around series of changes ('patches').
(As with the other VCS worldview, the underlying storage format is not necessarily a series of changes from an initial state.)
Both worldviews work, in the sense that they can create the same set of tree states in the same order, with the same textual description of each step forward (ie, each commit message). But my view is that the change worldview is fundamentally a pretense because we can't truly describe changes properly. Our primary tool for describing most changes is the text diff, but that's merely the implementation of a change, not the change itself. We can describe the change in the commit message, but again that's not the change itself.
The snapshot worldview is honest about what the version control system can really provide and what it can't. The VCS can provide snapshots, and it can generate text diffs and other analysis of the difference between two snapshots. But it doesn't claim to capture changes themselves, only their consequences in the circumstances they were made.
PS: The snapshot worldview doesn't preclude an idea of (named) 'branches', because branches can exist at the level of commits. A commit is one sort of metadata about the relationship of a snapshot with other snapshots, and this can include things such as 'this was made on branch X' if the VCS wants it to.
(And even if the VCS doesn't include it, people writing commit messages can.)
Comments on this page:
|
|