Open pablo-mayrgundter opened 2 years ago
Doc is currently private
Francesco, is that informative enough for now?
@pablo-mayrgundter is this still relevant?
Thanks for the ping, it looks like the versioning in the URL does work but yeah, we still need a UI control to query for versions and make them selectable by the user.
What is the definition of a version
?
Are we referring to something specific, or are we referring to any valid input that Github accepts in its URL structure? (e.g. commit hashes, branches, and tags)
I think it is a branch.
this is an example of a repo with two versions: https://github.com/OlegMoshkovich/Logo/tree/main
Version 1: https://github.com/OlegMoshkovich/Logo/blob/iteration_0/IFC_STUDY.ifc https://bldrs.ai/share/v/gh/OlegMoshkovich/Logo/iteration_0/IFC_STUDY.ifc
Version 2: https://github.com/OlegMoshkovich/Logo/blob/iteration_1/IFC_STUDY.ifc https://bldrs.ai/share/v/gh/OlegMoshkovich/Logo/iteration_1/IFC_STUDY.ifc
To be clear, you're referencing a repository with three versions.
One version in each branch:
main
iteration_0
iteration_1
Is there a Figma/mockup available for what the UI is expected to look like?
Yes, you are right there are three versions. High level mock up is here: https://www.figma.com/file/LNUJP0228mJqlb4ev6AKbf/Design?node-id=4%3A4568
I talked with Bruno Postle @brunopostle (https://github.com/brunopostle/ifcmerge), and he suggested ideas:
I wrote a proposal for a gui tool: https://community.osarch.org/discussion/comment/12598/#Comment_12598
Though I since elaborated this, but can't find where, some of the things not in the above proposal:
- isomorphic-git lets you connect to any repository, so there is no need to be github specific,
github also has a hard 100MB limit on file sizes so you really don't want to be limited to github.
- Although working with single IFC files seems logical, a repository will allow multiple IFC files,
so any git/IFC GUI will need to first point to a repository, then allow the user to browse IFC files
in that repository. This makes more sense when you consider that multiple IFC files can be
federated as an overlay.
- A true 3D visual diff between versions is hard, if not impossible, but a simple `git diff` will list
all the modified and removed object GUIDs, which can be used to quickly colour the 3d view.
- three-way merges is advanced usage, a lot can be done simply with a git commit log and a
tool to switch the 3d view between revisions.
..we even have a small amount of funding though osarch to work on this:
https://community.osarch.org/discussion/comment/12981/#Comment_12981
We chopped up the original requirements doc to start moving things here, but also didn't have a lot for Versioning requirements. That wasn't just being lazy ;) Our idea for versioning is to pass through GitHub functionality to the app. We don't expect everything to be useful as git is overly complicated, but some subset of versioning functionality.
1) So for instance here's a file you can view in Bldrs by pasting it into the search bar:
https://github.com/Swiss-Property-AG/Portfolio/blob/main/KNIK.ifc
the "main" path segment is the branch the file is in, and without any further information, this means the HEAD version of the main branch. That currently works.
2) GitHub also provides hashed and tagged versions, which we should support soon.
Supporting these means both in the URL (see also https://github.com/bldrs-ai/Share/wiki/URL-Structure) and also in the UI, by having some component to help explore previous versions and branches.
EDIT(Aug 18): The Share URL structure actually already supports versioning! So changing this issue to track development of the UI control. Example of versioned file:
https://bldrs.ai/share/v/gh/Swiss-Property-AG/Portfolio/770153b703d7aa59f7be0cb87930f29f162f666f/KNIK.ifc
Stretch: Lastly, we'd like to support checking in changes and resolving diffs. This is where things get complicated, so we'll need to revisit this more later.