[Svnmerge] [PATCH] Bidirectional patch take 2
blair at orcaware.com
Fri Feb 24 15:01:45 PST 2006
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
> 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
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 :)
More information about the Svnmerge