bugmonotone - Bugs: bug #19518, pick a single command for...


You are not allowed to post comments on this tracker with your current authentication level.

bug #19518: pick a single command for automatable db upgrades, and stick to it

Submitter:  Roland McGrath <roland>
Submitted:  Thu 05 Apr 2007 09:04:18 AM UTC
Category:  command line UI Severity:  3 - Normal
Item Group:  feature request Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
mtn version --full: 


  Spam posted by anonymous
Mon 16 Apr 2007 09:27:38 PM UTC, comment #1: 

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...)


Thomas Keller <tommyd>
Group administrator
Thu 05 Apr 2007 09:04:18 AM UTC, original submission:  

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.

Roland McGrath <roland>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by tommyd (Posted a comment)
  • -email is unavailable- added by roland (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code