ifcmerge asymmetry

[brunopostle]

Putting this here as it isn't noted anywhere else:

ifcmerge does three-way merge conflict resolution rather than a simple three-way merge, this is because there is always a conflict when merging two IFC branches - not least because of the FILE_NAME() header which is always updated (pointlessly in the context of a file that is already in a revision control system) - forked Native IFC projects will have step-IDs that conflict.

Conflict resolution means that the merge is one-way, data in the local branch is renumbered to make space for data coming from the remote branch. ie. any step-IDs created in the local branch since the fork can no-longer be relied upon to point to the same entities.

ifcmerge doesn't have to do this local rewriting, it could rewrite the remote for the merge instead (just change the order of the $LOCAL and $REMOTE parameters in the mergetool config). The reason why local rewriting was chosen is that it allows a back and forth between two branches - eg. Amy merges Charlotte's changes, and then Charlotte merges Amy's branch (which doesn't require any local rewriting since Amy already resolved the conficts), both branches are then in-sync.

The problem here is that if Betty forked and made changes to Amy's branch after Charlotte's fork, it may be using step-IDs that no longer exist in Amy's repository - Betty's branch is no longer mergeable under any circumstances. Merge order here is critical, if Charlotte merges Betty's branch before Amy merges Charlotte's branch then all three branches can be merged.

An alternative system would involve having a single 'master' branch and repository that always renumbered remote branches before merging (this can be achieved by reversing the $LOCAL and $REMOTE parameters as noted above). This would not allow any back-and-forth between branches, all forks from the 'master' would be mergeable back into the 'master', but these forks would then be detached and would need to be abandoned after the merge - this would clearly suit some workflows.

[brunopostle]

Another way to avoid asymmetrical merge resolution would be for authors to pre-agree working ranges of step IDs - currently BlenderBIM allocates new step IDs based on the highest existing number, but if my BlenderBIM was configured to also only create entities where the last digit was 1, and yours was configured to create entities where the last digit was 2, then the asymmetrical nature of the merge conflict wouldn't apply, since there would be no need to rewrite IDs to make space for the merge.