Re: [Gnu-arch-users] Re: the state of the union

[Tom Lord]

    > From: Mikhael Goikhman <address@hidden>

    > On 18 Aug 2004 09:47:40 -0700, Tom Lord wrote:

    > >     > They don't think this is a flaw, because one may implicitelly 
refer to
    > >     > the changeset in "svn merge".  I replied that, yes, explicit 
changesets
    > >     > are kind of redundant for strictly centralized non-distributed 
systems.

    > > Not really.  You want/need changesets as soon as you have branch and
    > > merge commands.  The goal of "Distribution" adds some constraints:
    > > e.g., changesets have to be "portable" between repositories --- but
    > > the need for changesets originates from branching and merging, not
    > > distribution.

    > This is exactly what I initially thought too, but then changed my mind.
    > With a centralized system you have always the whole history, so you may
    > implicitely refer to any changeset in the whole virtual world for any
    > "branching and merging". This is possible because you have no way to
    > create an out of the repository branch in a non-distributed system.

    > (The problem of explicit changesets (get-changeset, apply-changeset) is
    > orthogonal to the problem of accurate changesets (think inventory ids).)

If I give you a complete set of trees but no information about logical
file identities then you can not accurately compute changesets between
those trees (you'll have to make guesses about file identity).  With
just the trees, you'll have the same kinds of merging problems that
svn is, in fact, displaying (even though svn has *more* than just the
trees).

If I give you a complete set of tree, and those trees include
logical file identities, then, yes, you have a "dual" form of the
complete changeset history.

One branch of the common changeset format "debate" concerned the
desirability and wisdom of making a closed universe: revision control
systems in which you must have access to complete history in order to
use of changeset formats.   I can think of no virtues to making a
closed-universe system;  arch's open-universe approach is heavily
used;  people are already trying to build an open-universe system
out of svn (svk); .... the view that a closed-universe system is a
good thing is so absurd on the face of it that I have trouble seeing
why anyone would believe it.  (I didn't take you to be defending the
closed-universe view, though.)

Another branch of the debate, the one I think you are thinking of, is
whether or a per-tree history of the `svn mv' and `svn add' and `svn
del' operations that occured to that tree are a substitute for
user-managed logical file ids.

Those commands and their history are *close* but have a deep flaw: in
subversion, there is no formal notion of a project within a
repository: a repository is just "one big tree" and branching and
multiple projects in a repository exist only by convention.  The tree
rearrangement commands (e.g., `svn mv' and `svn copy') operate on
repositories, not trees.  Thus, a particular tree can have a fairly
twisted history of moves of files in from other branches, moves of
files out to other branches, and similar hair.  Thus, a history of
those commands records a development line for a single file in its
lifecycle through an entire repository, but that history says nothing
unambiguous about the logical identity of the file within a particular
branch's tree.   It's fine for a single-file merge operation: not for
a changeset application.

Consider, for example, an ancestor tree with one file.  You make a
branch and I make a branch.  We each make three copies of that one
file, each for a different purpose.   You make changes to your copies
and I want to merge them into my tree.   Which of your changes applies
to which of my files?

One can hack around that flaw by restricting either the
tree-rearrangement commands (like `copy') or by restricting the merge
commands (to just give warnings or take similar steps when confronted
with a confusing merge).

One natural form such restrictions might take is to only allow or
recognize histories in which, in effect, the moves and copies are such
that it is as if each file had a per-tree unique id.  (For svn,
"per-tree" might not mean a named development line like arch, it might
mean "whatever subtree of the repository is passed as an argument to a
merge command".)  Ok, that's fine, and there's a simple and direct way
to implement that which (a) makes it apparent, understandable, and
controlable by users (b) is space and time efficient and (c) enables
an "open universe" system in which changesets can be exchanged across
repository boundaries: inventory tags.


-t