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*
