[Svnmerge] [PATCH] Bidirectional patch take 2

[Blair Zajac]

Giovanni Bajo wrote:
> Blair Zajac <blair at orcaware.com> wrote:
> 
> 
>>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.
> 
> 
> Yes, but I personally care more of people which have already slow
> performance, rather than those which work locally and are blazingly fast. In
> fact, we could make svnmerge.py much easier to maintain and much more stupid
> by dropping caching, optimization of revision ranges and so forth, were it
> only for people working with a local repository.
> 
> Much of the carefully tuned code in there is just for those who have slow
> connections to their server. And those users should not be penalized as
> well.

True.  So let's come up then with a standard.  If the tests come back as the 
average running time of svnmerge.py is under N seconds, then we enable it by 
default, otherwise we leave it disabled.  I'm guessing gcc is a good test case 
for us, since it is so large, has many revisions under a single trunk and is not 
on a LAN for most committers.

This value of N will also enable us set a target, were if we put caching into 
svnmerge.py to remember the output from 'svn log -q -v' and other commands, then 
when we reach that target, we can enable it by default.

>>So the more data we have to make a decision, the better.
>>We need those svnmerge.py commands the gcc people are running :)
> 
> 
> Check it in the patch and I'll try to provide this information.

It's in there :)

Please send us the commands they'll be using for testing.  I would like to run 
any speed tests myself also.  Finally, even though we'll be local svnmerge.py's 
on gcc and other repositories, we don't have to worry about committing those 
merges back to them, as we don't have commit rights :)

Regards,
Blair