The following section describes how versioning is handled when transferring metadata.
Version information is always transferred in Coexistence and Migration scenarios. However, depending on the source and the target PDM customization, the version label can be different. For example, when transferring data from a PDM where the version label pattern is 1, 2, 3, 4 to a PDM where the version label pattern is ---, --A, --B, the version label will be automatically computed from the target patterns.
Example 1
Source PDM version pattern equal to target version pattern equal to ---, --A, --B, --C, --D,....
Transfer | Source Version | Expected 3DEXPERIENCE Version (order respected) |
---|
1st transfer |
--- (1st order) | --- (1st order) |
2nd transfer |
--A (2nd order) | --A (2nd order) |
Example 2
Source PDM version pattern equal to a, b, c, d, e, f, ...
Target version pattern equal to ---, --A, --B, --C, --D,....
Transfer | Source Version | Expected 3DEXPERIENCE Version (order respected) |
---|
1st transfer |
a (1st order) | --- (1st order) |
2nd transfer |
d (4th order) | --C (4th order) |
Example 3
Source PDM version pattern equal to 1, 2, 3, 4, ...
Target version pattern equal to ---, --A, --B, --C, --D,....
Transfer | Source Version | Expected 3DEXPERIENCE Version (order respected) |
---|
1st transfer | 1 (1st order)
| --- (1st order) |
2nd transfer | 4 (4th order) | --C (4th order) |
Note:
The data transferred using a
coexistence scenario still belongs to the source PDM and can evolve and be versioned by the source PDM. That is why a lock
prevents versioning such data in CATIA 3DEXPERIENCE. To do so, you must transfer Mastership from the source PDM to the target
PDM by means of the CoexistenceAdministration batch.
The data transferred using a
migration scenario belongs to the target PDM and can be versioned
directly in CATIA 3DEXPERIENCE.