[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Q: editor callback order?

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 07 Nov 2008 00:18:53 +0000

OK, I'll attempt a response.

On Thu, 2008-11-06 at 06:14 +0100, Neels J. Hofmeyr wrote:
> 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?

You're talking about receiving Editor calls and converting them to
svn_wc_diff_callbacks3_t calls, which is done in the client diff code.
One of the svn_delta_editor_t promises is:

 * 4. A producer must call @c change_dir_prop on a directory either
 * before opening any of the directory's subdirs or after closing
 * them, but not in the middle.

So you can't rely on them coming before. I don't know whether you feel
you've exercised the parts of our code that generate diffs enough to be
confident that they always do it in this order. I would feel much better
if you could cope with any order. If you rely on the order you're
finding now, I think this would only be acceptable as a temporary

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

Huh, what do you mean by "it works" above, then? This paragraph seems to
contradict that. Are they referring to different things?

But I wonder if this is really such a problem...

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

We're obviously talking about a merge here (as update/switch don't use
diff_callbacks). But in which scenario is this relevant? I can't picture

> - Summarizing diff wants to
> (a) print directories above their children while

It would be OK for it to print the directory below the children. It
doesn't have to be above. Maybe you can collect them all in a baton and
print them on dir_close() (heh, you'd have to resurrect it). You could
store this data in the single diff_callbacks baton; the callbacks don't
need to support per-directory or per-file batons to do this.

> (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.

+1 on that change, as we said.

> 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.)

That is related in the sense that it's a case where we had to decide to
impose an ordering where initially we hadn't imposed it. We could
probably do the same, if we have to, in other respects: we could say
that from v1.6 onwards the order of calls is restricted to XYZ. But then
we'd need to consider what would happen when a new client connects to an
old server.

- Julian

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-07 01:19:13 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.