Ben Collins-Sussman wrote:
> Proposed Changes:
>
> 1. In the filesystem model, create a 3rd node type called a "copy"
> node. (This is in addition to our "file" and "dir" nodes.)
>
> A copy node contains a pointer to a revision and a path.
Beautiful. Marvelous. I love it.
Not surprising, since I argued for something like that. :-)
> When we create node B as a "copy" of node A, we create a new
> copy node. This copy node allows us to discover the proper
> node-revision, but it also tracks the history of the copy.
And a successor of a "copy" node becomes a normal node of the correct
type, i.e., it's created as if it were the original's successor, but
with a different node number.
Does it make sense to differentiate between "file-copy" and "dir-copy"?
Probably not,
> 2. Remember that a copy command is really just an "add with
> history", and a move command is really just a "delete, followed
> by an add with history". Thus it's the *add* command, which,
> when given an ancestor path and revision, creates a copy node.
> (If there's no history given, then the add command creates a
> regular node.)
>
> For clarity sake, the history arguments to the editor's add()
> function should reflect this copying. Instead of
> "ancestor_path" and "ancestor_revision", we'd like to call the
> arguments "copyfrom_url" and "copyfrom_revision".
I'd like to discuss copy nodes with regard to directory copies and
branching. I'd like to see two things:
(a) Modifications to the copy live on the same branch as the original;
e.g., if we copy 53.7.11.2, and then modify the copy, we get 101.1.1.1,
not 101.1. I think that's important: that way the branch structure
within a node would be parallel to the branch structure of the whole
repository.
(b) Assuming directory copies are O(1), modifying an entry of a copied
directory should create a copy of the entry and a new node, not a
branch. In practice I guess that means modifying a copied directory
would mean first creating copies of all its entries. I don't think that
would be much of a problem, since copies are cheap.
Doing this would let clients show the tree of a node's revisions by
simply retrieving part of the index of the "nodes" table -- *and* that
tree would make sense to the user because it would have (a subset of)
the same branches as the repository itself.
Those of you who have used ClearCase will find the UI concept familiar.
Personally I find its version graph one of the most useful bits for
day-to-day work. Now I know that's not really a good argument for making
a design decison, but since we can get it (almost) for free ...
Yes, of /course/ I'll help to do the work. :-)
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:19 2006