|
CM tool integration is deprecated.
|
Issue
|
Modeler CM
|
CM tool integration
|
---|---|---|
Scalability
|
Supports large models with many users.
Modeler 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 Modeler 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)
|