Hi,
could you include the following function in versioncontrol.module (or in backend, doesn't matter for me). I need it for the git backend to see which branches are already in the database. This is needed because git doesn't track branches, so we will never add/delete branches in an $operation.
/**
* Returns an array of all labels in a repository, and if $type is given, filters by TAG or BRANCH.
*
* @param $repository As given by the API
* @param $type Set the filter type, possibel values are VERSIONCONTROL_OPERATION_{TAG,BRANCH}
* @return array An array of strings with the label names.
*/
function versioncontrol_get_label_list($repository, $type = FALSE)
{
$query = "SELECT label_id, repo_id, name, type FROM {versioncontrol_labels}
WHERE repo_id = %d";
if ($type !== FALSE) {
$query .= " AND type = %d";
$result = db_query($query, $repository['repo_id'], $type);
}
else
{
$result = db_query($query, $repository['repo_id']);
}
$labels = array();
while ($row = db_fetch_object($result)) {
$labels[] = $row->name;
}
return $labels;
}
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | versioncontrol-get-labels.diff | 3.99 KB | jpetso |
Comments
Comment #1
jpetso commentedI totally want such a function in the API module. However, for consistency with the other getter functions (get_operations(), get_repositories(), get_accounts()), I'd like to see a function signature like
versioncontrol_get_labels($constraints = array())with repository and type being optional constraints that are added to the query if they exist. Later on, we could also add a constraint for label ids, affected operations or whatever.If the API and apidox are ok, those additional features can of course wait until someone (for example, me) is motivated to implement them - I've got no problem adding partial solutions if they're prepared to stand the test of time :P
Comment #2
jpetso commentedPlease have a look if the attached patch works for you.
I decided to leave the repository as separate (required) argument, as the repo_id is not a standard element of label arrays, which would make the set of labels ambiguous if labels are retrieved from different repositories. Probably the feature of requesting labels from different repositories won't be needed anyways.
Comment #3
CorniI commentedlooks good. But as a side node, I just discovered that further optimization of my code made the function unnecessary for the moment (You know, code is still in flux). But ithisis a handy func, so please include it anyways, we could need it later.
Comment #4
jpetso commentedk, committed. I don't mind if you don't need it at the moment, as I wanted this function anyways (but didn't get around to code it until now).