> The difference between svn and a true changeset system is
> that we store the trees as first-class objects, and the
> changesets are derived. If I understand correctly, a pure
> changeset system stores the *changesets* (i.e. patches) as
> first-class objects, and the trees are derived artifacts that
> come from mixing and matching them.
I've found a different way to look at it to be helpful.
In all (whole tree) systems, you have a graph of trees, where nodes
are tree states, and edges come in various flavors.
Each commit typically adds two new edges:
1) a "physical ancestor" edge to the tree who's delta to
the new revision most accurately represents the set of
physical changes the programmer intends to record as the
definitive representation of the changes being committed --
the "deliberate changeset" edges.
2) a "logical ancestor" edge to the immediately preceding tree
in a line of development -- the most accurate
representation of where the programmer intends the changes
to fit into a development history. The "workflow" edges.
With fancy history sensitivity, additional edge types may come up as
well (e.g. the "merge history" edges).
It isn't crystal clear to me how the physical and logical edges are
stored in svn. My vague understanding is that physical links are
implicity stored in your server-side revision histories, and that the
logical links are stored in the file system namespace, according to
whatever naming policies users happen to adopt.
How the trees, edges, and changesets are _stored_ is immaterial at
this level of abstraction -- that's just trading off between various
representations of the same graph. How they are named and available
for manipulation is not immaterial:
You can (of course) store trees, trees with delta-compressed files,
patch sets, or any mixture of these. Different mixtures of these
representations have usefully different performance and complexity
implications, but the different representations don't change the
logical relationships among the various entities.
What I think differentiates changeset-centric systems are the features
for manipulating deltas in semantically useful ways. Such features
depend on the graph described above, the "other edges" (the fancy
history data), and on good features for intelligent patch
manipulation. Giving handy names to features of the graph is a big
part of this, as nearly as I can tell.
The little boilerplate definition I posted a while back tries to
describe all that:
WHAT IS REVISION CONTROL?
It is the role of revision control systems to provide two broad
classes of functionality:
A) The cataloging and archival of unitary changes made
(primarily) to software and documentation source code,
deliberately and explicitly, by contributors to that code.
B) The quasi-algebraic manipulation of unitary changes to form
useful combinations of changes; the combination and
coordination of work made by single or multiple
contributors acting across space and time.
If you want to say that svn is not "a true changeset system", I think
the reason would have to do with the not-done-yet history sensitivity
features and corresponding delta-patch/merge operators --- not because
of the storage manager's general representation strategy.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 8 22:23:59 2002