I'm not sure if it is. I don't *think* it's possible for any of the
actions performed by the logs in the parent directory to affect the
directory being opened. However, I had to make the choice between
calling svn_wc_entry() before or after calling
wrapped_editor->open_directory(), and I decided to make the choice
which was consistent with how the code worked before extracting the
editor wrapper, and make it explicit that this *might* be a reason to
keep the svn_wc_entry() call below the open_directory(). But again,
I'm not sure.

You're right. I wasn't sure which choice to make and ended up making a
bit of both.

> svn_wc__ambient_depth_filter_editor() takes a 'requested_depth'
> parameter, which it only uses in a local conditional (e.g., it never
> stores the requested_depth in the wrapper's edit_baton). This is the
> conditional:
>
> if (requested_depth != svn_depth_unknown)
> {
> *editor = wrapped_editor;
> *edit_baton = wrapped_edit_baton;
> return SVN_NO_ERROR;
> }
>
> Great. But from the doc string above, it's not clear whether we
> should have called svn_wc__ambient_depth_filter_editor() at all...
> That is, is it the caller's responsibility to check requested_depth
> and decide whether or not to wrap? Or should the caller always wrap
> (passing requested_depth), but the returned editor might be the
> original editor, if requested_depth == svn_depth_unknown?
>
> We should pick one way and enforce it. I think the way to do that is:
>
> if (requested_depth != svn_depth_unknown)
> {
> svn_wc__ambient_depth_filter_editor(&editor, &edit_baton,
> editor, edit_baton,
> anchor, target, adm_access,
> requested_depth, pool);
> }
>
> ...and just ensure that it is written in such a way that that is safe!
> We'd change the calling code so that it wouldn't have the extra
> variables to hold the wrapper editor, and change the callee to not
> take a requested_depth parameter at all.

OK, and we might as well leave out the requested_depth parameter while
we're at it?