Merging to an upper branch

Merging is difficult if there are conflicts to be resolved. But it is trivial if not.

The work can be split so that a "pre-merge" is made by a knowledgeable designer (who understands how to resolve the conflicts), and the final merge (trivial) done by the administrator.

Conflicting merge

    |
    o-----
    |     \
    |      o
    |      |
    .      .
    .      .
    .      .
    |      |
    o      o
    |     /
    o----

This merge is difficult: changes occurred on each path from the common base version

Trivial merge

    |
    o-----
    |     \
    |      o
    |      |
    |      .
    |      .
    |      .
    |      |
    |      o
    |     /
    o----

This merge is trivial: all the changes (if validated) can automatically be applied.

Pre-merge

    |
    o-----
    |     \
    |      o
    |      |
    .      .
    .      .
    .      .
    |      |
    o---   o
    |   \  |
    |    \ |
    |     \|
    |      o  pre-merge
    |     /
    o----

The pre-merge may safely be done by the designer (not affecting anyone else's work). A build is then done, labels are applied, and the results may be validated through testing (during this time, the "main" branch may be locked, so as to preserve the local topology of the version tree).

The final merge, engaging the administrator's responsibility, is again technically trivial, due to the change in the base version of reference.