Understanding FPM Sync Conflict

Prerequisite: How Sync Works

What is an FPM Sync Conflict?

FPM can handle most sync operations on its own with automatic merging features. A sync conflict is when FPM is unable to automatically resolve differences in the file between latest version available on the remote and the changes done against clone’s latest version.

Conflicts generally arise when two clones try to sync their changes to the remote in the following cases:

• They have changed the same lines in a file
• if one clone deleted a file while another clone was modifying it.

In these cases, FPM cannot automatically determine what is correct. Conflicts only affect the clone conducting the sync, the rest of the clones are unaware of the conflict. FPM notifies that the file gets in conflict-state and halt the syncing process for that file. Though, the rest of the file gets synced. It is then the clone’s responsibility to resolve the conflict.

Now that we have gone through the basics of the fpm sync conflict, let’s look at the various types of conflicts next.

Types of FPM Sync Conflicts

A conflict can be of various types depending on how it occurs.

edit-edit-conflict

The edit-edit-conflict occurs when two clones try to sync the file in which they have done the independent changes and three-way merge of the file has failed.

Let’s assume there are two clones A and B for some remote having fpm project XYZ. Both of them sync the same file from the remote which has the latest version v1 and try to make various amendments to that file. After making the changes, A syncs the file to the remote from its local. The remote, then, create a new version of the file v2, containing content sent by A and responds back to A. Now A and remote have the same version of the file v2, i.e. they are in sync. But, when B tries to sync the same file after making the changes from its end, it fails to do so, as the remote and B are out of sync with respect to that file, i.e. the remote has new version v2 of that file and B has done its changes against the version v1. Now remote doesn’t know what is correct.

edit-delete-conflict

The edit-delete-conflict occurs when the remote contains a new version of the file and the clone tries to delete the same file against some older version.

Let’s again assume there are two clones A and B for some remote having fpm project XYZ. Both of them sync the same file from the remote which has the latest version v1. After making some changes, A syncs the file to the remote from its local. The remote, then, create a new version of the file v2, containing content sent by A and responds back to A. Now A and remote have the same version of the file v2, i.e. they are in sync. B, then, deletes the same file using fpm rm <file> and tries to sync it, but it fails to do so, as the remote and B are out of sync with respect to that file, i.e. the remote has new version v2 of that file and B has deleted it against the version v1. Now remote doesn’t know what to do.

delete-edit-conflict

The edit-delete-conflict occurs when on the remote, the file is deleted and the clone tries to edit the same file against some older version.

Let’s again assume there are two clones A and B for some remote having fpm project XYZ. Both of them sync the same file from the remote which has the latest version v1. A deletes the file and syncs it to the remote from its local. The remote, then, deletes the file and responds back to A. Now A and remote are in sync. B, then, edits the same file and tries to sync it, but it fails to do so, as the remote and B are out of sync with respect to that file, i.e. the file is deleted on the remote and B has done its changes against the version v1. Now remote doesn’t know what to do.

add-add-conflict

The add-add-conflict occurs when two clones create a new file with same filename and independent content and try to sync the file.

Let’s assume there are two clones A and B for some remote having fpm project XYZ. Both of them create a new file with same filename and have added their own content. Afterwards, A syncs the file to the remote from its local. The remote, then, create a new version of the file v1, containing content sent by A and responds back to A. Now A and remote have the same version of the file v1, i.e. they are in sync. But, when B tries to sync the same file after making the changes from its end, it fails to do so, as the remote and B are out of sync with respect to that file, i.e. the remote already has version v1 of that file and B has created its own new file. Now remote doesn’t know what is correct.

How to identify sync conflicts

On sync, FPM produces some descriptive output letting us know that a CONFLICT has occurred. We can gain further insight by running the fpm sync-status command. The output from fpm sync-status indicates that there are some un-synced file s due to a conflict. These files cannot be synced in future syncs too unless their conflicts have been resolved.

How to resolve sync conflicts

Once knowing the files that have conflicts, you can resolve their conflicts using the fpm resolve-conflict <file-name> command. This command gives you various endpoints to address conflict according to its type.