The master version in a merge operation
When you merge two or more versions, you must specify which one is the master version. This is the version that will generally take precedence when details in any of the versions conflict.
For example, suppose a question has a different question text in two versions that you want to merge. In the new merged version, the question text will be as it was in the version you specify as the master version.
The following table shows how changes in a category list are handled.
Categories in master version
|
Categories in Secondary Version
|
Categories in Merged Version
|
Explanation
|
1. Dinosaurs
|
1. Dinosaurs
|
1. Dinosaurs
|
The categories are identical in the two versions and so the category is unchanged in the merged version.
|
2. Conservation
|
3. Fossils
|
2. Conservation
|
Category 2 does not exist in the secondary version, but it exists in the master version and so it is included unchanged in the merged version.
|
3. Whales
|
4. Birds
|
3. Whales
|
Category 3 was renamed in the secondary version, but in the merged version the category takes the name from the master version.
|
|
|
4. Birds
|
Category 4 did not exist in the master version, but is included in the merged version.
|
Changes between other items in the versions being merged are handled in a similar way with the following exceptions:
Order of questions and categories
The order of questions and categories is always taken from the most recent version included in the merge operation.
Items not present in the master version
Sometimes one of the versions being merged contains a variable or category that is not present in the master version. When this happens, the most recent version in which the item exists and which is included in the merge operation takes precedence.
Minimum and maximum values
When there are changes between the minimum and maximum values defined for a variable in the versions being merged, the minimum and maximum values in the merged version are not always taken from the master version, because this can cause validation problems when exporting case data. For more information, see
How the minimum and maximum values are handled during a merge.
Loop definitions
Some questionnaire definitions contain loops, which define a set of questions that are to be asked more than once. The number of times the questions in the loop are to be asked can be controlled in three different ways: by the categories in a category list (for example, the questions are asked once for each product in a product list), by an integer (which defines the number of times the questions are to be asked), or by using one or more numeric ranges. Loops of different types cannot be merged. However, a loop that is defined using an integer is basically the same as a loop that is defined using a single numeric range. So, to reduce problems caused when loop definitions change, Metadata Model Version Utility automatically converts any loops that are defined using an integer into loops defined using a single numeric range. However, if you attempt to merge versions in which a loop definition has changed from the categorical type to one of the other types, or vice versa, the loop definition in the merged version will be taken from the master version. This means that you are likely to get unexpected results if you use the merged version to export case data.
When merging loops that are controlled by an integer or one or more numeric ranges, the lower bound and upper bound values that define the iterations are added to the loop's Ranges collection and merged together if they are overlapping.
See also