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.
Critical