[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.

That's one command out of many that the svnmerge.py runs.

It would also be interesting to send the output from these commands to wc to see 
how much more information is being passed from the server to the client.

What we need are speed tests on running svnmerge.py in normal circumstances, 
with and without the --bidirectional flags.  While svn log --verbose is slower, 
the increased time may not be significant to all the other work that svnmerge.py 
is doing.  It also matters how many revisions are commonly looked at by svn log.

I'm also more concerned about having svnmerge.py operate correctly than speed. 
I don't see it as gratuitous.  I would rather see an optimization flag to turn 
off bidirectional support than the other way around.

> I'll review the patch later today, thanks!

Great!

Regards,
Blair