“Branch & merge” debates and PDM granularity

“Branch & merge” debates and PDM granularity

Do you remember discussions about true and fake  clouds few years ago? It was a trend among PLM and ERP vendors trying to prove that “my cloud” is the best one. Want to get back and read some of these stories? Here are few links on old posts from me and some PLM vendors. Once the dust settled, we can see a diversity of needs, solutions and benefits.

My attention was caught by another notion of “fake” debates in the industry. Now it is between CAD vendors discussing new “branch and merge” data management mechanism. Onshape blog – Don’t be fooled by fake “branching & merging” . Onshape was pioneering the idea of branch & merge in CAD leveraging their own data management and PDM features.

Quick video demonstrating Onsahpe branch and merge is below.

Solidworks 2018 came up the fight announcing Branch & Merge functionality in their coming update of Solidworks PDM 2018. Navigate to the following link in Solidworks 2018 docs and read more about Solidworks 2018 Branching and Merging.

The following video can give you an idea of how Solidworks 2018 branch and merge works.

I’m not sure, there is a conflict here. The discussion about branch and merge made me think about data granularity. In software configuration management “branching” is one of the standards operations. As a software engineer, you’re branching and merging your code many times. However, in PDM it was not a case. And the main reason was related to the nature of CAD files. Read my earlier blog – CAD files: Root cause of PDM nightmares. Files and operations on files are creating a huge challenge to PDM developers, which made branch and merge operation somewhat unpopular and sometimes impossible.

From that standpoint Solidworks is probably doing a good job automating some file operations by helping users to copy and replace correct CAD files to working folders. There is nothing wrong with that, because if you want to ‘branch’ your design in Solidworks, the problem of copy files and preserving right copies is not a simple one. But files are remaining PDM killer and therefore Onshape is capable to do something even more because Onshape doesn’t have this file limitation. Onshape branch and merge is going even deeper in the model and allows you to combine features and operations on the level of microversions.

What is my conclusion? I’m not sure,  branch and merge functionality has clear definition. Based on software best practice you can expect merge to be very granular like Onshape does. However, from pure PDM standpoint, file is the most granular level PDM is capable to manage. The devil is in details and in what functionality is needed for user. Marketing will do their job and will help us to clarify what are differences between both options. And CAD companies will keep their innovative development to bring the best solution to customers. Just my thoughts…

Best, Oleg

Want to learn more about PLM? Check out my new PLM Book website.

Disclaimer: I’m co-founder and CEO of OpenBOM developing cloud based bill of materials and inventory management tool for manufacturing companies, hardware startups and supply chain. My opinion can be unintentionally biased.

Share

Share This Post

  • Pingback: GHZ Partners | IT Services, Software()

  • I agree Branch and Merge is an important features when developing new product.
    At that page, we explained how it works in beCPG (it is not related to CAD):
    http://becpg.blogspot.fr/2014/02/new-product-development-trials-and.html

  • beyondplm

    Philippe, thanks for sharing the link. Version graph becomes a norm in lifecycle management and revision control. It is a good thing.

  • Loïc M.

    Oleg,

    I do not see your problem with files and operations on files. In software industry, the code is divided into files and can still can be branched/merged by the version controlled systems…

    Actually, if you think of the data representation in the PDM/PLM (also metadata, not the file), each revision of a part is already a branch of that part for the system. It apply to all versioned objects (document, CAD files, etc.). By “revising”, the systems creates a new object (revision) as clone of the input revision and then modify it.

    The SaveAs / Clone functionalities of PDM system also creates a new branch, but applying a different part number.

    OK, I admit theses “branches” are not intended to be merged later…

    I think the use of branches would be really useful to manage the features but PLM software companies should describe some best practices for designers (at it is/should be done in software development); otherwise it will only be even more confusing.

    I think this would really help for Change Management processes to have some “candidates” changes defined as branches, and when . This could allow to manage more efficiently many change requests (features) on the same parts.

    Loïc

  • beyondplm

    Loïc, from my experience of developing several PDM systems, files are turning to be a nightmare. You need to keep local copies, move them between locations, etc. etc… so, working with database without files is much easier. Also, it allows technically to 2 people to work on features that in file based system located in the same file.

    It open additional “branching” options. If your intention is not to merge part of one branch to a part of another branch, you can go with files. This is what SW PDM does and many others. However, if you want to be more granular, files will stop you .Think about your software example -you’re operating with source text – not files. I can get piece of one source and combine it with piece of another source code. Granularity is a key.

  • Loic Mouchard (Innoface)

    I really understand the merging functionality from Onshape, and find it good.

    With software code, I definitely handle files (with different formats). I could be java, property files, xml, javascripts, html, etc.

    The PLM software vendors decided to keep CAD-PDM integration complex storing the file in their own protected format ;), but it does need to be so.

    By the way, memory capacities are nowadays allow you not working with physical local files, the content can be cached in the memory of the client.

  • beyondplm

    This is another reason why you don’t need files anymore –> “By the way, memory capacities are nowadays allow you not working with physical local files, the content can be cached in the memory of the client”. I don’t see a direct connection to format protection. I can write it in the database in protected format as a blob or similar object. Also, in some CAD systems, assembly is just a text file.