Tom Lord wrote:
> > 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.
>
If I understand what you mean here, Subversion doesn't distinguish
between "physical" and "logical" ancestry. But I'm not sure i _do_
understand the difference.
And we don't record anything else right now, not even simple merge
history. Unfortunarely.
>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 mean, it _is_ immeterial, judgung by what you said below. :-)
>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.
>
Ah! I finally understand what you're getting at WRT patch formats! It
becomes clear now that you've put it in context. I never could
understand why you thought that desigining a general patch format could
be the first step -- now I understand that you assume that a patch would
include _all_ history metadata, not just "copies, moves and context diffs".
Of course, the problem still remains that you have to have a pretty
complete, generic revision management model upon which to base the patch
format -- including methods for gracefully downgrading or simulating
missing features of the target system. Which is probably 99% of the work
in the first place. :-)
>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.
>
That's one of the more beautiful definitions I've seen to date.
>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.
>
>
Exactly. Of course, that doesn't mean tnat adding
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 9 23:48:35 2002