> Here's why: the call to get an editor was *always* followed by a
> call to replace_root().
> [...]
> Well, if we can only do A and B together, and always in the same
> order, then what's the difference between A and B? Why are they
> separate? They might as well be combined, as they're effectively
> one operation anyway.
Agreed. The argument for combining get-editor and replace-root is
clear. But this isn't an argument for combining the editor baton and
the root directory baton.
> But I also think getting rid of replace_root() works out well for
> some other aspects of the editor interface. Given our organizing
> principle that the editor is primarily about tree transformations,
> and that other stuff should be done by calling functions on batons
> (functions which generally just do something to that baton and don't
> return a new baton), then the presence of an externally visible
> edit_baton didn't quite fit.
Of course it fits. "I'm done now" is a perfectly natural thing to say
about a tree transformation, and an editor baton is what you use to
say it.
> When close_directory() is called, the update editor can't actually
> do anything to the directory (such as bump its revision number)
> until all the outstanding file_batons have been closed with
> close_file(). When all the file_batons for directory D have been
> closed, then the postponed work involved in closing D gets done,
> *even though* there may be many other file_batons still open for
> various other directories.
Note that it doesn't actually help much to finish up directories as
soon as possible. If postfix deltas are being used, then all the
directories with changed files are going to be tied up until almost
the end of the edit.
(As things are currently structured, it's easier to ref-count
directories than to keep a list of them to come back to at the end of
the edit, though.)
> But my experience with the update editor is that dealing with this
> slight oddness is not really so hard, and (correct me if I'm wrong)
> I think you didn't have so much trouble dealing with it in the XML
> output editor either.
It's not hard, it's just more complicated and error-prone, and will
probably make people's lives harder in the future when it comes time
to debug something related to this.
Received on Sat Oct 21 14:36:20 2006