During the merge operation, FS Version Control carries over the changes made in the Source Branch to the Destination Branch.
In some cases FS Version Control may not be able to figure out the right operation to perform to bring over a particular change. These cases are called Conflicts.
A Conflict may occur if;
- An object deleted in the Source Branch is modified in the Destination Branch.
- An object is modified in the Source Branch and in the Destination Branch, and Git Server cannot consolidate these modifications. (For example, in both branches the backgroundColor of the same panel object is changed to different values. There is no way a Version Control System can figure out the right way to consolidate these two changes.)
- An object modified in the Source Branch is deleted in the Destination Branch.
- A newly created object in Source branch and a newly created object in Destination branch have the same name.
Moreover, even if there is not a Conflict, after the merge, an FS Object’s definition may violate the Formspider Object Rules (For example, a button cannot have two buttonPress events). This happens because all Git does is merging text files. It does not understand the semantic meaning of the Formspider metadata and cannot validate its rules.
FS Version Control monitors merge conflicts and validation errors and provides an easy to use interface to the developer so that he/she can resolve these issues.
If there is a conflict in a database object after a merge, Formspider does the following in the destination schema:
- It creates the database object in an uncompiled form with changes both in source and destination in it.
- It creates the database object with “MINE” suffix in its name which represents the object in the destination repository.
- It creates the database object with “THEIRS” suffix in its name which represent the object in the source repository.
Resolving Issues in Formspider Objects
After a merge in the Git server finishes, Formspider shows up the Merge Wizard to help the developer finalize the merge operation. Merge Wizard consists of three steps:
1) Resolving Conflicts
2) Resolving Validation Errors
3) Issuing the Commit to finalize the Merge
Depending on the result of the merge, the Merge Wizard may skip step 1 and/or step 2 .
1) Resolving Conflicts
In the picture above, the Merge Wizard shows a finished merge operation that resulted in 3 conflicts:
- Panel p1 is updated in the destination branch and deleted in the source branch. This is indicated as UD in the “Conflict Reason” column of the “Unresolved Conflicts” Grid.
- Panel p2 is updated both in the destination branch and source branch in such a way that Git cannot figure out a way to merge the copies. This is indicated as UU in the “Conflict Reason” column of the “Unresolved Conflicts” Grid.
- Panel p3 is deleted in the destination branch and updated in the source branch. This is indicated as DU in the “Conflict Reason” column of the “Unresolved Conflicts” Grid.
The “Unresolved Conflicts” Grid shows the following information for each FS object with a conflict:
Object Type: This column indicates the type of the object (such as Panel, Datasource, Dialog etc… ) the conflict is on.
Object Name: This column indicates the name of the object the conflict has occurred. Clicking the name opens an XML editor which shows an editable XML definition of the FS Object.
Conflict Reason: This column indicates the code for the conflict.
Mine: Clicking the View link in this column shows an uneditable XML Definition of the object in the destination branch.
Theirs: Clicking the View link in this column shows an uneditable XML Definition of the object in the source branch.
Resolve: Clicking the link in this column changes the status of the conflict from Unresolved to Resolved.
Delete: Clicking the link in this column changes the status of the conflict from Unresolved to Resolved by deleting the FS Object.
Steps to Resolve Conflicts
To resolve the conflict in p1 by deleting it, the developer should click the “Delete” hyperlink (existing under the “Delete” column of the “Unresolved Conflicts” Grid) shown for p1.
To resolve the conflict in p2, the developer should click the p2 hyperLink (existing under the “Object Name” column of the “Unresolved Conflicts” Grid) to edit its XML Definition.
The developer should click the “Resolve” hyperlink for p2 to update the conflict’s state to Resolved.
To resolve the conflict in p3 by accepting the changes made in the source schema, the developer should click the “Resolve” hyperLink. Since the object is deleted in Destination Branch, the XML definition of p3 is already set to the definition in Source Schema. FS Version Control just needs the confirmation that the developer wants to keep the object.
The “Resolved Conflicts” Grid shows two new columns compared to the “Unresolved Conflicts” Grid:
Solution: Shows the solution the developer applied to resolve the conflict. The possible values are M and D. M stands for Modified indicating that the developer kept the object and may have modified its content in the destination schema. D stand for deletion indicating that the developer resolved the conflict by deleting the object the conflict has occurred on.
Action: If the developer wants to change the way she resolved the conflict, she can do so by clicking the “Reopen” hyperlink. Clicking the “Reopen” hyperlink updates a conflict’s status to Unresolved.
Note that, the conflicts in database objects also show up in the “Unresolved Conflicts” Grid . The developer resolves these conflicts and compilation errors using her favorite database development tool. Next, she clicks the “Resolve” buttons for the database objects and moves them to the “Resolved Conflicts” Grid.
Once all the conflicts are resolved, the Merge Wizard allows the developer to move to the next step.
2) Resolving Validation Errors
A validation error occurs when an FS Object violates Formspider Object Rules after the merge.
In the example above, merging Panel p5 has caused a validation error becasue Panel p4 already includes panel p6 in its definition. Since a Panel cannot be included in two different panels at the same time, Formspider cannot save p5 to the repository.
The developer can resolve this error either by removing p6 from the definition of p4 or from the definition of p5. Once the error is resolved, the developer should click the “Resolve” button next to the error. After the resolve buttons is pressed, Formspider attempts to save the panel to the repository again. Once all the validation errors are resolved, the Wizard moves to the Commit Phase, which is the final stage of a successful merge operation.
3) Committing the Merge
Issue a final commit to finish the merge and save all the changes made in the Merge Wizard to the Git repository.