Non-Named GenericObject Lists

Lists composed of elements which are not named GenericObjects never produce a conflict. Since element-level list conflict detection is predicated on the ability to identify list elements (by name) and no such name exists in this case, no conflicts can occur - list order is not significant. As such, for such lists, conflict detection is bypassed. Merging, however, still occurs at the element level.

For example, consider an attribute whose value is a list of strings and whose initial value is [“A”, “B”, “C”]. Then two edits (such as two UserView checkout() methods) occur with this as the starting state for this attribute value. The first edit removes element B, resulting in a final list value of [“A”, “C”] and commits that change. The second edit (an optimistic edit) starts with the same initial value of the list ([“A”, “B”, “C”] but then removes element “A” and adds element “D” giving a local end result attribute value of [“B”, “C”, “D”]. The final merged list value is [“C”, “D”] because:

• The first edit removed “B”.

• The second edit removed “A”.

• The second edit added “D”.