subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Huelsmann <ehu...@gmail.com>
Subject Re: svn wc&repo performance
Date Tue, 09 Aug 2011 09:46:06 GMT
Hi Andreas,

On Tue, Aug 9, 2011 at 11:06 AM, Andreas Krey <a.krey@gmx.de> wrote:

> On Mon, 01 Aug 2011 07:39:59 +0000, Les Mikesell wrote:
> ...
> > SQLlite has years of development and a good reputation for robust
> behavior.
>
> I don't doubt that.
>
> > I'd expect it to be hard to match its performance and reliability without
> > an equally long development cycle.
>
> We don't want an SQL server, we want an svn client.
>
> A tool used must not only perform, but also be the proper tool.
>
> > I don't quite understand the point of re-implementing something that is
> > already developed on top of cross platform open source libraries.
>
> Using SQL is a tradeoff between developer time and user time; any
> implementation of SQL is obviously not as performant as a domain-specific
> serialization can be. Given the large user base of svn, some more thought
> in that direction may have been in order.
>
> But I may be barking up the wrong tree. I built svn 1.7 and ran my
> small 'second consecutive commit fails' test script with that. It's
> not the local operations, but those that act on the repository (here:
> file:///...) that take ridiculously long. Each commit and do-nothing
> 'svn up' takes about a second, for the five files involved. I've come
> to expect such operations to be instantaneous.
>
>
The fact that the 'svn up' takes about a second can't be blamed on SQL Lite
or any other SQL engine. The Subversion client sleeps 1 second to make sure
that it's able to detect changes to files: it does timestamp checks and
returning immediately would allow a short timeframe where modifying the file
would not result in a new timestamp (namely, modifications within the same
second, such as the use by scripts).

Bye,

Erik.

Mime
View raw message