Closed (fixed)
Project:
Version Control API
Version:
6.x-2.x-dev
Component:
API module
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
15 Dec 2010 at 06:25 UTC
Updated:
15 Apr 2014 at 22:25 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
sdboyer commentedYeah, 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.
Comment #2
marvil07 commentedSome code pieces why I think this needs work:
commit_restrictions/commit_restrictions.module: assumes operation labels have action
includes/VersioncontrolOperation.php: some code(never used? :-/) is hardcoding the action data member
includes/controllers.inc: labels inside operations still have action data member
Comment #3
eliza411 commentedTagging for Git Sprint 8
Comment #4
marvil07 commentedComment #5
marvil07 commentedNot ready before hard code-freeze, so changing tag.
Comment #6
marvil07 commentedComment #7
marvil07 commentedAfter 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.
Comment #8
sdboyer commentedSo...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
VersioncontrolGitRefChangeon the generic-reposync branch in vc_git for some insight into what I'm talking about.Comment #9
sdboyer commentedLemme make that easier with a link to the class: http://drupalcode.org/project/versioncontrol_git.git/blob/refs/heads/gen...
Comment #10
marvil07 commentedAfter 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.
Comment #11
marvil07 commentedBetter title
Comment #12
marvil07 commentedOk, here it is the commit patch I pushed :-)