Hi Andreas,
On Tue, Aug 9, 2011 at 11:06 AM, Andreas Krey <a.krey_at_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.
Received on 2011-08-09 11:46:48 CEST