When handing update-style REPORT responses, libsvn_ra_serf generates for each
file a pair of pipelined follow-up requests: a PROPFIND (for properties) and a
GET (for file contents). The order of these requests matters -- that is, the
code expects the PROPFIND results to have been processed before trying to deal
with the file's content.
I recently added logic to libsvn_ra_serf to consult the working copy pristine
store for file contents whose SHA1 checksum matches that of files about to
fetched from the network (via GET requests) so we can, you know, avoid
transmitting that content again. Unfortunately, the only way I could find to
preserve the required ordering of properties-then-content was to tie the content
handling to the Serf pipelined request logic (as it was beforehand) but using a
request that doesn't actually pull down the file's content. I used a HEAD
request to do so.
Ideally, though, there would be a way to stuff some sort of order-preserving
generic callback mechanism into the Serf pipeline machinery: "If we've made it
this far in processing the pipelined request results, go do this non-network-y
thing..."
With such a thing in place, we could avoid those HEAD requests altogether when
we know the file's content is already locally available.
Improvement
Major