[Svnmerge] [PATCH] Bidirectional patch take 2

[Blair Zajac]

Giovanni Bajo wrote:
> Blair Zajac <blair at orcaware.com> wrote:
> 
> 
>>>Please run timing tests with and without the --bidirectional flags,
>>>especially if you are using a repository that does not do
>>>bidirectional merges.
>>>The optimization in the patched svnmerge.py should show
>>>almost no speed loss.
>>>
>>>If people cannot show a speed hit for enabling this feature by
>>>default, I'll
>>>plan on doing so.
> 
> 
> $ echo $GCCREPO
> svn+ssh://giovannibajo@gcc.gnu.org/svn/gcc
> 
> $ time svn log --quiet -r100000:110000 $GCCREPO/trunk 2>&1 >/dev/null
> real    0m21.590s
> user    0m0.188s
> sys     0m0.044s
> 
> $ time svn log --quiet -r100000:110000 $GCCREPO/trunk 2>&1 >/dev/null
> real    0m22.816s
> user    0m0.192s
> sys     0m0.040s
> 
> $ time svn log --quiet -r100000:110000 $GCCREPO/trunk 2>&1 >/dev/null
> real    0m21.248s
> user    0m0.180s
> sys     0m0.092s
> 
> 
> 
> $ time svn log --verbose --quiet -r100000:110000 $GCCREPO/trunk 2>&1 >/dev/null
> real    0m42.020s
> user    0m0.688s
> sys     0m0.108s
> 
> $ time svn log --verbose --quiet -r100000:110000 $GCCREPO/trunk 2>&1 >/dev/null
> real    0m44.731s
> user    0m0.652s
> sys     0m0.088s
> 
> $ time svn log --verbose --quiet -r100000:110000 $GCCREPO/trunk 2>&1 >/dev/null
> real    0m52.781s
> user    0m0.668s
> sys     0m0.108s
> 
> 
> So, logging is basically twice as slower. Even if the merge time dominates, I'm
> unsure whether we want to add this gratuitous overhead for users not doing
> bidirectional merges.

I was able to reproduce the doubling of time against the gcc repository.  Also, 
the amount of data sent by the server to the client is significant, if you send 
the output of those commands to wc.  Adding the -v flag increases the amount of 
data by a factor of four.

$ svn log -q -r 100000:110000 svn://gcc.gnu.org/svn/gcc/trunk|wc
    9283   55693  635490
$ svn log -v -q -r 100000:110000 svn://gcc.gnu.org/svn/gcc/trunk|wc
   61021  160407 3107837

I did some tests against our internal Subversion server using a similar 10,000 
revision range, but from the top of the repository, not from a trunk, since we 
have 50+ projects in the repository, each with their own trunk.  This is over a LAN:

$ /usr/bin/time svn log -q -r90000:100000 http://svn/svn/repos | wc
0.38user 0.10system 0:18.02elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+922minor)pagefaults 0swaps
   20003  120120 1358764
$ /usr/bin/time svn log -q -r90000:100000 http://svn/svn/repos | wc
0.40user 0.09system 0:18.26elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+918minor)pagefaults 0swaps
   20003  120120 1358764
$ /usr/bin/time svn log -q -r90000:100000 http://svn/svn/repos | wc
0.41user 0.10system 0:18.06elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+919minor)pagefaults 0swaps
   20003  120120 1358764


$ /usr/bin/time svn log -v -q -r90000:100000 http://svn/svn/repos | wc
0.87user 0.17system 0:18.39elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1243minor)pagefaults 0swaps
   63417  218167 3706655
$ /usr/bin/time svn log -v -q -r90000:100000 http://svn/svn/repos | wc
0.91user 0.13system 0:18.38elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1244minor)pagefaults 0swaps
   63417  218167 3706655
$ /usr/bin/time svn log -v -q -r90000:100000 http://svn/svn/repos | wc
1.02user 0.16system 0:20.49elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1243minor)pagefaults 0swaps
   63417  218167 3706655

There's almost no difference in clock time and more than a doubling of the data 
printed by svn log.

So this tells me that svn log is being bandwidth limited, not server limited, at 
least in the gcc repository case.

So the two times performance impact doesn't happen everywhere, which is a good 
thing.  So people working in an enterprise environment won't be affected.

Given this, can we get some standard svnmerge.py commands that the gcc people 
will be running?  Give us some sample commands that we can run ourselves.

I would like to find out a common revision range that svnmerge.py will look over.

Also, even if svn log -v is two times slower for gcc, then if the svnmerge.py 
run takes several seconds, than that's different than doubling from a minute to 
two minutes.

So the more data we have to make a decision, the better.

We need those svnmerge.py commands the gcc people are running :)

Regards,
Blair