1. XML / JSON Requests
Concurrent Merge takes three or more versions, with one version treated as the "ancestor" or original to each of the other versions that are compared.
Each version needs a name, and an input. See I/O types for more information on sources of input.
As such, you can specify three or more versions, and the first in the set of versions will be treated as the ancestor. For example:
Like Concurrent Merge, Sequential Merge takes three or more versions, each with a name. These are then merged sequentially - in the order you specified, which needs to be the same as the order they were edited. The syntax for specifying versions in Sequential is the same as Concurrent:
1.3. Three Way Merge
As the name suggests, there are only three versions in a Three Way Merge. We have simplified how to specify versions in Three Way Merge by explicitly naming the elements used:
2. multipart/form-data Requests
2.1. Concurrent and Sequential
When using Concurrent or Sequential Merge, the part name is used as the version identifier in the merge - i.e. enter any valid name NMTOKEN isn't a parameter otherwise used by XML Merge REST e.g.
There is an additional parameter,
VersionOrder, used with
multipart/form-data to clarify the order of the versions - a comma separated list of the version names.
In Concurrent Merge the first item in this list will be assumed to be the ancestor.
2.2. Three Way Merge
This is similar to an XML or JSON request - there are predefined part names for
VersionTwo. There are additional optional parameters corresponding to each input's version identifier e.g.
If names aren't specified then the values "Ancestor", "VersionOne" and "VersionTwo" will be used.