At a high level, whenever I explain product data management (PDM) systems to users who are wholly unacquainted with the overall concept, I make sure to highlight a few key benefits as soon as I open my mouth:
- PDM systems control versioning and storage of your CAD files (as well as other document types, such as Word, Excel, etc.).
- They allow you to administrate access rights in collaborative environments, thereby safeguarding against natural productivity killers like unintentional overwrites.
- You’re generally provided, with most PDM systems, far greater search tools than what’s afforded to you as part of being a Windows user utilizing its indexing service.
Beyond these general yet important benefits provided by most PDM systems, you’ll begin to see feature-driven benefits diverge into different segments from system to system. How files are managed across different PDM systems can vary greatly.
At least two of the general feature niceties I mentioned in the bulleted list above can sound, when read through a certain lens, fairly restrictive. We use terms like “control” and “access rights” frequently when describing “how things work” in the PDM universe. However, in the real world, design teams sometimes need a level of flexibility that doesn’t conform to standard PDM practices.
A perfect example of this is the practice—or art—of prototyping and ideation. Each company, with due consideration to the infrastructure of its internal teams, industry and aims goes through a phase of testing product design(s) at one point or another.
Sometimes, this is because we’re designing for market research purposes. Seating companies might wish to design multiple seat backings to see which one, in market research testing, performs best. Their desire might be to see which aesthetic looks best for e-commerce purchase appeal, or which is most comfortable (after all, customer reviews and experiences matter).
File- and project-based PDM archetypes would typically necessitate natural hang-ups in such workflows. Using tools like SOLIDWORKS PDM, once a file is checked out by a given user, this prevents other users from actively editing this project. This hits on bulleted item #2 in my list. Typically, item #2 is a great selling point, but when you’re trying to work on multiple ideas at once, it becomes… well, a “productivity killer.”
In my research for this article, I polled a couple of SOLIDWORKS PDM administrators in my network with the following question: “How might you use the new “branching and merging” functionality included in SOLIDWORKS PDM 2018?” One responder, Austin Broeker, a mechanical designer and CAD administrator from MiTek Industries, offered that the new branch/merge functionality incorporated into PDM 2018 “will be the most useful for [us] when we are developing a prototype without a clear best way forward.”
In polling some of my SOLIDWORKS power-user friends, it seems the new Branch/Merge tools (as they’re designed in PDM 2018) are a big hit.
In Broeker’s case, the branching and merging tools included in SOLIDWORKS PDM 2018 will play an active part in supplanting a role traditionally occupied by Configurations in some of MiTek’s SOLIDWORKS 3D CAD projects. Broeker added, “In the past, if I had several ideas for a prototype, I would model them all as separate configurations in one part/assembly file.”
Configurations are a great way to quickly build, utilize and switch between different iterations or versions of part and assembly files from within SOLIDWORKS. I’ve taught many SOLIDWORKS courses over the years, and I don’t believe I’ve ever met a single student who didn’t get the practical use value of the tool. However, configurations, by nature, are single-file conventions.
They are not designed to allow, for example, the concurrent editing of different part design concepts by different users. Whether you were using PDM or not, you’d only be able to edit one effective version of the physical file at a time. When Austin used configurations effectively as an idea/prototype organizer, his workflow included lots of undesired bottlenecks.
The Branch/Merge features in 2018 are not intended to replace Configurations in SOLIDWORKS, and they certainly won’t. Configurations are still ultra-desirable in all of the ways I mentioned in my lead-in paragraph. However, when it comes to having multiple users working on different design concepts concurrently, branching/merging has the potential to assist SOLIDWORKS PDM users quite a bit.
Using the branching feature contained in PDM 2018, SOLIDWORKS PDM users can opt to branch a given file into two or more separate files. Since this represents more than one file object at this point, separate users can work on separate concepts within separate file environments. This helps to negate the risk that design routes taken by any individual can be overwritten, or that individual file access rights stall the innovation workflow while user(s) wait for one person to check in changes to the vault.
Instead, users can work on different concepts in parallel without needing to worry about limitations to file access rights that are typically desired and necessary in PDM environments—just not here. Veteran SOLIDWORKS PDM users might be wondering, “Isn’t this sort of the same thing as Copy Tree in PDM? I’ve had that for years.”
At this point in the overview of the branching functionality, I’d absolutely understand one coming to that conclusion. Where Branch/Merge and Copy Tree differ is in the extent to which the copied or
“branched” filesets retain restorable linkages to the original fileset(s). In fact, on the Help page for Copy Tree on the SOLIDWORKS website, this distinguishable characteristic is spelled out fairly clearly.
SOLIDWORKS PDM’s Copy Tree can make a copy of a project file set, but the copied version is unrelated to the original (unlike Branch/Merge.)
The page defines Copy Tree, in summary, as a way for users to “copy a parent file with all its references to create a second instance unrelated to the original.” The key word there is “unrelated.” Branching a fileset—rather than performing a “Copy Tree”—allows users to maintain a database linkage to the original fileset(s). Why does it do this? You guessed it: to leave open the possibility of “merging” the “branched” fileset back into the original fileset object in the vault.
While Copy Tree can help you copy an entire project tree (including its version history), it does not offer project flexibility in the same ways Branch/Merge does in PDM 2018.
Granted, the above definition could certainly use some clarification. I will offer that here. It may be helpful to begin my clarification with a general definition of what “branching” and “merging” means. The concept of “branching and merging” has been used in computer software spheres over the course of many years. In a computer programming sense, for example, the concept of “branching and merging” applies closely to the challenge of version control with objects (or, in our case, CAD files).
Conveniently, Wikipedia offers a rather nice synopsis of this. Under its article for the term “branching,” you’ll find the following definition: “Branching, in revision control and software configuration management, is the duplication of an object under revision control (such as a source code file or a directory tree) so that modifications can happen in parallel along both branches. Branches are also known as trees, streams or codelines.”
This is, essentially, the style of branching SOLIDWORKS deploys within PDM 2018. It does not, for example, give one the ability to have multiple users sculpt a design in a single CAD part model space at the same exact time. It does, however, give PDM users the power to “branch” their project assets into several assets—even if it’s only temporary—so that “modifications can happen in parallel.”
When it comes to the concept of “merging,” Wikipedia offers this definition: “In version control, merging (also called integration) is a fundamental operation that reconciles multiple changes made to a version-controlled collection of files. Most often, it is necessary when a file is modified on two independent branches and subsequently merged. The result is a single collection of files that contains both sets of changes.”
It’s important to examine the final sentence in this definition, as it applies closely to the various ways “branching” and “merging” could theoretically be used in CAD and/or PDM. The SOLIDWORKS PDM 2018 scope of “branching” and “merging” allows one to take their branched project files and, at a time of their choosing, consolidate the then-disparate version history trees of each project fileset back into a single object in the PDM vault.
It’s also important to note that, in a software sense, this is an enhancement to the maneuverability of file objects. The concepts employed here are core to the roots of the terms “branching” and “merging” by their very definition. It won’t, for example, take one file with a hole and no fillets and a different file with no holes and two fillets and allow you to merge them into one file with a hole and two fillets. It will, however, make the experience of using SOLIDWORKS PDM a lot more flexible for ideation purposes for many users.
About the Author
Sean O’Neill is a Senior SOLIDWORKS Support Engineer at Fisher Unitech. He is a graduate of Villanova University and remains based out of the Philadelphia, PA area. He is a Certified SOLIDWORKS Expert (CSWE), a former SOLIDWORKS World Presenter, and a former SOLIDWORKS VAR Marketing Manager. You can follow him on Twitter: @ServicePackSean