T
by theoryshaw on 24 Jun 2024, edited 24 Jun 2024
#
@brunopostle
Is there currently any way to resolve a merge conflict like the following?
https://hub.openingdesign.com/OpeningDesign/GIT_test
...
I ask because I can envision working on a file for days, for example, and trying to be super careful not touching any objects your collaborators are working on, but when the merge is done, there's one or two conflicts that show up. In this scenerio it would be sad if you couldn't merge all this work.
Would be nice if there was a way to 'revert' just those objects that are conflicting, for example, so you can merge all the other changes.
B
by brunopostle on 24 Jun 2024
#
+1 votes
With source code you can think of changes as 'patches' that can often be applied in any order (like adding vectors), but with IFC we have this three-way merge, but not diff and patch in any kind of useful way.
In your example, you have a wall that has been moved in both branches. If you managed to move it again in one of the branches, either to its original position, or the position it has in the other branch you will be able to merge, but this isn't really practical.
The simplest workaround is to duplicate the wall in one branch and then delete the original wall in both branches. This will merge (though an annoyance is that if you delete the only wall in a project, the IfcRelDefinesByType gets deleted too).
T
by theoryshaw on 24 Jun 2024
#
As a first step, could something be written where if there's a merge conflict, that it automatically just uses the change from the oldest branch.
for example...
T
by theoryshaw on 24 Jun 2024
#
It looks you won't need to revert/remove IFCRELCONTAINEDINSPATIALSTRUCTURE.
B
by brunopostle on 24 Jun 2024
#
+1 votes
Just picking one entity or the other when there is a conflict has some disadvantages: the user doesn't know it has happened, which could be a big problem with construction projects; or it could leave the model in an inconsistent state, with validation errors or even a broken graph.
There are some cases where it would be safe to keep an entity that is deleted in one branch but modified in another, typically IfcRelationship entities (I think that is what you are pointing-to in your example). But at the moment ifcmerge doesn't have any understanding of the IFC schema, it only understands the syntax of entities, attributes, IDs etc..
T
by theoryshaw on 24 Jun 2024
#
Yeah, it would be nice to have some type of conflict resolution--because conflicts are bound to happen, no matter how conscientious each collaborator is to not modify the same object.
B
by brunopostle on 24 Jun 2024
#
I do want to see any real-world conflicts, there may be an easy fix - like the IfcOwnerHistory problem, which probably broke merging all IFC2X3 - is this fixed for you in the new ifcmerge.exe?
T
by theoryshaw on 24 Jun 2024
#
is this fixed for you in the new ifcmerge.exe?
yes, the new .exe fixed the IfcOwnerHistory problem! Thanks.
I do want to see any real-world conflicts...
for sure, will keep you posted, if we run into any. We just started using ifcmerge.