provide CLI tool for updating a site from CVS based on update_status data

My personal opinion is to point those people at the releasemonitor module, and see if we can convince releasemonitor to exist peacefully with update status.

a compromise solution:

• deploy-from-CVS people learn how (or develop tools) to update their sites not to the end of the branch they care about, but to the latest official release tag (e.g., instead of cvs update -r DRUPAL-5, they do cvs update -r DRUPAL-5--1-3 to get the 5.x-1.3 version of the module in question).
• module maintainers put version = "$Name$" in their module's .info files (already suggested in the docs, and appears to be mostly common practice).
• we add some code to this module (already mostly written by webchick, back when she thought it might have been in core for the version column on the admin/build/modules page), to parse CVS-style version = "$Name: DRUPAL-5--1-3 $" version strings from the .info file and convert that into the a) human-readable and b) XML-RPC request-friendly version format ("5.x-1.3").

this would require no extra work for module maintainers (except following the existing suggestions for writing their .info files in the first place), no changes to the packaging scripts, and little extra code in here. it would require more work for the deploy-from-CVS crowd, but arguably, to use a better system (i.e. still run official releases, but upgrade/deploy with cvs instead of tarballs). this would allow them to submit bug requests with real version info, too. ;)

in IRC, i had a little debate with killes and merlin about http://drupal.org/node/116131 ("Automatically create a LATEST tag"), where i was explaining why i didn't like that approach. merlin mentioned my comment #2 above, and said in jest, "With a little nudging, that could probably even provide the cvs commands and you can just cut & paste"...

over lunch, i thought more about this (and the LATEST tag stuff), and actually think this "provide the cvs commands" idea is brilliant, and answers the "someone needs to build tools to help the deploy from CVS crowd" concern. check it out:

1. update_status_cvs.module knows what modules you have installed.
2. it does the XML-RPC call to find out the latest officially released versions.
3. if the only version info in your .info files is vague (e.g. version = "$Name: DRUPAL-5 $") it assumes you're out of date (even if that's not true), and flags it as such.
4. if the .info file has specific version info (e.g., you updated from an official release tag like DRUPAL-5--1-3, it knows how to compare this version with the answer from XML-RPC.
5. for any "out of date" (either known to be out of date, or modules with unknown version info), update_status_cvs.module maps the version numbers it got back from XML-RPC into CVS tags (which is trivial, given the conventions), and knows what the latest official release tags of *your* installed modules are. no parsing 'cvs status', etc.
6. it prints a page of cvs commands for you to run:
   

    cvs co -r DRUPAL-5--1-3 modules/views
    cvs co -r DRUPAL-5--1-1 modules/signup
    cvs co -r DRUPAL-5--2-2 modules/project
    ...
    

   the page could even know, care of drupal_get_filename() what directory to use, so it could be smart enough to tell you stuff like:

    cvs up -r DRUPAL-5--1-3 sites/all/modules/views
    cvs up -r DRUPAL-5--1-1 sites/foobar/modules/signup
    cvs up -r DRUPAL-5--2-2 sites/foobar/modules/project
    cvs up -r DRUPAL-5--1-2 modules/devel  (yeah right, if moshe ever made official releases...)
    ...
    

   obviously, the page would tell you to cd into your site root first, and make sure you've got your CVSROOT env set, blah, blah...

7. once you ran all these commands, if you checked your module update status again, every module would have valid version info, and update_status_cvs.module would be able to accurately tell you that your site is now up to date.
8. someone makes a new official release of signup
9. you check for updates again the next day, and now, the answer from XML-RPC disagrees with the (known) version info of your locally checked out copy (since you used an explicit release tag, neither the moving-target branch (DRUPAL-5), nor a moving target tag (D5-LATEST, etc)).
10. for extra credit, update_status_cvs.module could even form_alter() your main modules page to put the nice human-readable version numbers into the version column for you. ;)

the *ONLY* potential snag is that if you checkout straight from CVS, your .info files don't have the "project" attribute (those get added automatically by the packaging script for the tarballs). however, 99% of the time, the directory name of the module will match this, since on the project node, it's required that the "Project short name" (which is used to generate the path aliases) matches the directory in CVS. ;) so, if there's no "project" in the .info, we just look at drupal_get_filename() and try using that. the only people this would break things for are the ones who intentionally rename their directories once they checkout from CVS, and i'm definitely not interested in spending too much time making *their* lives easier. if they're going to rename the dirs, they're smart enough to add a "project = original_name" to their .info files if they want all this to keep working nicely.

upon further consideration and discussion in IRC...

whereas, the only people deploying from CVS *will* have shell access, and,
whereas, if you already have to login to run the cvs update commands...

therefore be it resolved that this "update_status_cvs.module" actually become a "update_your_site_from_cvs.php" CLI script. instead of printing out cvs commands you should run in a browser window, the script just runs them for you given the right arguments.

so, the UI stuff and changes to update_status.module still knows about parsing version = "$Name: ... $" junk, making things human readable and nice, etc. but, all the talk of "here are the cvs commands to run to get up to date" are handled via this CLI script. best of both worlds. ;)

Great suggestions...

>to update their sites not to the end of the branch they care about, but to the latest official release tag (e.g., instead of cvs >update -r DRUPAL-5, they do cvs update -r DRUPAL-5--1-3 to get the 5.x-1.3 version of the module in question).

oh yes please... I need that... module updating became a huge hassle single the introduction of the bigger official release tags... one script going thru the CVS to pinpoint the exact tag to be the latest offical would really help stabilitze my drupal sites

10-4 on the CLI-thoughts... frankly, auto updating via web would be nice, but the security implications of having the apache "nobody" user performing CVS commands are still to be solved...

Tracking this since it relates to http://drupal.org/node/116131

subscribe

for sanitizing the CVS $Name$ tag and branch based version strings into the human-readable equivalents, see http://drupal.org/node/146352.

we can't accomplish this plan until http://drupal.org/node/150316 is done. if you care about this issue, please look there.

subscribing.

perhaps this can be done via http://drupal.org/project/drush and the new drush_pm.module

Yes - we should also look at the upcoming DAST SoC project, which is working on automating the deployment of a site. (Perhaps make DAST the 'backend' of the drush command line installer?)