|
Step 4 - File Conflict Resolvers |
Top Previous Next |
|
Overview
Conflict resolution is a key feature of file collaboration that is in effect at the start of a session. When a file collaboration session begins, the host participants' configured folders are synchronized by a scan and merge phase, during which conflicts can be detected. Below we will define file conflicts, describe our detection scheme and the configuration options we provide to resolve them.
Defining a Conflict
When a session begins, the participants' folders are first scanned then merged to form a collective view of the participants' content. All files found under the designated folders are subject to collaboration, except for those excluded by filtration (see Step 3 - File Filters for more details).
A conflict occurs when a file path is found to exist on more than 1 host in a file collaboration session. For example, the following files are found to be in conflict:
\\Host-A\FC-Session-UserGuide\release-1.0\readme.txt \\Host-B\FileCollab-UG\release-1.0\readme.txt \\Host-C\FCS-UserGuide\release-1.0\readme.txt
In this configuration, the file '\release-1.0\readme.txt' is found to be in conflict across 3 hosts. Note that each host can designate varying root folders. Content below the Root Folder resides under a shared namespace. Conflicts may occur across a partial or total set of participant hosts.
Resolving a Conflict
The goal of conflict resolution is to designate 1 instance of a conflicted file as the "winning" copy or the one designated as the source for synchronization. The criteria for resolving conflicts are based on the file's meta data such as size, modification time or host name.
It is important to note that conflict resolution must select a single instance of a file, although it is quite possible that several copies of a file are potential candidates. Drawing from the paths listed in the previous section, if our session was configured to resolve conflicts based on file-size and all instances of '\release-1.0\readme.txt' were the same size, then all 3 would be resolution candidates. In this case, the winner would be arbitrarily selected from the candidate set. This concept applies to all resolution types that are prone to multiple candidate selection.
Once the merge and conflict resolution phases have completed for the session, synchronization transfers begin to distribute the source content. This includes all the source copies of conflict winners as well as files that are missing from participants.
Resolution Types
The conflict resolvers we currently provide are listed as follows:
All the types listed above have the potential for producing multiple resolution candidates. A collaboration session can be configured with any 1 of the available conflict resolvers. If a resolver produces more than 1 candidate for a conflicted file, a winner will be selected arbitrarily.
A session may also be configured with multiple resolvers in a sequence. When any one resolver generates multiple selection candidates, the candidate set is supplied to the next resolver in the sequence to further reduce the candidate set. Conflicted files will be processed through resolvers until either a single winner is selected or the resolver sequence is exhausted. If multiple candidates arrive in the latter case, 1 will be arbitrarily selected.
No Configured Resolvers
You can also choose not to configure any file conflict resolvers. In this case, when a file conflict is detected during the initial synchronization process, the file will be quarantined and placed in the File Conflict List, and you will have to manually resolve the conflict by selecting the host with the correct version of the file.
Configuration
In most cases the default file conflict resolver which is by Latest Modification Time will suffice. If you would like to customize this, click on the Conflict Resolvers tab and follow the instructions below:
|