Re: [Gnu-arch-users] Ongoing Comparison Between Version Control Systems

[Tom Lord]

    > From: Jonas Diemer <address@hidden>

    > On Sun, 7 Sep 2003 16:39:37 +0100
    > Andrew Suffield <address@hidden> wrote:

    > > "File and Directories Copies"

    > > Arch doesn't do this because it's considered a bad idea. Trying to
    > > merge across a one-to-many copy of this form would be insanely
    > > complicated.

    > Can't arch's tag command be used to do something similar?


You're both right.

Arch's tags do cheap tree copies but don't let you copy, say, an
arbitrary subtree of some project to form a new project.

To copy an arbitrary subtree like that, you'd want to do two steps in
arch: tag the original tree, then commit a revision against the copy
that deletes the stuff you don't want, and moves the subtree to the
top level.

In Subversion, the namespace doesn't contain (other than by
convention) any special names for particular project trees.   There's
no low-level difference between a directory which is the root of a
project tree, and a directory which is a subtree in a project tree.

Consequently, to do a subtree copy to make a new project in svn, you
can use just one step instead of two.

I think that what Andrew is pointing out is that given the tree-copy
semantics of svn, and the overloading of the copy operation to mean
each of branch, tag, and duplicate, the notion of logical file
identity (inventory tags in arch) becomes highly problematic in svn.
One consequence of the resulting hair is that it isn't at all obvious
how "smart merging" features can be usefully defined.

-t