Integrate with triggers and the activity module

There's already an implementation of hook_token_list() and hook_token_values() in versioncontrol.rules.inc, we might want to merge these two (generally, I find your token names more sensible) and put the token hooks into versioncontrol.module itself.

Also, VERSIONCONTROL_OPERATION_{BRANCH,TAG} is not necessarily the creation of a branch/tag, but might also tell that the branch/tag is renamed or deleted. Lacking conditions, triggers are generally not smart enough to handle that kind of distinction, so we might split those cases up into different trigger hooks.

Other than that, the patch looks good.

moving to 2.x where it should be included after dbtng and end up with #595930: from github to d.o cvs(aka start 6.x-2.0-dev and get access)

since an activity table is planned for 2.x: #879600: Meta: introduce an activity stream separate from commit logs, we should re-think how to do this

We now have basic views integration, and we are willing to use that to replace the commit log module functionality. So it seems like views is going to be the place where the activity is going to be shown. Any recommendations on #879600: Meta: introduce an activity stream separate from commit logs would be appreciated.

I really do not know if there are consensus about integrating with activity and trigger modules, so keeping this open until more people give opinions.

Linked back from #879600-14: Meta: introduce an activity stream separate from commit logs, I think this can be a good solution instead of having our own complete activity module.

tagging

A list of activity modules from Similar Module Review group at g.d.o. (IIRC there was no decision about which module to use).

So I'm a maintainer of the Activity module and know that it is well suited for some of the performance concerns that Sam brought up over the phone. The main one being that Activity will record a full message at the time an action happens, and then simply display the message at display time (through views) instead of using the variables to dynamically create messages.

This is efficient, but can lead to some messages becoming out dated. For instance, if you operate upon a node and record that update (something like "User updated the page 'this is an update'.") and the title is a link to the node, and someone changes the title of that node later, the first activity message will not change to reflect the updated title.

This problem was solved in Activity by being able to regenerate activity messages through bulk operations. The original object data (user, node, etc) is still saved in another table, as well as the activity message's template (ex: "[user-name] updated the page '[node-title]'.") so that these problem can be fixed, but this is not an automated process, it is manual, which may be of concern.

Activity module also is loosely based on actions/triggers. If a module has action integration, there is a just a bit of extension to those actions that needs to be done in order to make them compatible with Activity module. This extension is basically due to the fact that core action api is a bit limited when it coes to the data that is passed around.

For more details, pleas take a look at the DEVELOPER.txt

We started more discussion of this issue in #879600: Meta: introduce an activity stream separate from commit logs - but this is a better thread - more specific to Activity integration which I'm working on as I can.

For reference, from that thread, the messages we want to at least start with are:

[username] [action:pushed] to [branch-name] at [project-name] [time-ago]
[username] [action:created/deleted] [branch-name] at [project-name] [time-ago]
[username1] granted [username2] access to [project-name] [time-ago]

Also started another patch to #1020220: Reintroduce token integration which we'll need before this can be complete since Activity needs tokens to create the messages as described above.

So after some time trying to figure this all out, here's what I've come up with so far.

Activity module usually works as a recorder of events, so that when hooks fire (think nodeapi: insert) we can capture the object and record a message about that object related to the hook that is happening.

However, Version Control API isn't really _doing_ the things we're want to record. Versioncontrol itself is a recorder, or analyzer of actions that happen within a repository. As such, there is not really a hook that is fired when recording a commit. The closest thing I can really find that is comparable is the fetchLogs(). Again though, Activity works off of hooks that report things - but Versioncontrol is OOP and fetchLogs() is not a hook that announces itself here.

This all leads me to the assumption (so far) that while we may be able to use some of Activity's functions directly - the way we designed the API is not going to work with Versioncontrol. I think we would have to call Activity functions directly within Versioncontrol's functions/methods, and I'm not sure that is entirely desirable at all.

This is also the problem with the patch that has been supplied already. In trying to do trigger/action implementation, the code makes the assumption that there are functions called 'versioncontrol_commit', 'versioncontrol_branch', and 'versioncontrol_tag'. There aren't, unless I'm totally just way too tired at this point and up too late trying to do this stuff ;)

I'd really like to get Scott's take on this and see what he comes up with as well. He's worked on the D7 version of Activity which is OOP and he may have a better understanding of what we really need to do here to accomplish anything with Activity.

@sirktree there are a whole bunch of hooks: http://drupalcode.org/viewvc/drupal/contributions/modules/versioncontrol...

Why couldn't those hooks be part of a trigger implementation, and then an Activity implementation?

wow - yes - i had no business trying to code so late last night. Thanks Scott

we have the gsoc-activity branch, which is where this'll happen whenever we get to it. kicking it down the road.