Re: What `cloning' means

[Karl Fogel <kf...@galois.collab.net>]

Jim Blandy <ji...@zwingli.cygnus.com> writes:

> Here's a comment from editor.c:
> 
>   /* What don't we do?
>    * 
>    * What we don't do is start a single Berkeley DB transaction here,
>    * keep it open throughout the entire edit, and then call
>    * txn_commit() inside close_edit().  That would result in writers
>    * interfering with writers unnecessarily.
>    * 
>    * Instead, we take small steps.  When we clone the root node, it
>    * actually gets a new node -- a mutable one -- in the nodes table.
>    * If we clone the next dir down, it gets a new node then too.  When
>    * it's time to commit, we'll walk those nodes (it doesn't matter in
>    * what order), looking for irreconcilable conflicts but otherwise
>    * merging changes from immutable dir nodes into our mutable ones.
>    *
>    * When our private tree is all in order, we lock a revision and
>    * walk again, making sure the final merge states are sane.  Then we
>    * mark them all as immutable and hook in the new root.
>    */
> 
> The middle paragraph uses the verb `to clone' in a way that's somewhat
> inconsistent with the rest of the filesystem.  To clone a node
> revision is to create an immediate successor to that node revision,
> whose contents are initially the same, but will probably be changed.
> Cloning always takes place in the context of some transaction.
> 
> So you don't need to say that "If we clone a dir, it gets a new node."
> "Cloning" intrinsically means "making a new node."

I think it's more redundant than inconsistent, but agree it could be
clearer.  I like your proposed wording better, will switch to it.

-K


> I'd write that middle paragraph as:
> 
>    * Instead, we take small steps.  As the driver calls editing
>    * functions to build the new tree from the old one, we clone each
>    * node that is changed, using a separate Berkeley DB transaction
>    * for each cloning.  When it's time to commit, we'll walk those
>    * nodes (it doesn't matter in what order), looking for
>    * irreconcileable conflicts but otherwise merging changes from
>    * revisions committed since we started work into our transaction.
> 
> 
> Now, a very long time ago, we decided to use the word `clone' to
> designate the files and directories that had been virtually copied, by
> making new pointers to them.  But I kind of dropped that usage a long
> time ago, and then revived the word more recently to refer to creating
> successors.  If you think we should retain that old definition, and
> invent a new term for creating node revision successors, that's okay.
> But your usage of `clone' in the quote at top isn't consistent with
> either precedent, it seems to me.

Re: What `cloning' means

[Jim Blandy <ji...@zwingli.cygnus.com>]

Karl Fogel <kf...@galois.ch.collab.net> writes:
> I think it's more redundant than inconsistent,

Perhaps it's inconsistent in some places, but not others.
:)