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

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.
Received on Sat Oct 21 14:36:19 2006