In some situations, several users might be modifying an application definition concurrently. For example, several application developers might be working on the same application in their own development environments, or business users might be changing application configurations in the staging environment while developers are making other changes in the development environment. To avoid synchronization conflicts, review the following approaches.
Token systems prevent synchronization conflicts by allowing only one person in an environment to modify an application configuration. Only the person holding the "token" can make changes. The token is passed from one environment to another during synchronization: the target environment acquires the token from the source environment when the application definition is propagated. Any changes performed before obtaining the token will be run over without warning.
Token systems are simple, because it is easy to tell which environment is entitled to make changes at any given moment, and any part of the application is allowed to change in the token-holding environment. However, a token system prevents concurrent development.
A separation of concerns method restricts the scope of changes allowed in an environment. Each environment is concerned with a distinct part of the configuration. For example, one environment may be in charge of Page Builder templates, while another is in charge of dimension definitions. Changes to the area of concern can only be made in the appropriate environment. Therefore changes made in one environment never overwrite changes made in another.
Separation of concern methods facilitate concurrent development, but the separation of concerns must be well defined in advance and enforced consistently.
Conflicts arising from unrestricted concurrent changes in multiple environments can be resolved by manually comparing all the conflicting files and treating each difference individually.
However, manual resolution processes are time-consuming, require extensive knowledge of Endeca components and internal formats, are prone to human error, and are not scalable. Therefore, you should not consider manual resolution for synchronizing Endeca environments.