For rolling out the CVS backend on drupal.org, we need to implement versioncontrol_cvs_get_directory_contents(), an implementation of [versioncontrol_backend]_get_directory contents. Quoting the FakeVCS backend's API docs for this function:

/**
 * Implementation of [versioncontrol_backend]_get_directory_contents():
 * Retrieve the set of files and directories that exist at a specified revision
 * in the given directory inside the repository.
 *
 * This function is optional for VCS backends to implement, be sure to check
 * with versioncontrol_backend_implements($repository['vcs'], 'get_directory_contents')
 * if the particular backend actually implements it.
 *
 * @param $repository
 *   The repository that the directory item is located in.
 * @param $directory_item
 *   The parent item of the the items that should be listed.
 * @param $recursive
 *   If FALSE, only the direct children of $path will be retrieved.
 *   If TRUE, you'll get every single descendant of $path.
 *
 * @return
 *   A structured item array containing the exact details of which items have
 *   been inside the directory at the time of the commit, including the
 *   directory itself. Array keys are the current/new paths.
 *   The corresponding item values are again structured arrays
 *   and consist of elements with the following keys:
 *
 *   - 'type': Specifies the item type, which is either
 *        VERSIONCONTROL_ITEM_FILE or VERSIONCONTROL_ITEM_DIRECTORY.
 *   - 'path': The path of the item at the specific revision.
 *   - 'revision': The (file-level) revision when the item was last changed.
 *        If there is no such revision (which may be the case for
 *        directory items) then the 'revision' element is an empty string.
 *   - '[xxx]_specific': May be set by the backend to remember additional
 *        item info. ("[xxx]" is the unique string identifier of the respective
 *        version control system.)
 *
 *   NULL is returned if the given item is not inside the repository,
 *   or if it is not a directory item at all.
 */

The command we probably want to use for this is

  • cvs -qnf -d $root rls -Pl -r $revspec $item_path (for $recursive == FALSE), and
  • cvs -qnf -d $root rls -RPl -r $revspec $item_path (for $recursive == TRUE).

For an implementation on top of versioncontrol_cvs 5.x-1.x, $revspec will be $item['revision'] for file items and for directory items one of the following:

  • $item['cvs_specific']['selected_tag_name'] if this property isset().
  • $branch['branch_name'] where $branch = versioncontrol_get_branch($item['cvs_specific']['selected_branch_id']), if both the item's 'selected_branch_id' property and the resulting $branch are set.
  • Otherwise, skip the -r option and retrieve the contents directly from HEAD.

Of course, the demanding part is to write a parser for the output of that 'cvs' invocation.

Comments

jpetso’s picture

Oops, I just remembered that $item['cvs_specific']['selected_tag_name'] doesn't yet exist in versioncontrol_cvs 5.x-1.x, it's only in HEAD. Anyways, this should probably be coded using versioncontrol_cvs HEAD and versioncontrol 5.x-1.x (until I get versioncontrol HEAD back to a working state).

jpetso’s picture

Version: 5.x-1.0 » 5.x-2.0-rc1
Status: Active » Fixed

This, and the other two functions required for basic repository browsing (versioncontrol_cvs_get_item() and versioncontrol_cvs_get_file_copy()) are now implemented in 5.x-2.0-rc2 and later. Have fun browsing the latest HEAD - and *only* the latest HEAD, currently! - with Repoview.

Status: Fixed » Closed (fixed)

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