I was using 1.9 on an old working copy and found that the performance of
"svn st" and "svn cleanup" with 1.9 was much slower than with 1.8: 30s
instead of 0.2s or over a hundred times slower. I'm using SQLite
3.8.7.1.
After some discussion on IRC I identified the cause of the problem as a
missing sqlite_stat1 table, as produced by ANALYZE. The slowdown occurs
in the timestamp fixing code, which uses the status code, and I see 1.9
using queries with an extra ORDER BY clause. The sqlite_stat1 table is
created when a user runs "svn upgrade" with recent 1.8 or 1.9.
The problem occurs when a user started with a 1.7 working copy and
upgraded with early 1.8, or started with an early 1.8 working copy.
These working copies do not have the sqlite_stat1 table and 1.8
performance suffers with SQLite 3.8, however not all operations are
affected. After upgrade to 1.9 more operations are affected, in
particular "svn st" as in my opening paragraph.
The user can fix the problem by running "svn upgrade", as that adds the
table if it does not exist, but the client does not prompt the user to
do that as the working copy is already upgraded. I think the 1.9 client
needs to make it easier for the user to fix the problem: either create
the table automatically or produce a warning message when it is not
present.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2015-03-05 21:07:04 CET