Resolving conflicts

This chapter describes how to handle conflicts that may arise during distributed development between FirstSpirit, External Synchronization, and a version control system. These scenarios relate primarily to the synchronization of project content and changes to said content carried out by multiple developers, where the project content is synchronized between the developers’ work stations via a Git repository.

The majority of conflicts in a version control system environment can be avoided if the developer updates his local repository immediately before starting work on a work package and then imports the updated project data into his local FirstSpirit project instance; once he has finished working on a work package, he should then export the project data out of his FirstSpirit project instance and directly into the Git repository. Despite this practice, further conflicts may still occur as a result of multiple developers working at the same time. This chapter covers any such scenarios.

Conventions

The sample scenarios used are based explicitly on the model of distributed development.

• Two developers: Developer A and Developer B
• Each developer uses a separate workstation with a local FirstSpirit Server.
• The FirstSpirit project data that the developers work on are managed in a project “DevProject” on each local FirstSpirit Server.
• The data in the “DevProject” FirstSpirit project are versioned via a Git repository and synchronized between Developer A’s and Developer B’s workstations; however, this repository does not contain any data in its initial state.
• The Git repository already exists and can be accessed under the URL ssh://firstspirit.example/externalsync
• The Git repository is cloned on every workstation in the D:\Git\DevProject directory.

The scenarios use the FSDevTools command line tool (fs-cli) and the command-line-based Git client (git). Calls of these tools have been simplified to make the scenarios easier to read, though they do not necessarily correspond to the best practices presented in this documentation. When applying other tools to use External Synchronization and/or to version project data, the workflow may differ and some conflict handling scenarios may occasionally require other workflow steps.

Scenarios

Simultaneous changes to a template

• Different areas (disjunction)
  When two developers work on a template at the same time, changes take place at different points, e.g., the definition of a presentation channel.
• Overlapping areas (conjunction)
  When two developers work on a template at the same time, changes take place at identical points, e.g., the definition of a presentation channel.
• Identical changes
  When two developers work on a template at the same time, identical changes are made to the template on the two workstations.

Namespace conflicts

These scenarios relate to conflicts that may occur as a result of requirements for namespaces in the FirstSpirit project where Git is not familiar with said requirements. This section demonstrates in particular how to deal with unique IDs (UIDs) for FirstSpirit elements within a namespace in various distributed development scenarios.

• Same template type, same UID, different content
  The local creation of templates of the same type with the same UID (unique ID) leads to a conflict during distributed development.
• Different elements with the same UID (e.g., Page Store)
  The local creation of elements of different types with the same UID in a namespace (using Page Store as an example here) leads to a conflict.