@Nigel
there are so many stupid cliches and buzz words to choose from
You have think outside the box, it wil be a win-win situation. Keep me in the loop on the IFC git.
<details><summary>Sorry</summary>
<pre>
Sorry, I will stop now
</pre></details>
The Git module now has some remote tools, so you can now clone a repository, fetch and merge branches, and push (if you have permissions).
Try it out: open blender, in the IFC Git panel, enter https://github.com/brunopostle/ifc-test.git as a URL, select an empty local folder, then Clone repository will download and open this project in one click.
In theory, could you store for example an IfcWindow in a git submodule and use the submodule as an IfcProjectLibrary in your main repository (where the acutal IfcProject is)?
@Coen You could do this (the Git panel doesn't know anything about submodules, but only because I hadn't thought of it). The problem is that IFC has no concept of xrefs, so any window type has to be imported into the project file and used from there.
You could definitely use submodules for storing heavy files such as laser surveys etc.. that are not of general interest to all project participants.
I would like to show IFC git to my colleagues, they are developers, product managers, testers
But I am thinking of a nice use-case scenario which shows all the possibilities on collaborating with an IFC through git source control.
Does anyone have a cool idea?
For me IfcGit has a few distinct advantages:
1.) Versioning (even if you use it solo, the versioning is super useful)
2.) Design alternatives with branches (Being able to explore different ideas of the design and return to the old one if necessary)
3.) Simultaneous working with others decentrally through GIT with branches
4.) Merging different branches together
5.) a written record of commits / changes with who authored them
These are clear and simple winners. A million others regarding comparisons to BIM 360 and similar stuff, we once tried to do a central revit model through google drive, it worked but it was waaaay too weird.
So from my description:
an example project that has 2 design versions, that you need to load an older version authored by another person in another country, (check authoring) and return to a version before the roof was changed or something, then merge a branch with a neighbouring building modelled ,
A kinda 5 min demonstration that demos all the best stuff , that would be my approach
The fact that it only works with IFC is a kinda selling point aswell as the files will always be super small compared to a revit file or something
@Coen a lot of the features are obscure and difficult to show, Git is conceptually hard, I've been using since forever, and CVS and Svn and Hg before that, and it still makes my head hurt.
Though the git clone URL above is very impressive, here it downloads the entire repository history, reconstructs the most recent revision, and loads it in blenderbim, all in about 5 seconds. You can then browse the existing history, make a change, commit it, visualise diffs, and open any past revision quickly and easily.
What I would like to see is: an IFC.js viewer of Git repositories, so you can push a change and see it immediately in a browser - this won't be a difficult project. It would also be fun to push changes from blenderbim, fetch them in freecad, make changes and push them back. Merging two branches that have diverged in different software would be a knockout demonstration, but we are not there yet. Commit hooks that publish drawing sets, do IDS checking etc.. would be something. There is still 'bounty' money for any of these, it's only a few hundred dollars, but it isn't nothing.
Commit hooks that publish drawing sets
Like a release branch which is able to produce drawing sets through a release pipeline trigger for example?
And a link to the funding page, if anyone is interested in pitching in...
https://opencollective.com/osarch/projects/git_ifc
OSarch matches all individual donations.
@Coen said:
Commit hooks that publish drawing sets
Like a release branch which is able to produce drawing sets through a release pipeline trigger for example?
Yes, drawings could be generated automatically server-side every time you tag a revision and push it to the repository - no need to collect PDFs in a zip file to upload somewhere, it would be already done, dated, attributed and downloadable.
Is there a very basic tutorial somewhere? I am getting a bit lost switching between branches.
Let's say you have two seperate IFC files in one git repository.. Is it possible to cherry pick one commit to the other branch and will it update the IFC?
@Coen there is some documentation but this is all generic concepts and doesn't go into detail about buttons etc..
Basically, the 'working branch' tells you what branch you have open in blenderbim.
The list of revisions is a browser that you can use to explore branches and their revisions, but your model open in blenderbim stays the same unless you switch revision (the ? button), or merge branches (the ⚗️ button below that).
The solid diamond ? (and [HEAD] prefix) on a list item tells you which revision from this branch is open in blenderbim.
If you 'switch' to the top (most recent) revision of a branch then the BlenderBIM model changes accordingly, and your 'working branch' is now this branch. Edit and commit and you are extending this branch.
If you switch to any other revision (ie not at the top), then you have what Git calls a 'detached HEAD'. Edit and commit and you are forced to create a new branch. Currently this is the only way to create a branch in blenderbim since I'm trying to avoid adding too many buttons.
Please do ask questions, although I have been using git since forever, I never really understood it. I'm not sure I entirely understand it now, but I do know it is really weird.
@Coen said:
Let's say you have two seperate IFC files in one git repository.. Is it possible to cherry pick one commit to the other branch and will it update the IFC?
I'm not sure what you mean. You can have two unrelated IFC files in a single repository, their history is tracked separately but there is no mechanism other than blender copy/paste for moving stuff between them.
Otherwise, in Git a revision is a snapshot of the data, a three-way-merge looks at differences between the branches you are merging, against the fork point when they split. There is no way I can think-of to isolate a single change, as it may depend on the previous changes going all the way back to the fork.
@brunopostle Thanks for the answer, is it possible to create a branch through the Blender UI? Or do I need the terminal to create a branch?
@Coen said:
@brunopostle Thanks for the answer, is it possible to create a branch through the Blender UI? Or do I need the terminal to create a branch?
Just switch to an earlier version and when you next commit you have to give it a branch name.
If you want to branch from the latest model, save it again, commit this (empty) change, and the point you wanted to branch from is no longer the latest revision.
@brunopostle said:
Just switch to an earlier version and when you next commit you have to give it a branch name.
You mean give the git command in the commit message in the Blender UI?
Think of it as a superhero movie, if you go back in time and start changing history you are creating a new parallel universe with an alternate timeline (a branch).
Now BlenderBIM has a safety feature, when you change stuff in the past (commit a new revision on top of an older revision), you also have to give the branch a name or discard the change.
If you do accidentally create a branch and make changes in the past that should really have happened in the present day, you don't need Spiderman to find a mcguffin to restore order to the multiverse. Just switch back to the present day (the HEAD of the main branch), pick your forked universe (the branch you created) in the browser and click the 'merge' button.
That was a very wholesome explanation of git history :p
That gave me the urge to test out how chatGPT would explain git branches and forks as a stand-up comedian. Idk why it went rambling about television shows but I think it was funny.
Hey, hey, everybody! How you all doing tonight? Give it up for version control, am I right? Yeah! So, let me tell you about these two crazy things in the world of Git: branches and forks. It's like a sitcom up in here!
Alright, so imagine you're working on a project, and you're like, "I got all these cool ideas, but I don't wanna mess up the main code, you know? I gotta keep it clean." Well, that's where branches come in. It's like having your own little parallel universe of code. You can create a branch and start working on your ideas without affecting the main code. It's like a separate room in the code mansion. You can make changes, experiment, and if things go south, you just close the door and go back to the main party. No harm done! It's like having a safety net for your creativity.
But wait, there's more! Git branches are like a sitcom crossover episode. You can merge them back into the main code. It's like two storylines colliding, and you gotta make sure they play nice. If everything goes well, you get this epic moment where your changes become part of the main codebase. It's like your own little contribution to the show. And everyone claps, and you feel like a coding superstar. Yeah!
Now, let's talk about forks. Forks are like the rebellious cousin of branches. It's when you take the whole codebase and say, "I'm gonna do my own thing, baby!" It's like starting your own party from scratch. You take the code, make your own changes, and you're like, "This is MY version now." You become the master of your own destiny, just like in those reality TV shows.
But here's the twist: forks can actually be a good thing. They're like the rock stars who go solo but end up creating something amazing. You can take someone else's project, fork it, and make it your own. You add your own flavor, your own ideas, and if it turns out awesome, you can even contribute back to the original project. It's like saying, "Hey, I made something cool with your creation, and I want to share it with the world." It's like a remix that becomes a hit song. Everybody wins!
So, my friends, that's Git branches and forks for you. It's like having your own little code adventures, making changes, merging back, and even going off to start your own coding revolution. It's like a comedy show with twists and turns. Git, my friends, it's the sitcom of version control. Thank you, and goodnight!
Well at least a comedian's job is safe.
I apoligize in advance for idiotic questions, but I am struggling to understand.
What I have done.
1) Initilized a git repo with ony one ifc file in the git repo, it gives me a master branch. Started a project, modelled two walls and saved it
2) Opened the folder/git repo in VS code to create a branch called adjust-wall-width and then set the wall width from 100 to 200mm
3) clicked the pencil button which says: Switches the repository to the selected revision and reloads the IFC file. As which I understand it does a git checkout so you're working in the branch you want to work in? Gave a concise commit message and pressed enter, after enter the Commit changes button ungreyed and I could press commit.
4) I see the latest commit message in the Blender UI
Now I wanted to go back to the master and switch between the branches, I have to select from the dropdown and click the pencil icon?
It works, but my question is.
Am I using the tool as intended?
Now I want to merge my branch adjust-wall-width into master.
But the button is still grey
git fork overview to make it visual:
A more concrete (haha pun unintended) example:
I have the master branch with these two walls.
The walls are 100mm width and have a Pset_WallCommon Pset.
Now I have the adjust-wall-width branch with these two walls
The walls are 200mm width and don't have a Pset_WallCommon Pset.
If I merge the adjust-wall-width branch back into the master branch.
Do I have walls with 200mm width and a Pset_WallCommon Pset?
Or is there a possibly to cherry pick commits and apply them to different branches?
@Coen this seems like a reasonable workflow, you can do git operations in visual studio and blenderbim should update fine.
The merge button is greyed-out because you are missing the ifcmerge mcguffin. download ifcmerge.exe here, you don't need to follow the instructions on that page, just put it in your PATH for BlenderBIM to find it.
Yes you should be able to merge a wall that has a layerset width modification in one branch and a pset in another. It will choke if you have modified the same attribute in both because it doesn't know which you prefer - in this case it will tell you the id of the offending element and you will need to find it and resolve the problem before merging again.
@brunopostle
just put it in your PATH for BlenderBIM to find it
which PATH do you mean? Environment variable path for Windows?
I've added the ifcmerge folder with the exectuable in it
The BlenderBIM add-on found the ifcmerge tool, because the button is not greyed out anymore:
Now the button says: Merges the selected branch into working branch
Now I made the added pset wall properties branch the active branch, I am a bit confused on how to merge the branch back to master. How do I know which branch is which?
I have it set like this
After clicking the merge button I get this message:
Login or Register to reply.