Hi, Andreas,
Andreas Krey [mailto:a.k...@gmx.de]
> 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
On Tue, 09 Aug 2011 12:12:17 +, Stefan Sperling wrote:
...
> export SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS=1
ITYM "...AMPS=yes". Then it's running faster (and not apparently corrupt)
indeed, and we're now closing up to git.
I'd like SVN_DO_CONTENT_CHECK_ON_EQUAL_T
On Tue, Aug 09, 2011 at 11:46:06AM +0200, Erik Huelsmann wrote:
> 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
> ret
On Tue, 09 Aug 2011 11:38:41 +, Stefan Sperling wrote:
...
> Which script are you referring to? Can you post it or provide a link?
This one:
set -xe
rm -rf repo wc
time svnadmin create repo
time svn checkout file:///`pwd`/repo wc
cd wc
mkdir D
touch A D/B D/C E
# svn add . # <- That nuisance
Hi Andreas,
On Tue, Aug 9, 2011 at 11:06 AM, Andreas Krey wrote:
> On Mon, 01 Aug 2011 07:39:59 +, 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 r
On Tue, Aug 09, 2011 at 11:06:43AM +0200, Andreas Krey wrote:
> 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 r
On Mon, 01 Aug 2011 07:39:59 +, 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 se
