[ Please do not top-post on this list, i.e. please put your reply below or inline. More below ... ]
On Sat, Oct 1, 2011 at 6:49 PM, Kyle Leber <[email protected]> wrote: > On Fri, Sep 30, 2011 at 7:15 PM, Johan Corveleyn <[email protected]> wrote: >> >> On Fri, Sep 30, 2011 at 3:29 PM, Kyle Leber <[email protected]> wrote: >> > I've encountered what I think is a problem with subversion, but I'm not >> > completely sure (and according to the online instructions I should bring >> > it >> > up here prior to filing a bug). >> >> Actually, the instructions on >> http://subversion.apache.org/issue-tracker.html say that you should >> send your report to users@, not dev@. So I'm adding users@. Please >> drop dev@ from any further replies. >> >> > Basically, we're trying to merge a rather large collection of fixes back >> > in >> > our trunk. I check out a fresh copy of the trunk, then use the merge >> > syntax: >> > svn merge https://path/to/my/branch . >> > >> > This generally churns along just fine, but we occasionally get hung up >> > on >> > medium sized binary files where the svn client jumps to 100% cpu usage >> > and >> > sits on it for 3+ hours before moving on to the next file. These files >> > are >> > anywhere from 3-10MB in size, so not ridiculously huge. We generally >> > have >> > these files marked as octet stream, but changing to text did not help >> > the >> > situation when we tried that. >> > >> > I did find an old forum discussion about a potential issue that could be >> > related. I was wondering if this was ever addressed and could it still >> > be >> > the same problem. Link is here: >> > http://www.svnforum.org/threads/36123-Slow-SVN-merge >> > >> > I'm using svn client 1.6.12. I looked at the online change log up >> > through >> > the 1.7 alphas and didn't see any bug fixes that sounded relevant. >> >> This could be a relevant change (listed in the 1.7 release notes, not >> in the change log): >> >> http://subversion.apache.org/docs/release-notes/1.7.html#diff-optimizations >> >> Can you please try one of the 1.7 pre-release binaries, and see if it >> helps? See http://subversion.apache.org/packages.html#pre-release >> > Thanks, Johan. I tested with 1.7rc4 and it did not make any perceptible > difference. Anything else I can try? Hm, that's unfortunate. Actually, it was to be expected that this wouldn't help, because the diff-optimizations in 1.7 only play a role when merging text files (and diffing and blaming). And you said those "files-that-make-merge-hang" are generally marked as octet-stream, and changing them to text made no difference. That seems to indicate that the 100% cpu usage on the client isn't spent in the diff code (unlike the forum thread that you linked to, where the poster tracked it down to libsvn_diff/lcs.c --- he would definitely have been helped by the 1.7 improvements). So there's another reason. Maybe it has something to do with (lots of) subtree mergeinfo? Can you verify if there is a lot of svn:mergeinfo on directories and files all over the place? Also: can you tell us what version is running on the server? Maybe other people on this list have had similar experiences, and can give some suggestions? -- Johan
