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

Re: Merging Branch to Trunk takes 20 min for one change

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Mon, 12 Oct 2009 20:28:03 +0200

On 11.10.2009 13:26, Dadeo wrote:
> Wow, I did not expect you to do that for me! Thank you. Can you
> confirm that the merge did not show modified properties on all
> versioned files? If so, that is very enouraging. At least I know it
> can work.
>> Anyway, [Ben] told you to ask on the Subversion mailing list, not on the
>> TSVN mailing list because the svn mailing list is where the svn core
>> developers answer questions. They know a lot more about the internals of
>> the svn library than I do.
> Sorry, I did not realize the difference.
> I did a fresh checkout and tested before I initially reported the
> problem to you. I also had two other developers test the merge and
> they had the same problems I did, so I concluded it was not a problem
> with my system/internet. However, I did not check what anti-virus
> they were using.
> I duplicated your test exactly as you described. I assume the depth
> was working copy. I disabled my anti-virus (Nod32) before the new
> checkout and merge.

Ahem: Nod32 saves you from yourself and doesn't disable itself properly,
even if you ask it to. From what I've seen with that 'thing' is that it
just won't stop 'protecting' you.
I once had to completely uninstall that crap to get a connection working
properly. Admitted, it was about two years ago and I'm sure it has new
versions since then, but that was enough for me to get rid of it for good.

> The slow part of the merge is the first part - averaging about 750
> Bytes/s. Once the merged starts sending content (at about 1096 kBytes
> transferred) it transfers at about 33 Kbytes/s. My internet speed is
> only 256kb/s. But the other developers tried at much higher speeds
> with the same results.

The 'slow' part as you describe it is the part where svn asks the
repository for the required merge info. Since that info is sent in small
data packets (usually only a few revision data for every request the
client sends), the number of bytes/s is very low. What takes most of the
time is the establishing of connections to the repository (and there are
a lot of those).

> The results of duplicating your test were odd. I received tree
> conflicts. All versioned files are still marked as modified
> properties. And the merge still took almost 20 minutes.

Yes, I also got a lot of files marked as modified and even three tree
conflicts. But all those files that were marked as modified had their
svn:mergeinfo property modified, not their contents.

You could also try a nightly build. Since I'm using always the latest
one from trunk, it might be that there are improvements in the svn
library which are not yet in a release (btw: 1.6.6 is planned for the
end of this week).


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-10-12 20:28:10 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.