Software: Provision v6.2.2, Knowledge Exchange Server v6.2.2
Summary
Provision allows you to create two business classes in different packages with the same name. However, if this notebook is checked in to knowledge exchange server and checked out again, the objects are bizarrely munged whereby their generalizations etc are merged, renaming one object automatically renames the other, yet deleting one object leaves the other.
Scenario:
Create a new notebook in a local repository. Create two Business Class models representing packages: 'Package A' and 'Package B'.
In package A, create a Business Class 'BC. This will show up in the object explorer as 'Package A::BC'.
In package B, create a Business Class 'BC. This will show up in the object explorer as 'Package B::BC'.
It is not really necessary but it is possible at this point to rename these business class objects independently (but change them back to be the same for the next part), add generalizations etc, save the notebook and restart Provision etc, create topic business class models with both objects on the same model, all without incident.
Check the notebook into a Knowledge Exchange Server repository. Then check it out again with full lock.
If you now try to rename 'BC' within 'Package A', it will magically rename 'BC' within 'Package B' - i.e. the two objects appear to have been merged. However they are both still listed separately in the object explorer.
If any generalizations etc. have been created, all of these will appear within the Links tree, but only some of them will still have a 'Where Used' leaf. If both objects had generalizations, opening a model will produce errors stating that an object has multiple parents.
It is possible to delete one of the objects, but the other one remains.
This appears to either be a major trap for the unwary (there are no errors at all, or any other indication that there might be a problem later), or an incompatibility when using these two products together.
Extra info:
Although Provision when used on its own appears to fully support the use of identically named business classes in different packages (which is a perfectly sensible thing to have in a data model), exporting the information using Translator to Excel does not export the package prefix. As a result, the information cannot be re-imported without issue.
