On Thu, Apr 16, 2009 at 15:35, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Apr 16, 2009 at 9:32 AM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> On Apr 16, 2009, at 4:33 AM, Branko Cibej wrote:
>>> Hyrum K. Wright wrote:
>>>> * Current implementation is *slow*.
>>> I assume you know why and how to fix that, right?
>> Aside from the sqlite database issues mentioned by Greg elsethread,
>> we're also not taking full advantage of the new data store yet.
>> Neither properties or the dav cache (the old 'wcprops') have moved
>> into the sqlite database. Almost all the code external to wc-ng is
>> still relying upon svn_wc_entry_t to interface with the sqlite
>> database, which requires a complex, and potentially performance
>> intensive, translation. Moving the rest of libsvn_wc to hit the wc_db
>> directly will make things quicker indeed.
> So you are mainly wanting to do this to avoid the costly work of
> supporting the interim format 11. Aren't you going to have the same
> problem with 12 and others? As you move more things to the database
> and eventually get rid of the per-directory .svn folders aren't you
> going to continue to have these problems to deal with?
The bulk of the data is *already* in the database. It's just the
properties that are external. IOW, there are no "more things" other
Right now, we can't really use the wc_db without some costly work.
I've enabled a couple APIs (read_info and read_children), but the rest
are off limits. For each one, we have to write code to map that
functionality onto the v11 format. Ugh. After that, then we can start
using the new API within libsvn_wc. In short: it is very slow going to
*actually* move libsvn_wc onto v12 since we still have to support v11.
Once v11 is dropped, then we can call wc_db APIs at will (those that
are implemented, at least).
Received on 2009-04-16 15:49:00 CEST