No announcement yet.

Slow SVN merge

  • Filter
  • Time
  • Show
Clear All
new posts

  • Slow SVN merge

    I have been using subversion for about 1-2 years now in a production environment with a large number of files (and some large files). But I have not seen until now an issue with merging files that the merge operation takes hours for certain files.

    I have looked at the source code and believe it tracks down to a similar problem that I patched in cvs a few years back and that was the merge operation is not O(n). It seems that the merge operation is O(n^2) on the number of merge chunks that occur for a given change. When there are less than a 1000 this is probably fine, but some joker checked in a file that changed spaces on just about every 8-9th line through a 20-30 Meg XML file.

    First off -- has anyone else experienced this issue? If so, are there any ways you might suggest working around this (other than don't do that)?

    Also, if any dev's are reading this who care to check on this issue, I might suggest you look at libsvn_diff/diff3.c svn_diff__resolve_conflict -- and perhaps track the start positions in the hunk structure so a list traversal through all chunks is not required for each update. If I continue to see jokers do this to files I may try to prototype this fix myself, but if there is anyone else there that is more familiar with the codebase perhaps this is a quick fix.

  • #2
    update on slow merge

    I have built the latest svn source and tested against my merge of death example I have still running (takes about 9 hours for what should normally be a 10 minute task).

    I have narrowed the issue down to the libsvn_diff/lcs.c code where it determines the longest common substrings. Is there a way to use a "simpler" diff operation that would be faster on merges where i'm not as concerned about conflict resolution?


    • #3
      Post to the mailing list

      Dude, you should definitely bring this discussion to the dev list that the Subversion developers actually participate in:


      • #4
        You should definitely subscribe to the svn-dev mailing list and voice your problems there. If you even have a patch in the making, they'd be even happier.

        Br, Mike5