Re: diff --summarize

On 08/26/2011 05:47 PM, Julian Foad wrote:
> On Thu, 2011-08-25, I (Julian Foad) wrote:
>> I discovered today that the network traffic generated by my rewrite of
>> "diff --summarize" is ridiculously heavy - like apparently 100 times
>> what it was, in a simple real-world test. I have an obvious patch which
>> I'll apply soon which eliminates the requests for content of deleted
>> files, and that reduces it by a factor of ten
>
> Committed in r1162040.

Your diff-data-flows.txt is really nice for placing patches in the bigger
picture BTW :)
Patch makes sense to me. Unlike the rest:

> I think there's a correctness issue here, related to a quirk described
> in issue #3657 "dav update report handler in skelta mode can cause
> spurious conflicts", which is summarized in the doc string of
> repos_diff.c:remove_non_prop_changes(). Basically, sometimes the RA
> layer will send a no-op prop "change" which is not actually a change.
> If we want to know whether a reported prop "change" is actually a
> change, we have to fetch the original props and compare.

So do I get this right -- this only happens over mod_dav_svn, and basically,
in 'skelta' mode, mod_dav_svn decides not to care which props have changed,
and politely tells the client to just figure it out on its own by sending a
fetch-all-props response, as long as at least one prop has changed. That
*would* be entirely fine with us, but since sometimes this propchange is
just on an internal propkind that we don't care about, we can get a
prop-modified status that is false in our interpretation. Unless we actually
*do* download all props and compare them ourselves. The code has been fixed,
so it currently obediently downloads all props and compares them, and that's
too slow for --summarize.
Right?

That's what I thought first, but then I was reading from Paul's patch:
[[[
1) It stops mod_dav_svn from ever sending the 'fetch-props' response to a
   client, even when in skelta (i.e. send-all=false) mode. The server
   already knows what properties have changed so now it simply sends them,
   rather than telling the client to ask for them later.
[...]
  (upd_change_xxx_prop): Whether we are in send-all mode or not, we have the
   property changes already so send them now, rather than telling the client
   to 'fetch-props' later. The only time we don't send the props is for
   additions while not in send-all mode (i.e. skelta mode) since property
   fetching is implied in addition.
]]]

If I understood everything correctly, this thing, where we get a prop mod on
a non-interesting prop, can today only happen with a prop addition? Because
all other cases send all the props right away?

The more I try to converge all these details, the more I feel that I fail to
understand the status quo :)
i.e., if the server now never ever sends the fetch-props response anymore,
how can your code get 10x slower because it gets this response? (because
neon still sends it?)

/me increasingly guessing

~Neels