API changes from 5.x-2.x to 6.x-1.x

API module

• New menu wildcard loaders. The '%versioncontrol_repository' loader seems suitable for wide-spread usage, whereas '%versioncontrol_user_accounts', despite being public, will probably not be used a lot outside of the API module itself.
• New access callbacks: versioncontrol_admin_access(), versioncontrol_user_access() and versioncontrol_private_account_access(). Please use versioncontrol_admin_access() only inside functions but not as access callback for menu items, stick to array('administer version control systems') for the item's 'access arguments' property for that purpose.
• The 'user/%/edit/versioncontrol' path now leads to either a list of repository accounts or directly to the account edit form in case the user has only one account on the site. 'user/%/edit/versioncontrol/%' does the same for repositories (arg(4) being the repo_id), and 'user/%/edit/versioncontrol/%/%' (arg(5) being the VCS username inside that repository) always leads to the edit form of the respective account. This change was needed due to the new menu system and also prepares for future support of multiple accounts per user and repository.
• hook_versioncontrol_extract_repository_data($form_values) is now hook_versioncontrol_repository_submit(&$repository, $form, $form_state). Also, you can now use the $repository['data'][$module] array have minor bits of repository-specific data automatically stored in the new {versioncontrol_repositories}.data column (since update 6102). Try to keep all too large data out of this array, as it's getting loaded on every repository access.
• hook_versioncontrol_extract_account_data($form_values) is now hook_versioncontrol_account_submit(&$additional_data, $form, $form_state).
• Various form elements and form_ids in the versioncontrol.admin.inc and versioncontrol.pages.inc forms have been changed, mostly due to changes in the Drupal 6 Form API. Please have a look at the form callbacks in case you did form_alter stuff, and adapt your hook_form_alter() implementations accordingly. (You'll need to do that anyways because the hook_form_alter() parameters changed as well in Drupal 6.)
• versioncontrol_get_operations() has changed its arguments 2-4 ($result_count, $page, $limit) to an $options array and now makes it possible to directly use pager_query() or db_query_range() in order to retrieve the operation result. Calls with a single $constraints parameter do not need to be changed.
• Also, versioncontrol_get_operations() supports a new constraint called 'user_relation', and versioncontrol_project (if enabled) provides the constraint 'project_relation'.
• hook_versioncontrol_alter_operation_constraints() is now hook_versioncontrol_operation_constraints_alter(), conforming to Drupal naming standards. In addition, hook_versioncontrol_operation_constraint_info() has been introduced which allows to define additional "native" (direct SQL) constraints for the operation query in versioncontrol_get_operations().
• versioncontrol_format_revision_identifier() and versioncontrol_format_item_revision() have been renamed to versioncontrol_format_operation_revision_identifier() and versioncontrol_format_item_revision_identifier() for consistency.
• versioncontrol_get_item() changed its (optional) $revision parameter to a (similarly optional) $constraints array that can contain either the mentioned revision or a label as constraint. That enables the caller to retrieve items in a more targeted way with less confusing indirections.
• versioncontrol_is_account_authorized() (as well as hook_versioncontrol_is_account_authorized()) has the argument order swapped, for better consistency: first the container object, then the exact item in question (in this case, that item is the uid).
• New API function versioncontrol_path_contains(): returns TRUE if one path is a child path or the same as another.
• New API function versioncontrol_ensure_label(): makes sure that a given label exists in the database, and adds the label_id property if it didn't before.
• New API function versioncontrol_get_labels(): retrieves a set of labels for a given repository, optionally limited by a set of constraints.
• New (optional) API function versioncontrol_export_directory(): exports the contents of a directory in the repository into a local directory. Imagine "cvs export", "git archive" and the likes.
• versioncontrol_get_file_copy() has been renamed to versioncontrol_export_file(), for naming consistency with the above versioncontrol_export_directory().
• Operation labels can now be modified through the API by backends, which will trigger hook_versioncontrol_operation_labels($op='update'). For completeness, the same hook is also called with $op values 'insert' and 'delete' at the same time when hook_versioncontrol_operation() is invoked. See hook_versioncontrol.php for API documentation if you want to use that new hook.
• Removed versioncontrol_get_user_statistics() in favor of the new API function versioncontrol_get_operation_statistics() which provides approximately the same functionality but in a manner that is scalable (direct database query instead of manual operation counting) and more flexible (can retrieve statistics about any given set and grouping of operations, not just grouped by uid).
• theme('versioncontrol_account_username') has changed parameters; the previous $prefer_drupal_username and $format parameters are now part of an $options array.
• theme('versioncontrol_user_statistics') has changed scope and parameters, and is now theme('versioncontrol_user_statistics_table'). In addition, theme('versioncontrol_user_statistics_item_list') and theme('versioncontrol_user_statistics_account') have been introduced.
• Removed versioncontrol_get_repository_registration_message() in versioncontrol.pages.inc. You probably never used or even noticed it, no need to mourn for that function.
• The "Allow unauthorized commit access" option is now set per repository instead of global.

Backend-only changes

• The [versioncontrol_backend]_format_revision_identifier() function now takes a $repository parameter instead of the whole $operation array, because jpetso was too stupid to consider the item revision formatter function (which does not provide any $operation array) for the 5.x-2.x API change. (Sorry for that.) In turn, you can remove the [versioncontrol_backend]_format_short_revision_identifier() implementation if you had any.
• There are two new, optional API functions making it possible to have different VCS usernames than just the default "alphanumeric characters" username scheme. The functions are called [versioncontrol_backend]_account_username_suggestion() and [versioncontrol_backend]_is_account_username_valid(), and the API documentation can be found (as always) in versioncontrol_fakevcs.module.
• Operation labels can now be modified without direct database access even after the operation has been created, by calling the new API function versioncontrol_update_operation_labels().

Commit Log

• Renamed commitlog_send_notification_mail() to commitlog_notification_mail(), because it now takes the $send parameter optionally (as drupal_mail() does) and therefore doesn't send the mail if $send == TRUE.
• commitlog_account_url() is now commitlog_get_account_url(), and returns only the URL instead of the whole link.
• New function: commitlog_user_notification_mail() (in addition to commitlog_notification_mail()) - makes use of various user properties (language, mail address) to send a notification mail.
• New function: commitlog_get_url($constraints) - retrieves the URL for the given constraints.

Project node integration

• Removed versioncontrol_project_get_projects_for_operation(), use versioncontrol_project_get_projects(array('vc_op_ids' => array($vc_op_id))) instead. (This change has been brought to you by the {versioncontrol_project_operations} table which enables project/operation associations by means of direct SQL queries.)
• Removed versioncontrol_project_get_statistics(), in favor of direct SQL queries.