[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [TSVN] Re: Another go at a patch for SVNFolderStatus

From: SteveKing <steveking_at_gmx.ch>
Date: 2004-10-29 23:07:06 CEST

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.


   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

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.