Will Dean wrote:
> Yes, I think I agree with this too, in general. It's just when we're at
> the current stage in the SVN release cycle, when there will be no big
> release until locking is implemented (which could be ages), it seems
> like it might be hard to get mere performance issues into a SVN release.
>
> The problem is that SVN can actually suffer terrible perf problems in
> its official releases, and these can bleen through into TSVN. TSVN
> 1.0.8 was incredibly slow, and was the latest official TSVN release for
> a long time. This was because Stefan had forgotten to apply a SVN patch
> before building it.
> (This patch had been in previous TSVN releases)
And that's exactly why I don't like to patch other libraries! I just
haven't found a way to automatically patch a library from the build
script. And if something isn't in the build script, it tends to be
overlooked and forgotten.
> So TSVN hasn't always (or perhaps even generally?) been built off
> un-patched SVN releases, and maybe that's just inevitable, though
> clearly undesirable.
The path for TSVN1.0.x to the subversion library was really necessary
because of the _huge_ performance gain (or lost if not applied).
> Personally, I would much prefer us to patch TSVN to avoid this
> particular perf bug, but I'm failing to convince Stefan that my
> avoidance technique is safe. (Though the ball is currently in his court
> to tell me why it isn't! ;-)
I've already merged two revisions from the Subversion trunk to my 1.1.1
copy of the Subversion sources. So I can test that stuff. Also, I have
convinced the Subversion guys to nominate one of those two fixes to
include for the next 1.1.2 release (the other one's already nominated).
And today they accepted that. So I think that's the better way to handle
those fixes.
And even though I asked you guys to step in and also write a mail to the
Subversion dev list to support my request to include that fix in 1.1.2,
noone did!
> Of course, it actually matters less to me than to anyone else, as I'm
> cheerfully running a build with all these patches in.
>
> Maybe I should fork the whole lot (apr, svn, etc), apply my performance
> patches where I see fit, and just publish that as a 'racing version',
> for people to take if they trust me, and not if they don't...
That would be very sad. Forking projects is never a good idea, it splits
up the development effort.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Oct 30 00:09:36 2004