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'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