Hi Andreas, On Tue, Aug 9, 2011 at 11:06 AM, Andreas Krey <a.k...@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.