HEAD release always considered Not Supported during cron

I'm seeing the same thing for Event module 5.x-2.x-dev:

Event 5.x-2.x-dev (2008-Mar-11)                 Not supported
Recommended version: 5.x-2.x-dev (2008-Mar-11)

@Junyor: That's actually a bug in cvs_deploy. I just found the problem in both 5.x and 6.x -- see attached patches. Basically, we can't figure out what version the HEAD release is since we don't know the 'project' value early enough in the process. This must have crept in during all the code reorganization as a result of #184664: Support subdirectories inside modules and/or #209242: update.module reports bogus results when .info files are newer than the cached available update data.

@salvis: Even once you apply the d5 patch here to your copy of cvs_deploy, event will still tell you that 5.x-2.x-dev is unsupported, since killes never dealt with the new maintainer settings on his module, so 5.x-2.* is not marked as a supported release (perhaps intentionally). Please report this to the event issue queue and argue with killes about it there. ;)

@dww: I'm not using CVS deploy, only Update Status, and I understand why Event 5.x-2.x-dev is shown as "Not supported!", but there are several problems with what's displayed in this case (see screenshot):

1. There's a semantic clash between "Not supported!" and "Recommended version" — it should say something like "Latest version"
2. Since I have installed the latest version, it should not recommend that I redownload the latest version.
3. The "Not supported!" apparently overrides all other alert messages, so Update Status loses the ability to alert to necessary updates. I can select "Ignore 5.x-2.x-dev" and this will restore the alert functionality for the other modules, but not for Event itself.

I generally like the updated project look and the way it works with Update Status, you did a great job there; this is just an edge case that is not working quite right yet.

@salvis: please, see above. As far as event.module is concerned, the 5.x-2.* series is unsupported. If the maintainer set this intentionally, then you really shouldn't be running this version at all. The main problem is that he has not in fact set it intentionally. And, if you checked out from CVS, you *have* to use cvs_deploy for update_status to work at all.

re: #1: update_status is behaving exactly as expected here.

re: #2: Since you're already running 5.x-2.*, update_status can't recommend you downgrade. All it knows is that what you're running is unsupported. That said, it's a little weird for it to print out a "recommended" version in this case. Please submit that as a separate issue against the update.module component in core and I'll see if there's anything I can do given the string freeze and general difficulty of making any changes in core. If I can't fix the 6.x version, I'm not going to bother fixing the 5.x version for this edge case.

re: #3: You're just talking about what update_status chooses to say on the status report page. It always prints the most scary warning there out of all the possible warnings on your site. If something you're running is unsupported, that's more scary than something that's just out of date. However, it's impossible for that 1 line on the status report page to summarize everything -- if you want the full picture, visit the available updates report, and you'll see the complete mix of everything going on.

Meanwhile, can someone please verify this patch fixes the actual bug here in the CVS deployment case? Thanks.

Sorry to pollute this issue with an unrelated problem — I thought they had the same origin. I've opened #237608: "Recommended version" for unsupported branch as you requested.

P.S. I didn't check out anything from CVS, I just installed the event-6.x-2.x-dev.tar.gz tarball from http://drupal.org/node/206919.

P.S. The snapshot release is now visible on Event's front page, see #237483: Please publish the 2.x-dev releases on the front page.

I installed cvs_deploy today and am very happy, thanks for this great module! I like the update_staus module and I like deploying modules from CVS, to track local changes. Now I can do both : )

My only problem is that I think I am experiencing this issue (HEAD release always considered Not Supported), with cvs_deploy itself.

I installed Drupal from the DRUPAL_6 branch, to get the latest Drupal 6 code. I want the latest Drupal 6 versions of modules, so for example I installed gallery from its DRUPAL_6__1 branch. There is no cvs_deploy DRUPAL_6__1 branch: Drupal 6 development seems to be going on in HEAD: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cvs_deploy/

- so I installed cvs_deploy like so:

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib co -d cvs_deploy contributions/modules/cvs_deploy

This worked, except that cvs_deploy is marked "Not supported!" in update_status. Meanwhile the gallery module is happily marked "Up to date"

I assume if I installed cvs_deploy from the DRUPAL_6__1-0 tag then I would not have this problem. However it would be nice if cvs_deploy supported the latest Drupal 6 version of itself...

Thanks again, Jack

@jablko: Then please apply the patch from #2, confirm that it fixes the problem you're seeing, and report back your results here.

@dww: Unfortunately, the patch didn't help. After the call to _cvs_deploy_version_alter(), the version is still empty.

It looks like _cvs_deploy_version_alter() correctly sets the Tag to HEAD, but cvs_deploy_version_from_tag() expects $tag to be empty if the version is HEAD, thus it ends up returning an empty $version.

Ahh, I see the problem! This only happens if you've run "cvs up -r HEAD" (or something similar), so that the Tag actually is "HEAD". If I do "cvs up -A" to clear tags, dba is seen correctly by cvs_deploy.

Using if (!$tag || $tag == 'HEAD') at the top of cvs_deploy_version_from_tag() fixes this bug without your patch. See the attached patch.

Actually, it looks like both patches are necessary. I've been getting notices that my site was using unsupported releases and sometimes the "Available Updates" page says that DBA is from HEAD. If I reload, the problem goes away. I'll apply your patch again now and see if the problem goes away tomorrow.

It seems that I am still getting notices about available updates even with both patches. When I visit the available updates page, no available updates are listed. I'll see if I can debug this issue further.

@dww: It seems like this only fails when the status is updated via cron. In that case, it seems like cvs_deploy.module isn't loaded, so cvs_deploy_system_info_alter() is never called, the version remains as HEAD, and a notice is sent out. Does that make sense?

Nevermind. cvs_deploy.module is being loaded. But it still only fails when run from cron.

I think I got it: this is happening because there's no cached update_status data for _cvs_deploy_version_alter() to use to figure out the version string of the HEAD release:

1) update_status_cron() calls update_status_refresh(), which invalidates the cache, then calls update_status_get_projects()
2) update_status_get_projects() fires cvs_deploy_system_info_alter(), which calls _cvs_deploy_version_alter()
3) _cvs_deploy_version_alter() finds that the version is HEAD, and tries to get the version info from cache, but the cache is empty, so the version is left as HEAD instead of being updated from the update_status data as it should be

Ahah!. This bothers drush.module as well since we support CVS checkout style deployment.

Ugh, I just revisted this thread. I see what Junyor is talking about in #13, and that's a nasty problem. I'll have to think about what to do about that one. :( Meanwhile, I committed the patches from both #2 and #8 above, which are certainly necessary as a first step. Setting this back to active and changing the title since there's no code for that part of it, yet.

subscribing.

subscribing

Subscribing ... as a developer I can solve it for my module users to branch immediately ... but it's a weird solution.

Assuming #220592-33: Core cache API breaks update.module: fetches data way too often, kills site performance, etc is committed to HEAD and DRUPAL-6, the attached patch will solve this bug (applies cleanly to both branches of cvs_deploy -- HEAD and DRUPAL-6--1).

Since #220592: Core cache API breaks update.module: fetches data way too often, kills site performance, etc went out with 6.11 core today, I committed #19 to HEAD and DRUPAL-6--1. Anyone else willing to verify the end of the DRUPAL-6--1 branch of cvs_deploy works splendidly with core 6.11 so I can cut a 6.x-1.1 release in good faith?

Thanks,
-Derek

It's a beautiful thing when the fix for a problem you just noticed already exists!

current dev works great with 6.11.

Tested current dev with 6.11, works like a charm.

Thanks dww.

Thanks for the tests: cvs_deploy 6.x-1.1

Can't mark this fixed, since this now needs to be backported to D5 once I finish #155450: backport separate {cache_update_status} table and private non-volatile cache API from D6 core and release update_status 5.x-2.4...

Now that #155450: backport separate {cache_update_status} table and private non-volatile cache API from D6 core is fixed, I backported, tested, and committed the attached patch to DRUPAL-5.

Automatically closed -- issue fixed for 2 weeks with no activity.