[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_client_upgrade and speed

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 11 Sep 2009 21:18:06 -0400

As stsp notes, this is an artifact of continuing to use multiple sqlite
databases. Shoot ... we still haven't integrated the multiple property files
into the databases. That represents a *TON* more I/O then our target
implementation.

Yes, you reported it a while back, and we were just as aware of it at that
time as now. This is a fuckton of work. If you want it sooner than we are
going, then jump in and help. I think you're underestimating the work here,
and the amount that has and is being done. Speaking for myself, your comment
makes my work feel unappreciated.

The externals thing is an interesting point. Same will happen with nested
working copies that are not managed via externals. I think we may want to
handle those by default, but there are usability issues and some backwards
compat problems that could bite us. Could you please open an issue with your
ideas, so that I can track it to completion? Thanks.

Cheers,
-g

On Sep 11, 2009 11:32 AM, "Stefan Sperling" <stsp_at_elego.de> wrote:

On Fri, Sep 11, 2009 at 11:04:22PM +0200, Stefan Küng wrote: > Seriously,
this is not just a minor i...
As far as I understand there is much work left to do before it can be
made any faster. So what you are seeing is currently still expected.

> If this doesn't improve soon, I won't link TSVN with svn 1.7 but stay >
with version 1.6. With v...
You should stay with 1.6 then, until 1.7 has moved to using
a single database.

Stefan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2393734

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2393776
Received on 2009-09-12 03:18:13 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.