[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-commits-nodiffs] Revision 7888fc3d6ad3f27eb418b4b7d587409fb9c7
From: |
monotone |
Subject: |
[Monotone-commits-nodiffs] Revision 7888fc3d6ad3f27eb418b4b7d587409fb9c70043 |
Date: |
Sun, 3 Oct 2010 02:28:52 +0200 |
----------------------------------------------------------------------
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
----------------------------------------------------------------------
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Monotone-commits-nodiffs] Revision 7888fc3d6ad3f27eb418b4b7d587409fb9c70043,
monotone <=