Ah, the twin pillars of Check In and Check Out, titans in the CAD pantheon and usually in the first breath or two of any conversation about Product Data Management (PDM). Long has this technique been the lynchpin in regulating data integrity for revision controlled items in a multi user environment. Undoing such a core feature seems like utter madness. Yet, it seems the world is changing. Social engineering projects are challenging the classical tenets of revision control, and there is growing sentiment that PDM as it stands today is insufficient for the future. At the center of this changing sentiment, are the branching and merging methodologies widely used in Software Configuration Management (SCM) with rather ubiquitous tools like Git and Subversion. Guess who’s coming to dinner?
Back in ancient times, last Tuesday to be exact for some, CAD engineers would bang rocks together to make files, files which had specific ownership in native directories. Ownership and exclusive access were the primary means of determining who worked with what to mitigate a total free-for-all. Some engineers, over time, became rather possessive and became attached to this model. In some cases this ownership model was replicated in PDM exactly, requiring ownership to be transferred from one user to another before access to change a file was granted. But there was clearly a better way. By offering a central repository, PDM removed the need for outright ownership to determine change rights. But a mechanism was needed to keep two people from working on the file at the same time – and that mechanism was Chekov, er – Check In and Check Out.
Changing a file required checking the file out. Sometimes the process was implicit (handled within the CAD system) other times the process was explicit (requiring manual intervention). Once the changes were completed, the file was checked back in. For some engineers overly attached to the prior ownership model, the fact that anyone could mess with their nuclear wessels was downright frightening. So it wasn’t long before particularly obstinate engineers would devise the camp out – essentially sitting on a check-out on purpose. Anyone questioning the camp out would be met with glaring. The issue was quickly rectified with reporting and automatic check-in. It seems so ridiculous that the check in/check out model was resisted in some circles, now that the mechanism is quite universal. It’s in every CAD management tool, document management app, and yes, even Sharepoint.
So now that everyone’s comfortable with check in / check out it may very well be time to throw it all away. Right into the ocean. The limitation of check in and check out is the serial nature of change. Have something that needs to changed often by lots of people? Well everyone just needs to get in line and take numbers. Now serving #1138. It’s just like the DMV, and we all know the DMV is the height of civilization. The answer is to just let change happen. All at once. Which is of course, madness. Or is it crazy like a fox?
The answer may lie in adopting software development methodologies, namely branching and merging. Case in point a snippet from a GrabCAD interview with open source engineer Matthieu Lapeyre:
“What do you think PDM solutions lack that you need?
PDM is missing the ability to branch, fork and make merge requests. With an open source project, especially an open source robot, people are making their own modifications but they don’t have editing rights for the main repository. They need to be able to make merge requests- send notifications from their repository to ours so their changes can be merged upstream. That’s better than everyone working on the exact same version.”
But let’s be real about this, Keptin. Merging and branching is hard enough with just the text file components in software, what’s to be done about CAD binaries and other file types? It’s a little more complicated that rerouting power from the phaser banks. Up until this point, the answer has been to run away. But I don’t think it’s an impossible feat. That’s a technology worth working on. It’s high time someone started attacking this problem directly.
Google Docs, for example, has simultaneous edits, provided you author the documents using their web tools – but their vision of revision control is lacking in fidelity. In the CAD space, at least one major player is thinking at least peripherally along these lines. Just recently Chad Jackson penned an article describing capabilities in ENOVIA V6 where metadata elements associated with CAD are essentially decimated as separate database objects to allow simultaneous editing. Here’s a passage that explains the idea:
“The important point here is that those changes occurred serially, one after the other. With two users, that may not be a big deal. But once you scale that up to, say, twenty users collaborating on 100 parts, users need to get in line to modify a part. Or worse yet, users simply own a part with no one else touching them, eliminating any collaboration.
With Dassault Systèmes’ approach, the need to explicitly coordinate change or wait in line for modifications is removed. All that meta-data can be modified simultaneously and independently. Design teams can work more collaboratively and quickly.”
This particular concept is not without its serious problems, and is not branching and merging outright. But still partial credit for some incremental ideas in trying to solve the problem of serial change. What do you think? Are software branching and merging concepts the future of not only social engineering, but all hardware engineering? Or are we better served by blowing the idea out the nearest airlock?