Repository-based Configuration Management > Overview of repository-based configuration management (repository-based CM) > Repository-based configuration management or CM tool integration? (repository-based CM)
  
Repository-based configuration management or CM tool integration? (repository-based CM)
* 
CM tool integration is deprecated.
If you want to apply configuration control to a model, you must choose between using repository-based configuration management (CM) or external CM tool integration, because they are mutually exclusive:
• If a model has been versioned through Model Explorer, CM tool integration features are disabled.
• If a model has been connected to a CM tool through the CM tool integration, repository-based CM features are disabled. Note that you can enable the database-based CM features by right-clicking the Model in Modeler, pointing to Tools > Configuration Management, pointing to Advance, and then clicking Disconnect From Configuration Management.
Repository-based CM is simpler to use than CM tool integration. In addition, repository-based CM supports parallel development of models and is faster. Unless you have specific reasons for using CM tool integration, it is better to use repository-based CM.
When to use repository-based CM
If you want to use repository-based CM or CM tool integration only for creating and storing model baselines, use repository-based CM. When you create a new version of the model, the previous version of the model is protected to provide a baseline that cannot be changed. Should you require model versions in a CM tool environment, you can export a previous version of a model, and then store the export files in your CM tool environment.
If you are working with models that are large or have many users, use repository-based CM. When managing models in a CM tool environment, users have to check out and check in Packages to make changes; when working with a large model, these check out and check in operations can be time consuming, and if the model has many users it becomes more likely that a Package you want to change is checked out to another user.
If you want to support parallel development of models through branches, use repository-based CM.
When you may want to use CM tool integration
If you need to work across sites that do not have a high-bandwidth connection, you may prefer the CM tool integration solution of model replicas on each site, rather than the database-based CM solution of using Terminal Server or Citrix. Many users of Automatic Code Synchronizer on a Terminal Server or Citrix server will result in high memory demands of the Terminal Server or Citrix server.
If you want to control access to models and packages through your CM tool rather than through Modeler, you must use CM tool integration. Note that if a user can check out a package from a CM tool, that user can change the Package in Modeler, irrespective of any access permissions set through Modeler.
If you want to reuse packages in different models, you may want to use the CM tool integration solution in which multiple replicas can reuse the same Package from the CM tool environment. Repository-based CM does not support Package sharing as such, but you can use the Component Sharing Wizard to copy packages between models. Alternatively, you can store a 'master' copy of a Package in a folder, and models can import and update the Package from that folder.
Summary table
The following table summarizes the issues you should consider before deciding on whether to use repository-based CM or CM tool integration.
Issue
Repository-based CM
CM tool integration
Scalability
Supports large models with many users.
Repository-based CM operations are faster than CM tool integration operations.
For archiving purposes, supports large models with many users.
For managing models, performance depreciates with larger models. With many users, it is more likely that Packages you want to change are checked out to other users.
Version control
Models can be versioned and branched through Model Explorer. Branching supports parallel development of items.
Models and Packages are versioned each time they are checked in to the CM tool. CM tool integration supports serial development of items.
Making isolated changes to a model
You can create a branch (a private sandbox) and make changes in isolation to other users.
Changes made in a branch are available in the trunk only after the branch is reconciled.
You can create a replica, and then check out Packages to that replica - changes made in the replica will be in isolation to other users.
Changes made in the replica are available to other users only after the changed Packages are checked in to the CM tool environment. From Modeler, the other users then have to update the relevant Packages from the CM tool environment.
You can only change Packages that are not checked out to other replicas.
Working across sites (no high-bandwidth connection)
Can use Terminal Server or Citrix, although many users of Automatic Code Synchronizer will result in high memory demands of the Terminal Server or Citrix server.
Can have replicas on each site.
Version skew
Version skew is possible only when using branches. Version skew is less likely to happen with repository-based CM, because versioning is at a model level.
Version skew is more likely to happen with CM tool integration, because users can check in and check out at a package level.
Access control
Controlled through SQL Server and Modeler.
The primary control of access is through access rights granted in the CM tool.
Modeler access permissions are used to allow only single user access or multi-user access, as required.
Note that if write access to a Package is granted in the CM tool, it is then not possible to prevent that Package being changed through the Modeler. See Controlling access in the Modeler and CM tool environments (CM tool integration)
Multi-user access
Controlled through Modeler at item level through transaction locks, and diagram level through diagram locks.
Controlled in the CM tool at Package level through check in and check out operations of Packages.
If single user use of Modeler is being used, only one user can change the contents of a Package in Modeler at any given time.
If team use of Modeler is being used, access is then controlled at item level through transaction locks, and diagram level through diagram locks.
Package Reuse
Can use the Component Sharing Wizard to copy packages between models. Alternatively, you can store a 'master' copy of a Package in a folder, and models can import and update the Package from that folder.
A Package in a CM tool environment can be referenced from many models. If a referenced Package is updated, the updated information is picked up next time a user performs a get latest version or check out operation on the Package in their Modeler environment. See Reuse (CM tool integration)