IP Data Management (DM) types

One of the first decisions when creating a new IP is to select between the three basic types. At the Helix IPLM level each type is identical, the primary difference is how (or whether - See Container IPs) they manage their design files. Any type of IP can be used as the resource (child dependency) of any other type of IP, and all IPs can store and display metadata in the same ways. There are no restrictions in how the various IP types can be used or related to one another in an IP Hierarchy (CIPB) so it is fully allowed to mix and match IP types in a hierarchy as needed.

DM IPs such as Perforce, git, SVN, or SharePoint

DM IPs manage design files in a DM system. DM IPs have a repo_path field that points to data in a Data Management system, this field is formatted according to the underlying DM the IP is managing.

Workspace Behavior: When DM IPs are loaded into a workspace, a directory is created and the managed files under the repo_path are loaded using native DM commands. Once in the workspace native DM commands are used to manage the data at the file level, either directly from the command line, or indirectly through another application like VersIC. Helix IPLM commands are used at the IP level to update the workspace, make releases, and compare the workspace versus IP releases.

Release Behavior: A new DM IP release from a workspace will capture the files currently in the workspace at the time the release is created. The format of the release contents is different according to the DM system, in the case of Perforce a file list of the files under the IP's repo_path is captured along with the file versions of those files. In Subversion IPs the repository revision is captured at the time of release. git IPs will capture the SHA number currently loaded in the workspace. In all IP types the current resources configuration in the workspace is also captured as part of the new release.

Update/Integration Behavior: Perforce IPs support file based update modes in bringing in new IP versions in the workspace. This means that local modification can be retained via file updated modes. All IP types support update modes at the resource level, but only Perforce IPs support it at the file level as well. See Update modes for more details.

Container IPs

Container IPs are identical to DM type IPs with the single difference that they do not manage DM level files. They do however have resource IPs, and support the same types of metadata that are supported by DM type IPs.

Container type IPs are useful for grouping other sets of IPs into a sub-system, and providing a level of abstraction from the version changes of the lower level IPs. For example if resource IPs go through many version changes, these can be masked by a Container type IP which can be released when ready for consumption at a higher level of the design.

Having a container as the top IPV (and hence only resources) also allows easily generating quick variants/derivations without getting into complex branching/merging situations. For example, once a project projects.revA0@HEAD.TRUNK with static resources is finished the customer could create a new projects.revA1@HEAD.TRUNK with a copy. This makes it easy to revert to the previous version on demand.

Container IPs can be converted to P4 (and only P4) type IPs by editing their dm_type field. See Editing IPs for more information.

Workspace Behavior: When populated into a workspace Container IPs do not directly populate any files on disk (nor will a folder representing the container IP be loaded) but any DM or File System type resources of the container IP populate their files into the workspace.

Release Behavior: Container releases from a workspace will capture changes to the IPVs that are a part of the container's resource list, but as Container IPs don't manage files, no files will be captured as part of their release.

Update/Integration Behavior: Container IPs bring in updates with new releases just like other IP types, and support resource update modes. See Update modes for more details.

Filesystem IPs

File System IPs repo_path field is a directory path to a location on a shared disk (eg NFS directory). Each release of a File System IP will have a different repo_path value, with a new set of data constituting the new release data at each new location.

Filesystem IPs are a way to manage large or infrequently changing blocks that it might not make sense to add to a DM system.

Workspace Behavior: When a workspace is built that contains a Filesystem IP, a file system link is generated from the workspace to the location specified in the Filesystem IP's repo-path (which will be a different location for each release of the filesystem IP). From the workspace user's perspective the Filesystem IP appears as a link into the local workspace, and full workspace management functionality is available for the IP (with the exception that it cannot be brought locally into the workspace). The user is responsible for maintaining correct permissions on the filesystem IP directory, and for ensuring that the directories corresponding to each filesystem IP version continues to exist over time.

Release Behavior: The file contents of each new filesystem IP release have to be configured and placed outside of Helix IPLM. Resources are captured as part of a new release, just as with any other IP type.

Update/Integration Behavior: Filesystem IPs bring in updated resources with new releases, just like other IP types, and support resource update modes. See Update modes for more details.