The that diffs and merges are done at the same time the data for those operations is being read off the network has the positive effect of making the operation show progress early. But the downside is that folks wishing to use external diff and merge tools either must background those tools, or use them really, really, quickly to prevent the network pipe from backing up and the server disconnecting (because it thinks the client has disappeared). This is related to issue #1966, in which we saw that even our *internal* diff program can operate slowly enough that merge operations could timeout server-side. This can be fixed in a few ways (speaking DAVvishly here, but I think similar issues apply to svnserve): a) the RA layers can cache the result of their REPORT request before attempting to process them. b) the client/WC layer can do the work of generated tmpfiles as the editor->apply_textdelta() calls come in, but *not* do the actual work of contextual diff/merge (though, in theory, the svndiff handling could timeout the server in the same way that contextual diff work does). c) reverting the streamy REPORT response in favor of some other (maybe multi-threaded, or pipelining?) solution. I deem this issue critical to legitimate interaction with external merge tracking tools, but will settle with P2 for priority right now.