Issue 60: pick a single command for automatable db upgrades, and stick to it

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?