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.