action was used for label operations(tag and branch operations), and it end up in the class, but we need to remove it, since it is not the right place. This seems to be trivial, but opening an issue to make sure we are not breaking some code anywhere(git grep action shows at least code in commit_restrictions module, operation entity and versioncontrol.module file to be reviewed).

Comments

sdboyer’s picture

Status: Needs review » Reviewed & tested by the community

Yeah, the action corresponds to the op/label combination, not directly to a label itself. It ought to be removed. The patch looks right to me, and doesn't break tests.

marvil07’s picture

Status: Reviewed & tested by the community » Needs work

Some code pieces why I think this needs work:

commit_restrictions/commit_restrictions.module: assumes operation labels have action

 foreach ($operation['labels'] as $label) {
   if ($label['action'] != VERSIONCONTROL_ACTION_DELETED) {
     return FALSE;
   }
 }

includes/VersioncontrolOperation.php: some code(never used? :-/) is hardcoding the action data member

    foreach ($this->labels as $label) {                                       
      // first, ensure there's a record of the label already                  
      if (!isset($label->label_id)) {                                         
        $label->insert();                                                     
      } 
      $values = array(
        'vc_op_id' => $this->vc_op_id,
        'label_id' => $label->label_id,
        // FIXME temporary hack, sets a default action. _CHANGE_ this.        
        'action' => !empty($label->action) ? $label->action : VERSIONCONTROL_ACTION_MODIFIED,
      );
      $insert->values($values);                                               
    }

includes/controllers.inc: labels inside operations still have action data member

  protected function extendData(&$queried_entities) {
    parent::extendData($queried_entities);
    $query = db_select('versioncontrol_operations', 'vco');
    $query->join('versioncontrol_operation_labels', 'vcol', 'vco.vc_op_id = vcol.vc_op_id');
    $query->join('versioncontrol_labels', 'vcl', 'vcol.label_id = vcl.label_id');
    $query->fields('vco', array('vc_op_id'))
      ->fields('vcol', array('action'))
      ->fields('vcl'); // add all the label fields
    // build the constraint list
    $operation_ids = array();
    foreach ($queried_entities as $entity_data) {
      $operation_ids[] = $entity_data->vc_op_id;
    }
    $result = $query->condition('vco.vc_op_id', $operation_ids)
      ->execute();

    // Attach each label to the labels array on the respective operation data.
    foreach ($result as $label) {
      $label->repository = $this->options['repository'];
      $queried_entities[$label->vc_op_id]->labels[$label->name] = $this->backend
        ->buildEntity($label->type === VERSIONCONTROL_LABEL_BRANCH ? 'branch' : 'tag', $label);
    }
  }
eliza411’s picture

Issue tags: +git sprint 8

Tagging for Git Sprint 8

marvil07’s picture

Assigned: Unassigned » marvil07
marvil07’s picture

Assigned: marvil07 » Unassigned
Issue tags: -git phase 2 +git phase 2 leftovers

Not ready before hard code-freeze, so changing tag.

marvil07’s picture

marvil07’s picture

Assigned: Unassigned » sdboyer
Status: Needs work » Needs review
StatusFileSize
new4.04 KB
new11.81 KB

After taking a look about what those pieces of code were doing, I end up thinking that decouple it independently will help.

I have done that: I am introducing a new entity, VersioncontrolOperationLabel, which will have the action mentioned here.

I am also attaching the git backend change here con convienience at review time.

@sdboyer: Please let me know your opinion before actually pushing these patches.

sdboyer’s picture

So...hmm. This is a bit of a pickle. This runs us back into the problem that we've really changed the nature of the Operation concept to be representing that of a true, single *commit* - synonymous in centralized, different in distributed. Now, though, we've been doing all this work to introduce the generic events framework, which is what really reflects the network activity action, and is the place that we should actually be recording label-level "actions." So basically, I'm still thinking that removing this field is the way to go; if we reintroduce it, then it should be in the context of those events.

The slight problem there is that we've architected the events system to be even more loosely coupled - there's no longer a single place in the db where we can express an 'action' on a label, as we only define a very basic db table in the core module, and leave it up to the backends to define their own table for extended data. I think this approach is a lot better, but I think it means the code you've written is a dead-end :(

Check out the VersioncontrolGitRefChange on the generic-reposync branch in vc_git for some insight into what I'm talking about.

sdboyer’s picture

marvil07’s picture

Assigned: sdboyer » marvil07
Status: Needs review » Needs work

After a quick IRC talk, I end up agreeing sdboyer point, but this involves chnage db schema to remove action from there too.

I will provide a patch for that.

marvil07’s picture

Title: Remove action data member from branch and tag entities » Remove the idea of operation label actions

Better title

marvil07’s picture

Status: Needs work » Fixed
StatusFileSize
new9.66 KB

Ok, here it is the commit patch I pushed :-)

Status: Fixed » Closed (fixed)
Issue tags: -git sprint 8, -git phase 2 leftovers, -versioncontrol-6.x-2.0-release-blocker

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

  • Commit f67dce9 on 6.x-2.x, repository-families, drush-vc-sync-unlock by marvil07:
    Issue #998684: Remove the idea of operation label actions.
    
    - Remove...

  • Commit f67dce9 on 6.x-2.x, repository-families by marvil07:
    Issue #998684: Remove the idea of operation label actions.
    
    - Remove...