Comment 1 by Thomas Keller, Apr 17, 2007
The problem is that db migrate not always needs a db regenerate_rosters call (f.e. for the transition between 0.33 and 0.34), however if you do something like the following scriptwise $ mtn db migrate && mtn db regenerate_caches monotone happily regenerates the caches even if it is not needed. And regenerating the caches can be quite time consuming for bigger databases. On the other hand, regenerate_caches makes perfectly sense as stand-alone command if you have messed around with db kill_rev_locally and need to clean up things, so I wouldn't certainly vote for (re)moving that either or putting it into db migrate. So, what about the following: a) let mtn db migrate set a flag somewhere that the caches have to be regenerated (if this isn't already done) after a scheme migration b) make mtn db regenerate_caches default behaviour to do nothing if no such flag is present and only start something if the flag is set or some --force option is given (I know Nathaniel hates --force option, but I think it would be quite useful here...) Opinions?
Sign in to reply to this comment.
Reported by Unknown User, Apr 5, 2007