This skelta problem is caused client side when no DAV cache is
available (in this case the client requests the full text and all
properties as it doesn't know how to ask the delta against base).
Server side there is no property filtering problem (and this problem
doesn't occur with serf via HTTPv2 either)
Bert Huijben (Cell phone) From: Neels J Hofmeyr
Sent: zaterdag 27 augustus 2011 4:17
To: dev_at_subversion.apache.org
Subject: 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
Received on 2011-08-27 12:56:24 CEST