Re: M-x big-picture

Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:

> a) All sorts of copies must be O(1)

That's the plan.

> b) A "svn copy" will do nothing but create a new "copy" node, which
> contains the copy source's node revision and path.

Right.

And, if the node that we copied is a directory, then the new "copy"
node *appears* to be a new directory too. If we never touch this copy
node ever again, we have ourselves the equivalent of a tag.

> c) Subsequent changes to a "copy" node will automagically create "file"
> or "dir" successors (on the ame branch), according to the type of the
> copy source.

Sure.

> O.K., that's all clear as long as the source is a file. If it's a
> directory, we actually want to copy the whole tree. So it seems to me
> that we have to create copies of its children when they change, but I've
> seen discussions about creating branches instead.

I think you're right. If, in my example above, somebody decides to
modify a child beneath the directory `copy' node, we need to start
making new node-revisions underneath. This *is* a branch.

The confusion here comes from user-interface land. When a client user
types `svn tag', what will happen? A new subdir copy-node will be
created somewhere in the filesystem. We talked about this behavior
last May, but never came to a full decision about how to best present
this model to the user. Do we let the user see new subdirs spring to
life, or do we somehow hide this? Do we structure the repository
filesystem so that all tag/branch subdirs are in one place? Lots of
open issues here.
Received on Sat Oct 21 14:36:20 2006