What is an item fork in a graph?
I’m resuming our series of blog post about configuration management concepts. The last one was about non-interchangeable revision. This week we cover the fork concept. Fork...
Filter by Category
Filter by Author
I’m resuming our series of blog post about configuration management concepts. The last one was about non-interchangeable revision. This week we cover the fork concept. Fork...
Posted by Yoann Maingon
As I’m now in the business of editing PLM software with Ganister. I have been involved in defining what would be a correct way of dealing with configuration management (CM)...
Posted by Yoann Maingon
I’m resuming our series of blog post about configuration management concepts. The last one was about non-interchangeable revision. This week we cover the fork concept.
First let’s make sure we don’t confuse Fork and Branch.
A branch is typically copying data to work on an alternative in order to ultimately merge the benefits of this alternative, back in the initial version. It allows to work on multiple alternatives at the same time.
Fork, is closer to basic configuration management practices. You have a product, and you decide to create a new version. But this version is different enough to not keep the same product number and start a new product reference, not just a revision.
Historically in PLM, Fork, is copying a folder. Whatever the PLM data you are working on (mechanical, electronic design, or service definition). You create an alternative by copying and renaming a folder.
PLM is a graph, and in a graph, the limits of your folder don’t exist. Therefore we need to understand what is the impact of a fork on a few nodes of the PLM graph.
Here is a simple example with PRTC being forked.
The consequence of such operation is:
The difference with a non-interchangeable revision is that you don’t supersede the initial part (or any type of node). In our case PRTF starts from the latest state of PRTC but from now on it will live its own life.
The following example is an actual automated test script from Ganister PLM. It show that part C1.0 is forked and in the same Engineering Change Order (ECO) D and F are revised (from 1.0 to 1.1) in order to consume the result of the fork. Part C1.0 doesn’t change its state. It is still a released Part. Thanks to the graph we easily add a “fork” link to keep the traceability of the fork.
The next step will be to cover the case of a superseding fork. Pretty similar to this fork but changing the state of the former object.
As usual feel free to comment your objections !
As I’m now in the business of editing PLM software with Ganister. I have been involved in defining what would be a correct way of dealing with configuration management (CM)...
What is the language your PLM solution has been built with? It is something that barely comes up in PLM evaluation. Does it matter? I think so, but in order to know why it matters...