[ 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 <kyle.leber_at_gmail.com> wrote:
> On Fri, Sep 30, 2011 at 7:15 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>
>> On Fri, Sep 30, 2011 at 3:29 PM, Kyle Leber <kyle.leber_at_gmail.com> 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
Received on 2011-10-01 20:48:24 CEST