Change #7: New filesystem "copy" nodes (and renaming add_*() args)

[Ben Collins-Sussman <su...@newton.collab.net>]

Change #7:  New filesystem "copy" nodes (and renaming add_*() args)

Status Quo:

   When we copy (or move) a node in the filesystem, we're currently
   losing information about where it came from.  Our "lazy cloning"
   model goes a long way, but in the end we get just a bunch of
   duplicated pointers to the same node revision numbers.

   E.g.: if a node A points to the same node revision that two others
   (B and C) point to, there's no way to know whether A was copied
   from B or C.

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.

       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.

   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".
   
Rationale:

   I think it's all been explained above.  Other folks, feel free to
   add to this explanation.

Re: Change #7: New filesystem "copy" nodes (and renaming add_*() args)

[Branko Čibej <br...@xbc.nu>]

I wrote:

> Does it make sense to differentiate between "file-copy" and 
> "dir-copy"?  Probably not,

... because it takes only one additional lookup to find the original 
node's type.



$&@#!, I should finally learn to review my posts before sending them.

-- 
Brane �ibej
    home:   <br...@xbc.nu>             http://www.xbc.nu/brane/
    work:   <br...@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <br...@acm.org>            http://www.acm.org/

Re: Change #7: New filesystem "copy" nodes (and renaming add_*() args)

[Branko Čibej <br...@xbc.nu>]

 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:   <br...@xbc.nu>             http://www.xbc.nu/brane/
    work:   <br...@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <br...@acm.org>            http://www.acm.org/