Re: svn status <file> is slow under a large check-out

Thanks for all great info so far!

>Taking that query out reduces the read() calls back to 99. Do we need
>another SQLite index? Can we improve that query?

Your index idea was a good one. I used sqlite3 to back up my wc.db,
then ran the query you found, filling in the parameters as appropriate
and commenting out the use of IS_STRCT_DESCENDENT() since that is a
custom function that I didn't have on hand. Running it with .timer ON I
found that the query takes 4.15s to run on average. I then created an
index like this:
  CREATE INDEX bobindex1 ON nodes (kind, presence, op_depth)

and now the query consistently takes 0.27s. Really good news! But I
wonder if improving the query is a better solution, or at least should
ALSO be done. For one thing, it seems that running "svn status" on just
a file should implicitly behave as if the --non-recursive flag had been
specified, shouldn't it?

So I think I'm going to add that index to my actual wc.db to work around
the problem myself, but I still think an issue should be created to
provide a permanent fix. (And I think the permanent fix would be three
things: the index, the implicit --non-recursive behavior for files, and
possibly the query optimization if someone can come up with an
improvement.)

Can I get a "buddy" on this? Thanks again!
Received on 2012-05-05 18:39:38 CEST