Calling for all subsets to be checked in to facilitate migration can be very costly and nonproductive. Migration can take place while subsets are checked out.
Consider checking out a subset with the root subject area for Modify and the databases for Delete before any other subset is checked out. You can then migrate the data-related objects (entity types, attributes, relationships, and so forth) by overriding the subset, and then re-checking out the subset.
You can use this same technique for other shared objects. If shared objects are being changed in one model, you should check them out for Modify or Delete in all other models but not download them. This protects them from being changed or ending up in another subset for modify or delete. When it is time for them to be migrated, you can override the protective subsets and the migration can proceed without conflict.
When a mass check in is required, spread the uploads over time so everyone does not try to upload at the same time (such as at the end of the business day).
Following a mass upload, a mass download is usually needed for the next day.
|
Copyright © 2013 CA.
All rights reserved.
|
|