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. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
