Differences

This shows you the differences between two versions of the page.

--- mantisbt:source_control_integration_requirements [2007/09/28 15:27] – Sectioning jreese
+++ mantisbt:source_control_integration_requirements [2011/11/16 07:40] (current) – The page rendering was broken (maybe since new PHP version on mantisbt.org). Added new line to fix it at end of file. atrol
@@ Line 2: / Line 2: @@
 **Author**: John Reese
+**Status**: Draft
 ===== Introduction =====
@@ Line 8: / Line 10: @@
 The goal with this feature is to provide a VCS-agnostic interface which will allow for direct integration with version control software, but will not favor a single system.  This feature will attract many businesses and projects which need direct integration with their source control system, some of which may have multiple repositories in various VCS systems.
 ===== Current Approach =====
+Currently, Mantis has a simple interface for receiving information from a VCS system, relying on the VCS's post-commit hooks to call the ''core/checkin.php'' script with a specific set of arguments.  Mantis then parses the message from the VCS system, using a configurable regular expression to look for text patterns indicating which bugs were affected or resolved by the submission.  The result is only a bugnote attached to the affected bugs with the entire message from the VCS, and maybe a partially-resolved issue.  This is the full extent of Mantis' integration with version control software.
+==== Limitations ====
+  * Commit messages must include bug numbers in usually-unforgiving patterns of text to be properly recognized.
+  * Bugnotes attached by checkin are associated with a special source control 'user' regardless of who committed changes.
+  * Reverse integration is limited to what can be shoe-horned into the bugnote message by the source control post-commit hook.
+  * Mantis knows nothing about the VCS system, or even the changeset itself once it is a bugnote.
 ===== Proposed Approach =====
+For an optimal set of features that will be available across all version control systems, Mantis will need to have a basic understanding of the underlying concepts that power the majority of all VCS software.  An abstract Source Control API will be created that has knowledge of repositories, files, and changesets.  Basic functionality will be implemented in the API for tracking and browsing a standard file tree repository, and individual VCS applications will need to extend this API to provide specific functionality for accessing, browsing, and manipulating the repository.
+Mantis will allow for multiple associated repositories to be used with the installation.  When changes to the repository are made, a post-commit hook of some sort shall be used to transport information about the changes to Mantis.  If the information includes references to issues in Mantis, then appropriate links to the changes will be attached to the listed issues.
+==== Repositories ====
+For the purpose of Mantis, a repository is merely a hierarchy of files that are associated in some manner to the Mantis installation.
+==== Changesets ====
+When something has changed in the repository, the changes are contained in a changeset, which has a timestamp, author, description, and a unique identifier of the changes, and may include references to multiple files, possibly from multiple paths in the repository.
 ===== Database Changes =====
@@ Line 20: / Line 47: @@
 Please hold your feedback until this page is completed.