We created multiple branches from different Revit models into one stream. How to merge all the branches into one? Thanks!
1 Like
Hey @chloesun, depends what youâre after:
- merge things together so you can view them all together: we should support that sooner or later. itâs not yet exposed in the viewer, though it can be done programatically.
- âmanual mergeâ: receive all the commits you want to merge in one host application, eg. gh, combine them up, and send them.
- just merge things together in one commit, without caring re merge conflicts (however youâd define a merge conflict in aec): we should be able to allow that to happen, rather easily, but weâd need to know first if itâs actually useful (hence itâs not implemented).
Curious to hear what you think!
1 Like
@dimitrie thanks!
- merge things together so you can view them all together: we should support that sooner or later. itâs not yet exposed in the viewer, though it can be done programmatically.
I was searching to find ways to do that in the viewer, it would be helpful to have that implemented. For now, how to do it programmatically without using an API gateway like Grasshopper?
Just give my two cents, very premature ideas:
1, Copy from software dev, so eventually, every branch will be merged into main to show the full picture.
The feature I might have in mind is you can choose branches to merge into main, while in the main branch viewer, you can still see the original source (like the Github âblameâ feature, something like when you click the original branch name icon, that specific content is highlighted)
Question is when a branch is merged into main, it will no longer be updated right? So you can only merge branches that you are sure that wonât change?
2, More like Photoshop.There is no main branch. Every branch is a living entity, like site, architecutral, structural, MEPâŚetc. They update constantly and we just need a feature to view them all(turn the layers on /off). While solving âmerge conflictsâ in this case could be a rough clash detection that you can calculate the intersections among the branches, and highlight the intersections.
For now, I think the second option might be more suitable for AEC workflows
2 Likes
Hi @chloesun! Sorry for the late reply, weâre âbusyâ with our retreat (read: eating pizza in various tuscan villages). Weâve decided to do try and solve this as a quick open coding dojo. If you want we can schedule it during a time that you can join as well, if curious. Iâll follow up next week and propose some times!
1 Like
Yep, definitively behind on this 
Life & company chores have a way to slice and dice my time. I wonât make any more timing promises until Iâm 99% certain I can keep them.
If really urgent and any of you want to have a stab at this, hereâs a quick run through off the top of my head:
Assuming you have commit A and commit B, what you need to do is create a new object containing a reference to A and Bâs referenced objects, say something like
let commitA, commitB
let mergedObject = {
speckle_type: 'Base',
objects: [ { speckle_type: 'Reference', referencedId: commitA.referencedObject }, { speckle_type: 'Reference', referencedId: commitB.referencedObject } ]
}
Next up, you need to merge the closure table from A and Bâs objects, picking the min depth of each duplicate key (if any), and store it in mergedObject.__closure.
Lastly, mergedObject can be saved via a quick mutation on the gql api (createObject), and you can wrap the returned objectâs id in a commit (whilst ideally taking care to populate the parents array with commitA & Bâs ids - thatâs what itâs for).
1 Like
@dimitrie oh, not really bother with any promises or not 
take you time
On the same topic (or related)⌠how do you guys think âsource controlâ should take place in Speckle? Is this something for Speckle in the first place? Like, sharing models is one thing, but would it also be supporting stuff like branching, merging, diffing, pull request, etc?
Speckle currently have a notion of a stream. AFAIK, a branch is just another stream, right? Or is it really a branch as in the way git operates? And is the merge you described here, just merging two streams in one? Or does it also tries to resolve conflicts?
Furthermore, Iâve looked a bit into how Revit does âversioningâ. They have this concept of work sharing, and AFAIK it is only supported locally/network or bim360. When one enables work sharing, Revit gives you features to lock or unlock an element in the model. Basically how source control used to work decades ago
Curious on what you guys think!
Ha, many questions. Some things still stand from 1.0 time.
Every object in speckle is immutable - if something changes, hashes change, itâs basically a new object. This where the âonly forwardâ mantra of Speckle comes from, and thatâs why thereâs no need to lock/unlock elements.
More specifically: in 2.0, branches are essentially âlabelsâ for commits, a bit just like in git. Commits are wrappers around a âtree-blobâ which contains the actual data (a high level intro is here). Commits can have multiple parents for tracking descendants. Streams are just âreposâ right now. If someone used to BIM360 asks, theyâre folders 
Merging: the merge described above is a simple one, without any conflict resolution. Conflict resolution is something hard in AEC, where itâs not just text 
It can be:
- actual 3d clashes - but only some of them, because many can be âokâ
- element duplication (do you have overlapping representations of the same object from more disciplines?)
- etc.
In short, itâs in the âeye of the beholderâ - thatâs why for actual ârealâ merges the only sound approach is to pull the data into an authoring software of choice (ie, Rhino) and resolve any âconflictsâ manually.
Streams are just âreposâ right now.
So, a stream can have multiple different files (models) in it?
Merging: the merge described above is a simple one, without any conflict resolution. Conflict resolution is something hard in AEC, where itâs not just text
- actual 3d clashes - but only some of them, because many can be âokâ
- element duplication (do you have overlapping representations of the same object from more disciplines?)
- etc.
In short, itâs in the âeye of the beholderâ - thatâs why for actual ârealâ merges the only sound approach is to pull the data into an authoring software of choice (ie, Rhino) and resolve any âconflictsâ manually.
Interesting!
Thinking out loud⌠from what I understand (a friend of mine is more of an expert user, so Iâm discussing it with him as well), Revitâs primary way of supporting collaboration in the same file is to enable work sharing. For this reason, almost all companies opt to store their models on disk (network), because that is one of the two work sharing options (other one is bim360, which is $$$). The collaboration feature prevents conflicts, so Revit does not have any conflict resolution support.
I was thinking Speckle will enable a new way of saving Revit models. One that is much more transparent and easy to share with other AEC tools and with other teams. But I also have a feeling that it conflicts with how Revit users collaborate, namely via locking elements.
How difficult is it to actually merge in Revit with the current connector? What would the steps be (would like to ask my friend if he can try it out while my developer license for Revit is pending )?
And how difficult would it be to actually build a diff/merge tool in Revit? Iâve read some papers on diff/merge algoritmes for 3d (and BIM), and I think it would be doable. Speckle could facilitate in the loading of the merging sets. I have a feeling that this would be far more natural (instead of locking), especially given how Speckle works, would you agree?
I am tracking this topic as well. For me it would be most interesting to be able to set up a WIP v Shared workflow where multiple branches can be used for multiple teams. This is also how the âGITâ idea is launched.
Very black and white:
We can analyze ownership of objects based on creation of those elements in different branches: i.e. If one branch has created the object, changes proposed in the merge from that branch are always treated to overrule other changes.
Another way is to set-up âtestsâ.
For quality check in GIT there is a method called âtestsâ to verify code.
This method is used to merge code from branches to the âmainâ . This creates a flow from one developer to a reviewer, making a certain check on the code/functionality.
For merging, we can do a sort of sandbox on the speckle viewer, where the owner of the âmainâ (BIM Coordinator e.g.) will view these different objects and identify which one is correct. after the conflict resolution, the sandbox is cleared and the outcome is put through to the main as well.
if an item is accepted that has a later date, that also has a conflict of an item with an earlier date on another branch, we could automatically assume these conflicts are resolved by the computer as the other element is the latest âtruthâ
We can always only allow merging branch by branch, to make sure this review does not get too complex.
1 Like
This functionality is also necessary to facilitate the workflow i described here.
For merging, we can assume: âan element is always overwritten by the version in the latest commitâ
2 Likes