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

Re: current plan for WC

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 2 Oct 2008 10:44:59 -0700

On Thu, Oct 2, 2008 at 10:27 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Mark Phippard wrote:
>> On Thu, Oct 2, 2008 at 1:08 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>> Mark Phippard wrote:
>...
>>>> Could "entries" be moved to sqlite for 1.6? Too much work? Seems
>>>> like that would yield an improvement.

Possibly, but a good bit of work to bite off for the 1.6 timeframe
(which is scheduled to branch in 4-5 weeks).

A more likely improvement that I've mentioned is moving the properties
into SQLite. That could be a separable task from the
ball-of-nastiness.

>>> Would it? Don't we keep entries in memory most of the time, attached to the
>>> adm_access batons?

Hopefully. I don't recall if anybody has done a serious analysis of
reading/writing of the entries files.

>> Wouldn't issues like SVN connection timing out why we rewrite a large
>> entries file go away if each "entry" is just a row in a table?
>
> It's probably not the rewriting of the entries file that's killing us there.
> I would suspect it's the processing of the log files as a whole, which
> involves (besides just writing out the entries file) copying the files from
> text-base to the working area, keywords expansion, newline conversion, etc.

Yah. Seems more likely, but would need to take an honest look.

Note that moving to SQLite would get rid of a bunch of loggy actions,
as SQLite will guarantee the atomicity for us. Thus, we could perform
a bunch of atomic operations as-we-go rather than one big sucker at
the end.

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-02 19:45:41 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.