Johan Corveleyn wrote on Sat, Oct 01, 2011 at 20:47:29 +0200:
> [ 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).
>
What does 'svn merge' do for binary files? I checked svn_wc__merge()
a few months ago and for binary files all it knew to do was
(a) if mine == merge-left then set merged := merge-right
(b) invoke the configured diff3-cmd
(c) raise a conflict
but it didn't do any line-based merge (per Johan's second response).
> 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?
>
Another line of thought: the algorithm for computing binary deltas
changed a few years ago, and I recall reading (on old bug reports?)
about some cases in which the delta combiner would be inefficient for
deltas generated by old servers --- i.e., it would be expensive to 'svn
cat' files that were committed to old servers in repositories that
haven't been dumped/loaded by a newer server.
In any case: can you run the merge under a profiler and tell us in what
function(s) time is spent?
Daniel
> --
> Johan
Received on 2011-10-01 21:11:32 CEST