Greg Hudson <ghudson@MIT.EDU> writes:
> 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.
So get_editor() would return both an edit_baton and a root_dir_baton?
> > 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.
Sure, it helps directories finish up as soon as possible, and in fact
that's exactly how the update editor works now. When the driver calls
close_file() on the last open file in a directory D, then D will get
closed at that time, no matter how many other open file batons there
are.
Unless I'm missing something basic here, it is simply not the case
that all directories with changed files are tied up until almost the
end of the edit. A dir D is tied up just exactly as long as it needs
to be, which is until the last postfix txdelta for a file in D is
handled.
> > 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.
Hmm. It's hard to argue against this, as I'm sure you're aware :-).
I'm essentially claiming the same thing, but in reverse.
It's not very constructive of me to say this, perhaps, but: What we're
now discussing *is* all stuff that was listed explicitly as part of
Change #1. The disappearance of the edit_baton and close_edit() were
both part of the proposal (though all the ramifications of their
disappearance were not necessarily apparent).
Is the issue that, now that you've seen Change #1's effects on one
editor, you realize that you don't like it? If so, let me offer the
fact that I've seen its effects on all the editors, and in the
majority of cases, I think they got simpler and less error-prone, not
more.
-K
Received on Sat Oct 21 14:36:20 2006