Deleting a tag on a single file removes relationship between the tag and project

Weird, somehow the drupal.org DB didn't know about your tag, even though it's clearly in CVS. Can you explain how you created the tag in the first place?

Anyway, I just manually added a record to the drupal.org DB about this tag for your project, so you should now be able to create a release node for it...

cheers,
-derek

Ahh, yes, indeed! A known bug. Drat, I can't believe I still haven't gotten around to fixing that. :(

In fact, while I'm sure I've written about this before (maybe over in http://drupal.org/node/90968), it should really be its own separate bug.

In fact, we might as well fix this via the version control API, not just cvs.module, to help encourage the vc_API roll-out on d.o...

this keeps hitting people (e.g. http://drupal.org/node/192422).
jpetso, any thoughts?

Version Control API handles this stuff completely different - it doesn't store the current state of tags and branches but only "operations", where one tag can occur multiple times (e.g. "DRUPAL-6--1-0 created with the following files: (...)", "DRUPAL-6--1-0 deleted from the following files: (...)"). So with the CVS backend, you need to query CVS directly for that, which I think is the less error-prone approach than tracking states in the database.

So this bug only applies to cvs.module. The code that's responsible for this (in xcvs-taginfo.php) goes like

  if ($op == 'add') {
    mysql_query("INSERT INTO cvs_tags (nid, tag, branch) VALUES ($nid, '" . mysql_escape_string($tag) . "', $branch)");
  }
  else {
    mysql_query("DELETE FROM cvs_tags WHERE nid=$nid AND tag='" . mysql_escape_string($tag) . "'");
  }

That means the tag is automatically deleted for the whole project if just one file of that project has been unassigned that tag. I could imagine that the most sensible fix for that would be to check if there are any files left in the project directory that still have this tag assigned, and if not, delete it, otherwise keep it.

Should I try a fix in cvs.module or rather work on getting the CVS backend up to speed a little more?

Hunmonk and I discussed this on IRC, and though I am certainly no CVS expert, neither of us could come up with a way to actually do this.

My feeling is that spending an hour or two looking into solutions for this is not an efficient use of time, given that this doesn't appear to come up all that often and given that cvslog really should have been end of lifed by now anyway.

My suggestion was that we could at least document this undesired behavior and present a workaround, like possibly committing a file to the project with the just-deleted tag and then deleting that file. I don't know if this would actually work, however.

i believe a better workaround would be to tell people to explicitly tag files, instead of tagging all then deleting a tag on a file.

this would only matter in the case where there was a versioncontrolled file in the directory that the author didn't want tagged -- otherwise they could just simply issue cvs tag [tagname] and be done with it.

Hunmonk and I discussed this on IRC, and though I am certainly no CVS expert, neither of us could come up with a way to actually do this.

What I'd like to see in a versioncontrol based solution is that once we know of a changed (added/removed/moved) tag, we query CVS for the new list of tagged files and store this list for further processing by the release scripts. Like,

/**
 * Implementation of hook_versioncontrol_tag_operation().
 */
function versioncontrol_release_versioncontrol_tag_operation($tag_op, $tagged_items) {
  foreach (versioncontrol_release_affected_projects($tag_op, $tagged_items) as $project_nid => $affected_project_info) {
    $project_item = versioncontrol_get_parent_item(
      $tag_op['repository'], $affected_project_info['files'][0] /* any affected (tagged) file as starting point */,
      $affected_project_info['project']['directory']
    );
    // Retrieve all items inside the project directory item (which also includes the tag as information).
    $project_tagged_items = versioncontrol_get_directory_contents(
      $tag_op['repository'], $project_item, TRUE /* recursive */
    );
    if (!isset($project_tagged_items)) {
      continue; // couldn't retrieve the project directory item or its contents... shouldn't happen though.
    }
    // Store the new list of tagged items in the database for further processing by the release scripts,
    // replacing any older listings. If $project_tagged_items is empty, the release tag will be deleted.
    versioncontrol_release_set_tagged_items_for_project($affected_project_info['project'], $tag_op['tag_name'], $project_tagged_items);
  }
}

That would indeed make it possible to have an accurate file listing on tag additions and modifications alike.

[edit] Bugfix, and documentation of the "no more items in there anymore" condition.

Ok, a quick fix for cvs.module goes like this:

• Call cvs -qnf -d $root rls -RPl -r $tag $path on the repository (like in cvs_fetch_repository(), same $repo variable too), where $tag is a tag specification like "DRUPAL-6--1-0" and $path is the project directory without leading slash, like "contributions/modules/versioncontrol".
• Check if any line in the result starts with "----" (four dashes), which is the start of any line for normal files.
• If you've got such a line, keep the entry. (At least one file with that tag still exists.) If no such line exists, delete the tag.

That would work. Depending on your ambitiousness, you can also copy the "cvs login" snippet from cvs_fetch_repository() so that it doesn't break for remote repositories, and sooner or later this same command will also need to be used for implementing versioncontrol_cvs_get_directory_contents().

@jpetso: i don't think we can use this exact procedure, as taginfo is called before the tag operation happens. sounds like we'd need to modifiy the procedure, or find a posttag hook.

whoo, finally a really good argument for having used posttag in versioncontrol_cvs... not that this helps you in any way :P
sorry about that, i totally forgot that cvslog still has a combined script for the pre- and post-tag operations.

A quick look through 'info cvs' reveals that there's no support for transactions at all and you have absolutely no chance to invoke cvs on changes that will only be committed afterwards. So either it's moving the non-access-checking code to posttag, or waiting for versioncontrol_cvs.

i've had enough of this bug. with EOL approaching, i have no interest in any major refactoring. we're just going to have to live with this one until versioncontrol_cvs is ready.