Q: editor callback order?

Hi all,

I'm busy writing code around svn_wc_diff_callbacks3_t that relies on the
"Editor" to send *all* prop changes on a directory *before* it starts
sending stuff on the children of that directory.

More specifically, I'm wedging in a function that gets called as soon as
anything is sent on any child node of a directory for the first time. The
function wants to claim that it is called after all prop changes on the
directory have come in, and before anything is done to the children of that
directory. A first SVN_ERR_ASSERT trial of mine suggests that it actually
works. But, generally:

Is This Ok?

A concern is that the current diff driving code tends to handle dir prop
changes on close_dir(), meaning *after* all children. If that has a good and
fix reason, I'm screwed. Unless all "late" props are things like mergeinfo.

Thanks
~Neels

...more details, if you like:

Why do I want to do this?
Both tree-conflicts notification and summarizing diff need to know all prop
changes on a directory before iterating the children of that directory:
 - Tree-conflicts may want to skip all children,
 - Summarizing diff wants to
   (a) print directories above their children while
   (b) being able to tell whether an added directory also has prop changes.

I've seen that *file* prop changes have been changed to come along with
file_opened() and file_added() instead of via a separate callback for props,
and I want to do the same for directories.

So I am discarding dir_props_changed() from svn_wc_diff_callbacks3_t, and am
instead adding prop change parameters to dir_opened() and dir_added(), so
that all prop changes are already available when the directory is
opened/added. But to call the dir_opened() and dir_added() callbacks at the
right time (after all props, before all children), I am making the slightly
acrobatic move of triggering as soon as the first child node is encountered
(or the directory is closed again).

If anyone thinks/knows this to be terminal bull, please shout!

BTW, the callbacks already rely on a node deletion to come in before a node
addition in order to detect a replace. (If it's related at all.)