Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> I have a big question mark about this sitting somewhere around my
> hypothalamus. I suspect I really don't understand our copy-is-branch
> model, even with the proposed changes to create a "copy" node type in
> the filesystem. I'm especially muddled about directory copies. I'd like
> to clear things up. Here's what I think I understand:
>
> a) All sorts of copies must be O(1)
>
> b) A "svn copy" will do nothing but create a new "copy" node, which
> contains the copy source's node revision and path.
Nope. An "svn copy" does nothing but create a new directory entry
referring to the same node revision as the original. (In Chicago, we
did discuss the possibility of adding "copy nodes" to get certain
things right, but I want to leave that out of the picture for now, and
get the simpler worldview working. Things work fine without them.)
When you want to commit a change to the copy, the change creates
successors (in the node revision sense) of each node that is changed,
and to their parent directories, parents' parents, etc. and makes the
changes to the successors. Eventually this results in a successor to
the root node, which we install as the root of the new revision.
Since the original of the copy refers to the same node revision it
used to, not the successor, the original is unaffected.
Don't assign any significance to node revision numbers, other than the
successor/ancestor relationship. The only reason we can't just use
simple linear numbering is that we need the ability to create an
arbitrary number of successors to any given node revision, and we want
the node revision numbers to encode that successor/ancestor
relationship. But there is no sense in which 10.3 is a "more
distinguished" successor to 10.2 than 10.2.1.1. Neither is
necessarily the branch, nor the trunk. Whoever needs a successor to
10.2 first gets 10.3; everyone after than gets 10.2.n.1, with
increasing n.
Received on Sat Oct 21 14:36:21 2006