Modernize updatecode command

I saw that myself.

it's a biiit different because it is calling hooks in it's handlers, but it could definitely benefit from having rollback support

Yeah - I don't think we need the generic hook (pm_post_update) here any more - we do need to keep the version control engine function in though - that really needs to be applied after each update, not after the whole batch.

One big thing I want to do here, that should clean it up a lot is to move all the backup stuff to be a version_control engine (albeit a kinda clunky one).

There are various other things we could do - I want to push all the "big" operation functions into their own files, as I did with updatecode (and also move some of the updatecode only functions into the right file).

Oh - yes, the rollback stuff would be very cool too and should be interesting to write (what with the different version control engines in play). This is dependent on moving the backup stuff into an engine first, I think.

Made a start on this, but not enough to review yet.

I am adding a ['signature'] element to the engine array for hook_engine_version_control, so we could do a directory existence check to detect if that version control is active in a particular place - so for svn we have 'signature' => '.svn'. The idea is that you could provide a comma separated list of engines - e.g. --version-control=svn,backup (which would be the default) and it would use the first one that "matches". We can't include the tests in the engines themselves, since you can only load one engine at a time.

Questions:
- Is this a useful approach - anyone have any better ideas?
- Are directory checks sufficient, or should we be doing something more precise (like an exec "svn info !dir" for example) - or should we sommort both types of signatures?
- Is this worth abstracting out (into drush_include_engine() for instance) - it seems like there might be other uses for this kind of "smart fallback" behavior - the package handlers would seem to be another case.

I'll try and remember which computer I left this (proto) patch on...

Subscribe

OK, here is a patch. I have tested it pretty thoroughly with the various combinations of update handler and version control, as well as the various error conditions. It could use some testing across different platforms (e.g. OS X and Fedora). The exception is for bzr, which I just did a theoretical update on - if a bzr user could sanity check this that would be great.

I had to hold back from going crazy and rewriting everything, but hopefully this is a good first step, and I think puts us in a good place to be able to record "unhacked versions", check for patches, and support themes etc. There are still a few TODOs (such as making the package managers use a single array param as version control now does).

The only major architectural change is that version control engines are now namespaced (via a simple class interface) so we can load more than one at a time without function naming conflicts. This avoids a potential edge (or not so edge) case we have now where you have some modules (e.g. in sites/all) versioned and some (e.g. sites/default) unversioned, or versioned with a separate system. If folks like the idea I think it is worth considering moving the factory function up into drush.inc so as the standard way you use engines (we would need to coordinate this change with provision, of course).

Here is a test script I used for svn sites:

rm -rf modules/votingapi modules/admin_menu modules/token
svn rm modules/votingapi modules/admin_menu modules/token
svn ci modules -m"blah"
drush dl -d votingapi-2.0 admin_menu-1.0 token-1.10
drush -y refresh
drush -y enable votingapi admin_menu token
drush updatecode -dy

and "backup" sites:

rm -rf modules/votingapi modules/admin_menu modules/token
drush dl -d votingapi-2.0 admin_menu-1.0 token-1.10
drush -y refresh
drush -y enable votingapi admin_menu token
drush -dy updatecode

Committed a bunch more re-factoring over the last couple of weeks - mostly moving things around to simplify the structure, standardize the naming and pass more information down to the various engines (this is needed for future improvements). I have fixed quite a few bugs also due to a nice test script - I will go through and close off any issues that are resolved.

I think that is the most disruptive part over - the next round of changes will be more substantive, so will get their own issues.