This is related to http://drupal.org/node/158526 but actually solves a different problem and requires slightly different code, so I'm submitting it as a separate issue.
http://drupal.org/node/208687 and http://drupal.org/node/209242 fixed a critical update_status bug where if the .info files were newer (when someone unpacked a new version of a module) than the last time update_status checked for available update data, the status report would generate bogus results.
that's now fixed for people deploying with tarballs, since when the install the new version, we know the .info files get overwritten with the new values in the tarballs.
however, people who deploy from CVS are usually still broken here, since "cvs update" is likely to send a new copy of foo.module, but foo.info rarely changes.
so, we want to use the identical logic from http://drupal.org/node/158526 to find the most recently modified CVS/Entries file, and store that as the '_info_file_ctime' attribute in the .info file (care of hook_system_info_alter()). That way, when someone does a "cvs up" to deploy an updated release, CVS/Entries will get changed on disk, we'll see a newer _info_file_ctime, and update_status will know to invalidate it's cached available update data and refresh.
This really shouldn't go in until http://drupal.org/node/158526 lands, so I'm submitting this initially marked "postponed", but I wanted to write it up now while it's still fresh in my head.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | cvs_deploy_info_file_ctime_5x.patch | 1.96 KB | dww |
| #2 | cvs_deploy_info_file_ctime_6x.patch | 1.93 KB | dww |
Comments
Comment #1
dwwI committed http://drupal.org/node/158526 to both HEAD and DRUPAL-5, so this is now active.
Comment #2
dwwPatches for both 5.x and 6.x versions. Both are tested, but if anyone else wants to test or review, that'd be lovely. ;)
Comment #3
dwwCommitted to HEAD and DRUPAL-5.
Comment #4
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.