[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn merge operation extremely slow

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sat, 1 Oct 2011 01:15:00 +0200

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):

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


Received on 2011-10-01 08:27:54 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.