@theoryshaw Git itself assumes that you only ever merge branches. So when you get a pull request you are expected to pull it into a local temporary branch, do the merge (then remove the temporary branch if you want).
ifcmerge doesn't care about this stuff, so if you are happy working on the command-line, you can merge a file that you received by email without worrying about branches.
@brunopostle are you able to merge ifc-git-branch into master? I got a failed merge. It seems like it should work.
https://gitlab.com/openingdesign/clothing_boutique
@theoryshaw there is a merge conflict, ifcmerge reports the location, but ifc-git doesn't show it in the UI yet:
$ git merge remotes/origin/ifc-git-branch
Auto-merging testy.ifc
CONFLICT (content): Merge conflict in testy.ifc
Automatic merge failed; fix conflicts and then commit the result.
$ git mergetool --tool=ifcmerge
Merging:
testy.ifc
Normal merge conflict for 'testy.ifc':
{local}: modified file
{remote}: modified file
entity #1067 attribute [6] conflict!
merge of testy.ifc failed
$ git merge --abort
entity #1067 is an IfcWall, ifcmerge says that attribute [6] ObjectPlacement has been edited in both branches.
However #1067 is identical in both branches, so this looks like a bug, will investigate...
@theoryshaw ifcmerge is adamant that this ObjectPlacement started as #1080, was changed to #1177 in 'master' and to #1130 in 'ifc-git-branch', but I see #1130 in both branches. I've run out of time to investigate, will look again later.
Np! I can run some more tests, to see.
@theoryshaw Basically you had a project with a single wall, then in master you made a copy of this wall, and in a branch of the original project you made a different copy of this wall. The merged result should have had all three walls.
The problem is that when you copy a wall, blenderbim creates a new wall, but also creates a new ObjectPlacement for the original wall, even though from a user perspective nothing about the original wall has actually changed.
Now ifcmerge is clever/stupid enough to realise that this ObjectPlacement is entirely new in both branches, even though due to the way you did it it happened to use the same set of step-ids in both branches (which was a boggle to say the least).
ifcmerge will refuse to merge an entity where an attribute has been modified in both branches - I'm not sure that randomly picking one to keep is a good idea because this will result in invalid IFC data such as orphan entities, but maybe we need to do this anyway with a 'prefer local/prefer remote' flag, since resolving this stuff manually is no fun at all.
But ultimately this is a BlenderBIM misfeature: copying a wall regenerates the ObjectPlacement of the original wall, even though as a Native IFC user you expect the original wall to be unchanged. None of this would have bothered anyone until now, so there are probably other similar glitches throughout BlenderBIM. I think a similar thing happens when you delete a window from a wall, the wall gets a new ObjectPlacement and/or Representation even though neither has changed. These need collecting and reporting in the tracker.
Thanks Bruno, added issue here: https://github.com/IfcOpenShell/IfcOpenShell/issues/2971
Could this add-on also be used to make a different view between a structural and architectural model? Could you also use feature tags to swap between different design variants?
@Coen swapping visibility of elements depending on classification, phasing etc.. is already possible in blenderbim.
If you have design variants in separate Git branches then you can use this add-on to swap between them without changing the camera viewpoint, but note that it is reloading the whole project each time, so it isn't going to be very fast.
From https://gitlab.com/openingdesign/clothing-boutique-20230412-for-testing
I was able to merge ryan_branch into the master, but was not able to get bpo_branch to merge into master
I only added a few annotations in ryan_branch, so i feel it should merge.
If you look at the Merged branch: ryan_branch commit...
You can see a lot of ifcwalls changed, but I feel they shouldn't have, as the ryan_branch did not change these.
@theoryshaw this is a perfect example of the asymmetry in the conflict resolution. In order to merge a remote branch, any local step IDs that conflict need to be rewritten to make space, basically anything added after the fork.
ifcmerge isn't just doing a three-way merge, it is resolving a conflict in a three-way merge.
So you can merge ryan_branch into master, but this involves rewriting recent history in the master branch, which would be fine except bpo_branch was forked during this recent history - bpo_branch is now an orphan and can never be merged :(
Solution would be to merge bpo_branch into master, then ryan_branch into master, this isn't a problem because you are not rewriting any history that ryan_branch cares about.
Similarly, you could merge bpo_branch into ryan_branch, then merge ryan_branch into master.
I don't want people to have to keep track of this sort of thing, Git is hard enough as it is. We need some kind of warning that merging a particular branch will orphan some other branch.
cool, cool... i think i get it. Good to know!
@theoryshaw now we don't have to rewrite the local data to accommodate the remote data - just switch the second and third arguments in the ifcmerge command and it will rewrite the remote and keep the local pristine, then you can merge as many forks into master as you like in any order.
One problem with this is that it will then orphan these forks, they will have to be abandoned once merged - which is probably fine if that is how you want to run your project.
But the main problem with doing this is that it is more polite to rewrite your local data when doing collaboration. If you are collaborating with someone else you want to be able to merge their fork, then they can merge yours etc.. in this circumstance you need to treat the other person's data as sacrosanct.
okay... i think. :)
I'm not sure I understood your last post so closely. :) We'll get there, though!
@theoryshaw it is not so cool, a normal software three-way-merge is symmetrical - but you have no idea if it has introduced bugs or if the software will even run. An ifcmerge three-way-merge is asymmetrical, which is a pain, but at least the resulting file will be a valid IFC (there may be physical clashes or doors into nowhere, but this is why we do coordination).
@brunopostle
From this commit:
https://github.com/IfcOpenShell/IfcOpenShell/commit/cc9777b1e838481f42c5fcedd04ef8a60206f69f
And this note in the BBim update thread:
https://community.osarch.org/discussion/26/blenderbim-add-on-new-release#latest
FC Git version control integration
Incredible work by Bruno Postle and Bruno Perdigao have led to an integration with the IFC Git project. This allows you to track changes on an IFC project, merge changes from multiple users, and jump to points in the project change history.
You can now manage your BIM data in a local Git repository without leaving the BlenderBIM Add-on. Instead of just saving a file, you can create revisions with descriptions. These revisions are browsable and retrievable, changes between two revisions can be visualised in 3D. Any revision can be forked, creating a branch for developing options or playing with designs. There is an experimental tool to merge branches using an IFC specific three-way merge for conflict resolution.
And the fact that this little drop down appeared in BBim a few iterations ago:
Am I right in assuming that the IFCGit experimental addon has been fully incorporated into BlenderBim? Without the need for a separate install?
Yes, thanks to help from @bruno_perdigao add-on has been moved into BlenderBIM, so if you have the old add-on installed you should uninstall it.
However we still have no way of shipping the git executable with BlenderBIM, so you do need to install this separately. On a Linux system you probably don't have to do anything, but on Windows you need to download git ( @Ace you don't need to do anything, you already have it). Similarly, if you want to use the experimental merge functionality, you need ifcmerge in your PATH, windows executable downloadable from here: https://github.com/brunopostle/ifcmerge/releases/tag/2022-06-20
There is also some basic BlenderBIM Git documentation
@brunopostle said:
Yes, thanks to help from @bruno_perdigao add-on has been moved into BlenderBIM, so if you have the old add-on installed you should uninstall it.
However we still have no way of shipping the git executable with BlenderBIM, so you do need to install this separately. On a Linux system you probably don't have to do anything, but on Windows you need to download git ( @Ace you don't need to do anything, you already have it). Similarly, if you want to use the experimental merge functionality, you need
ifcmergein yourPATH, windows executable downloadable from here: https://github.com/brunopostle/ifcmerge/releases/tag/2022-06-20
Amazing! Thanks @brunopostle and @bruno_perdigao !
@Ace This will be one of your very best videos :)
@Nigel said:
@Ace This will be one of your very best videos :)
Hahahha yes it will!
@Ace said:
@Nigel said:
@Ace This will be one of your very best videos :)
Hahahha yes it will!
Can't wait, actually, on a serious note this is (to use an annoying and overused cliche but in this case appropriate) a game changer in the BIM world.
@Nigel
(to use an annoying and overused cliche but in this case appropriate)
I thought you were going to use the word 'disruptive' ?
@Coen said:
@Nigel
(to use an annoying and overused cliche but in this case appropriate)
I thought you were going to use the word 'disruptive' ?
there are so many stupid cliches and buzz words to choose from
Login or Register to reply.