Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-2048

Primary connection (of parallel network connections used) in ra-dav diff/merge timeout unnecessarily.



    • Bug
    • Status: Closed
    • Critical
    • Resolution: Fixed
    • all
    • 1.2.0
    • src
    • None


      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.


        1. 1_issue-2048-patch.txt
          26 kB
          C. Michael Pilato



            Unassigned Unassigned
            cmpilato C. Michael Pilato
            0 Vote for this issue
            0 Start watching this issue