Reported by Unknown User, Apr 5, 2007
(This entry was imported from the savannah tracker, original location: https://savannah.nongnu.org/bugs/index.php?19518) It is rough being a packager of monotone with scripts for running unattended "easy" server installations. The natural thing is to want the init.d script to do automatically any db upgrades that are necessary before starting the server after a software upgrade. There is in general no way to know for sure what older version was running before when the database was last used. Originally, db migrate did the job; it's a bit verbose about it, but it's quick when there is nothing to be done. Then there was db regenerate_rosters, and then there was db regenerate_caches. Now db migrate will actually tell you that you need to run db regenerate_caches too, but it won't just do it! I'm sure the separation between the operations is lovely for monotone hackers. But it's just nuts for users and admins not to have a single "make it right" operation. And for users and admins and packagers, it's a gratuitous pain if the name of that operation changes every few versions. What I want is a single, simple syntax that silently does nothing if there is no db upgrade needed. If something is needed, it just does it, all of it, for whatever version of old database it might be. If there is another upgrade that requires new signatures or otherwise really warrants manual intervention, the automatic command can barf in that case. I don't really care if it's just a script, as long as it comes with monotone in each new version and it does the job right. It might be nice if this included an option to make a backup copy of the database for you, since an automatic upgrade script calling this is going to do that anyway. For users, I think it might be nice to have a command-line and .monotonerc option to just do any necessary upgrades implicitly with any command that now errors out telling you to do the upgrade. monotone version: ----------------- 0.34
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.