Avoid operations requiring a backfill because it makes the operation difficult to yield the desired results.

The command should only be used for forward propagations. For example, if member revision is 1.2, and you intend to resync to 1.4, the command responds correctly (as long as you are propagating forward on that development path). However, if you want to update member revision back to an earlier revision (for example, 1.1) the command will do nothing because it determines the change has already been made.

Keep the number of propagations small so that when they fail they are easier to resolve. Perform your development path merge operations as frequently as possible. For example, do not perform two years worth of operations because the accumulation of complexity makes it difficult for the operation to yield the desired results. You will be more successful performing the operation in small chunks.

Avoid refactoring operations such as move, rename, move subprojects. For example, if the configuration of a child development path is very different from the parent in terms of structure, then it will be more difficult for the merge operation to yield the desired results.

Ensure all change packages for the source development path have been closed after the last development path merge operation. The operation only uses changes from closed change packages. Similarly, ensure all change packages that are under review have been reviewed.

Use transactional change packages. If possible, to avoid problems, make transactional change packages mandatory on your system. Ensure all changes needed for the propagation are in change packages, because if some required operations are outside of a change package and some are in a change package, the merge will fail (because it is unable complete some needed operations).

Do not re-use development path names. For example, when creating a new development path, do not use the same name of one that was previously deleted.