Calling the commitlog for projects with the current project-6.1.x-dev and RC1 of the Version Control API is not working - the Version Control API expects constraints to be delivered in a different format.

Changing versioncontrol_project_commitlog as follows fixes this issue for me:

/**
 * Page callback for 'node/%versioncontrol_project_node/commitlog'.
 */
function versioncontrol_project_commitlog($node) {
  drupal_set_title(t('Commits for @title', array('@title' => $node->title)));

  if ($node->type == 'project_project') {
    project_project_set_breadcrumb($node, array(l($title, 'node/'. $node->nid)));
  }

  $constraints = array();
  $constraints['repo_ids'][] = $node->versioncontrol_project['repo_id'];
  $constraints['paths'][] = $node->versioncontrol_project['directory'];
  return commitlog_operations_page($constraints);
}
CommentFileSizeAuthor
versioncontrol_project.commitlog.patch913 bytesAnonymous (not verified)

Comments

jpetso’s picture

jpetso commented
Status: Needs review » Needs work

Your patch is not really wrong and would solve the problem from the current point of view, but is not really the right solution either. versioncontrol_project is specifically tracking nid<->operation associations, and provides the 'nids' constraint as a more performant, more scalable and (most importantly) more future proof possibility of associating version control operations to projects. (With a little luck, multiple repositories will be possible per project - like for distributed version control systems - and the repo_id/directory association won't be as straightforward anymore as it is now.)

If that direct association doesn't work then it's a bug indeed, but should be fixed at the core, which is either: a) the generation of the operation query, or b) the tracking of nid<->operation associations. I'll need to test sometime soon anyways, but you could help by determining which one of those two it might be.

Please have a look at your {versioncontrol_project_operations} and look what's in there - all operations from {versioncontrol_operation} (or most, until cron or a hook script catches them) should be tracked in there. "0" as project nid means "no association", while not appearing at all means "not yet tracked". Maybe that table reveals where the error lies.

In case the above doesn't lead to anything, you might try to print the operation SQL query from the versioncontrol_get_operations() function (called $query) with drupal_set_message() (or dpm() from Devel, which also prints the parameters quite nicely).

Anonymous’s picture

Anonymous (not verified) commented

Thanks for the feedback. I won't be able to work on this today or tomorrow, but I'll continue with it.

Anonymous’s picture

Anonymous (not verified) commented

It is working w/o the above patch now.

Are the commit-nid-relations build after collecting the commit messages?

jpetso’s picture

jpetso commented

They should be built when new operations get recorded, and there's a cron hook to catch any operations that somehow slipped the operation recording hook (e.g. because versioncontrol_project was disabled for a while). New operations get recorded instantly when using hook scripts, or also on cron when using log fetches.

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs work » Fixed

This could explain it, thanks.

It's working for me w/o any patch, so I'm setting this to fixed.

Status: Fixed » Closed (fixed)

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