AMS supports artifacts imported from Git or Subversion source control management (SCM) repositories. Artifacts in SCM-sourced projects are accessible through the AMS web client. Such artifacts are visible in the Workspace view and editable in the Artifact Editor.

The AMS coordinates SCM artifact changes made within and outside of AMS. When an SCM project artifact is updated, committed, and approved, the change is propagated to the external Git or Subversion repository. When a change is made to a file in the Git or Subversion repository by an external user, the AMS pulls the change from the repository and applies it to its internal copy of the artifact. External modifications are pulled either on demand or by a periodic background thread, whose interval is set in the AMS configuration file. Propagated changes include updates, additions, and deletions. Repository changes that get pulled into AMS bypass the normal AMS approval process Workflow in Detail (that is, they work like the existing AMS project-import mechanism). However, locked AMS artifacts prevent changes to the corresponding repository file from being pulled.

The version numbers of artifacts imported from Subversion repositories match those of corresponding repository files. The AMS supplies its own version numbers for artifacts imported from Git repositories. AMS artifacts from Git repositories include the corresponding Git commit hash. See Viewing Artifact and Project History for more information about project history.

Merge conflicts are detected and resolved through the AMS web client. For example, when an artifact is concurrently modified within AMS and externally in the Git or Subversion repository, the first modification to arrive at the repository wins. As an AMS user, if your artifact modifications appear after the externally made ones, you must synchronize your changes with those of the external user through the web client Synchronize tool. This scenario is similar to two AMS users modifying an AMS artifact concurrently; the first one to have the modification approved wins, and the other user must synchronize.

Access to SCM repositories is disabled by default. To enable AMS access to your SCM repository, you must change settings in your ams.conf file. AMS provides plugins for access to Git and Subversion repositories, as well as the option to configure customer-written plugins for other SCM repository types.

SCM Project-to-Repository Directory Mapping

Each AMS SCM project maps to a directory in the SCM repository. The name of an SCM project need not need match that of repository directory. For example, in the diagram below, AMS SCM projects P1 and P2 map to repository directories dir1 and dir2/dir3, respectively.

An artifact's path, on the other hand, matches the path of the corresponding file relative to its project's repository directory. For example, repository file dir2/dir3/dir4/a3 appears as artifact dir4/a3 in SCM project P2, because that is its path relative to repository directory dir2/dir3.

Two AMS SCM projects may not have overlapping directories in the repository. In the example below, AMS would reject the creation of a project mapped to directory dir2/dir3/dir4, since dir4 is a child of dir2/dir3, which is already mapped to project P2.

A file in the SCM repository can be imported into at most one SCM project; this follows from the non-overlapping directory restriction.

Any directories within or below the SCM repository root directory are candidates for importing as SCM projects into AMS. When an SCM project is created, all the files in and below the corresponding repository directory are imported as artifacts into the new AMS project.

In the diagram below, project P1 has a single top-level artifact, a1, while project P2 has a top-level artifact a2, and a second, non-top-level artifact, dir4/a3.

The resulting view from the web client of the projects and artifacts shown in the diagram above is: