[Monotone-commits-nodiffs] Revision 7888fc3d6ad3f27eb418b4b7d587409fb9c70043

[monotone]

----------------------------------------------------------------------
Revision: 7888fc3d6ad3f27eb418b4b7d587409fb9c70043
Parent:   49dd914875452ee88c691a67f6f53f637cf40881
Author:   address@hidden
Date:     10/03/10 02:25:55
Branch:   net.venge.monotone.automate_get_roster

Changelog: 

* database.hh/cc: new migration method put_file_sizes_for_revision
  which loops over all added / changed files of each changeset of a
  revision and caches their file sizes
* database.cc (database_impl::sql): remove an invariant which assumed
  that we only ever open the database in "normal" mode again - this
  is not correct, in case the migration happens in several, disconnected
  steps. Actually we should save the old open state here and close /
  reopen in the new state if we find out that the mode changed, then
  however all other functions which currently assume "normal" mode would
  have to re-open the database and would furthermore also fail in case 
  a cache table has not yet properly been refilled.
* migration.hh: introduce a new enum, regen_cache_type, which determines
  which specific cache needs to be invalidated after a migration, or if none 
  or all caches need to be regenerated (tweak the migration_status
  class accordingly). 
  This reduces the amount of time people have to wait who normally do 
  regular updates. In the file sizes example regenerating all the file 
  sizes only takes 6 minutes, while regenerating all caches takes 15 minutes
  (2GHz Core 2 Duo, nvm*), so this should improve the user experience here.
  In the future implementors can decide whether their schema change only 
  needs a particular cache invalidation of an existing cache, a cache
  invalidation of all caches or a cache invalidation of a new, yet to be
  defined cache type.
* migrate_schema.cc (migrate_sql_schema): add regen_cache_type to the
  migration_event structure and set it accordingly for the older migrations
  (tests will show if this works out, I might have to set a couple of older
  migrations to regen_all); if a migration needs the invalidation of more
  than one particular cache, all caches are invalidated by default (best
  automatic guess so far)
* migrate_ancestry.cc: split up the single regenerate_caches function in
  in separate functions of which each handles the invalidation of a specific
  cache; add tickers to the branch cache invalidation function and make them
  all use tickers with a resolution of 1 (we have some weird bug in our
  ticker code which lets the ticker output two clean lines after it finished,
  need to investigate this one sometime)
* cmd_db.cc (regenerate_caches): call regenerate_caches with regen_all

Changes against parent 49dd914875452ee88c691a67f6f53f637cf40881

  patched  cmd_db.cc
  patched  database.cc
  patched  database.hh
  patched  migrate_ancestry.cc
  patched  migrate_schema.cc
  patched  migration.hh


mtn --db={your.database} diff 
--revision=49dd914875452ee88c691a67f6f53f637cf40881 
--revision=7888fc3d6ad3f27eb418b4b7d587409fb9c70043
----------------------------------------------------------------------