You can create copies of objects with different names. As a result, you can add an object to a deployment group that has an existing copy in the target folder, but the copy has a different name. In this situation, the wizard detects the relationship between the objects and replaces the copy in the target folder with the object in the deployment group.

For example, you add the mapping m_Orders to a deployment group and copy it to the production repository. As you continue development, you change the name of the mapping in the development repository to m_OrdersWeekly. You add this new version of the mapping to a deployment group and copy it to the production repository. If the production repository is versioned, the wizard determines that m_Orders is an older copy of m_OrdersWeekly and replaces it, creating a new version. The latest version of the mapping in the production repository is now m_OrdersWeekly. If the production repository is non-versioned, the wizard determines that m_Orders is a copy of m_OrdersWeekly and replaces it with m_OrdersWeekly.

An object in the target repository might also have the same name as a deployment group object without being a copy of the object. The object may be of a different type. If this happens, the naming conflict causes the copy operation to fail.

For example, a mapping uses relational source src_Records in the development repository. You add the mapping to a deployment group and copy it to the production repository. Later, you delete src_Records from the production repository and create a new XML source, also named src_Records. If you then use a deployment group to copy the relational source src_Records to the target repository, the copy operation fails because the XML source src_Records has the same name, but is a different object.