Jim Blandy <jimb@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.
Received on Sat Oct 21 14:36:22 2006