Add Views support for Version Control Operations
| Project: | Version Control API |
| Version: | 6.x-1.0-rc2 |
| Component: | API module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | cweagans |
| Status: | needs review |
I was needing a way to filter commits by software project (/not/ using project.module) and display the commits in a block on the project node. I noticed that Version Control API didn't yet integrate with Views, so I decided to take a stab at it. Patch (against 6.x-1.0-beta3) and screenshot of a views-edit form attached below.
Features so far:
- "Version Control Operations" Views Base Table implementation — allows creating a view that returns every commit across every repository.
- Fields / Filters / Sort types / Arguments:
- Commit Log Message
- Commit VCS Username
- Commit Date
- Commit Revision Number — links to commitlog if installed and if user has access
- Commit Path Terms (*) — links to Taxonomy terms matching commit paths
- Commit Paths
- Repository
- Repository's VCS
- Relationships:
- Commit Author — joins to drupal user account, so all user account fields are available(*) "Commit Path Terms" currently works with Subversion only, and only as a Field and an Argument. It uses the path_trunk repository field to act as a mask on the committed paths — whichever Taxonomy terms match the committed paths are presented as a Field, or filtered as an Argument. For example, if path_trunk is /Student/*/%project/, and if Taxonomy term "Widget Factory" is present, a commit that modifies the file /Student/2009/WidgetFactory/README.txt would be assigned the "Widget Factory" term.
| Attachment | Size |
|---|---|
| versioncontrol-views-0.png | 132.26 KB |
| versioncontrol-views-0.patch | 11.48 KB |
#1
Wow, that's freakin' awesome. I've been shying away a bit from Views support because that circumvents the carefully crafted query of versioncontrol_operations(), but given the 5.x-2.x (and later) table structure it doesn't seem that scary anymore.
<?php+ module_load_include('inc', 'versioncontrol', 'includes/versioncontrol.views');
?>
I believe Views does this by itself when refreshing its cache - this line most probably isn't necessary.
<?php+ $title = 'r'. $data;
+ if (user_access('access commit messages')) {
+ return l($title, "commitlog", array('query' => array('id' => $values->vc_op_id)));
+ }
+ else {
+ return $title;
+ }
?>
The 'r' in front of the revision identifier is very SVN specific. Commit Log has a nice themeing function to make that same link, but it only works on the whole $operations array which I'm not sure we want to fetch here. So let's make use of one of Version Control API's revision identifier formatter functions (which are the basis for Commit Log's revision identifier display, and are not inserting any links). Not having required any formatted revisions yet that didn't come with either the $operation or $repository/$item variables, I had to add a new function versioncontrol_format_revision_identifier() that uses just the $vcs and $revision strings. That'll be in beta4, then, so this code should then look like
<?php+ $title = versioncontrol_format_revision_identifier($data);
+
+ if (module_exists('commitlog') && user_access('access commit messages')) {
+ return l($title, 'commitlog', array('query' => array('id' => $values->vc_op_id)));
+ }
+ return $title;
?>
In the same vein, the
$data['versioncontrol_operations']['revision']handler should deal with a "revision identifier" instead of a "revision number" (think of Git & Co.) and is not numeric but a plain string, so it probably also shouldn't be click sortable (in fact, date is the only appropriate sort column while vc_op_id and revision are not).And finally... would it be possible to split out the "Commit Path Terms" feature into a separate add-on module? It's kinda cool, but it's also a hack and doesn't really fit into the API module itself because it's specific to a single backend implementation. (Plus I had already considered eliminating the VCS specific repository tables and stuff settings like the trunk path into a single "data" serialized array column in {versioncontrol_repositories}. That would probably make your query impossible... besides, do you know if it works on Postgres as well?)
Nevermind the above, I really dig this patch. Good work, hope to see it committed sometime soon.
#2
Taking this on.
#3
Annnnnnnnddd we're back:
I've made the revision number a revision identifier now, so this will work with Git & co.
I've stripped out the SVN specific stuff. It should be implemented in versioncontrol_svn. I've also stripped out the Commit Path Terms. The attached patch provides basic views integration, and nothing fancy.
Would love to see this committed soon. http://drupal.org/project/software_projects is in need of this functionality =D
#4
Doing some testing, I discovered some bugs. Will be back with a new patch in a bit.
#5
Woo for new patches.
#6
Thanks again for the work on this. I'll aim to review it properly tomorrow (Friday) night.