Tell me, oh dear reader, what is the usual way to show a change in a blueprint? Yup, little silly clouds. But wait, we, engineers, have a technical term! Because, you know, you need to sound smart when you charge thousands of dollars to draw clouds on a sheet of paper. Those are called revision clouds.
Revision cloud, from the Autocad user’s guide.
Changed the width of a wall? Cloud! Changed the description of an item? Cloud! Changed anything at all? Cloud!
Well, many revisions here!
And how, in our infinite wisdom, do we keep track of these cloud? We add some descriptions in the cartouche (also known as title block). If you are lucky, these descriptions will somehow be linked to their respective clouds. If you’re unlucky… good luck maintaining accurate drawings!
It’s easy to say to ourself: “Ah, I’ll just update it when I make a change…” Unless you are working on candyland’s problems, chances are that all your grey matter will be used elsewhere when the time for modification arises. Or maybe I’m just dumber than the rest of you. I know I always forget some little things here and there… But even if you are super smart, can you guarantee that you will be the sole editor? Perhaps an intern will need to change it one day…
Versus software engineering
Programmers have to deal with version changes all the time. Do they draw little ASCII clouds in the source code? Perhaps they could add commentaries to describe the cloud too?
._''^^''-------''-----'''-------'''_ ( (let (current-item (pop list)) ) \ (print current-item)) / ^-----________-___------__-----_--/ Oh hai there! I changed this ^^
NO THEY DON’T! ARRRG! They have special softwares for this, named version control system1. These softwares will, on demand, show the difference between versions of the source code. You can even re-build an older version of the software, if you so desire.
Surely there’s a way out? Some days ago I received a revision for a project I was working on. Remember when I was raging against revision cloud? Well, having NO revision mark whatsoever is worse. I like to think of myself as a resourceful person, so I tried to use diff-pdf on the revised blueprint. This nice little software will color any differences in 2 PDF. Problem solved?
FUCK ME! The drawer moved the output view of about 3mm, making sure any output from diff-pdf would be unusable! (You can see it more clearly by looking at the axis’ bubble in the lower left.)
The big problem here is that I’m comparing a view, not the drawing itself. Consequently, the exported PDF can’t be used to generate revision cloud. When you think about it, in the software world they don’t try to compare the executable, but rather the source code. Transposed in the mechanical word, it means the .dwg, .slddrw, .iges, .par, .dxg…
What I propose is to join your source file to the PDF. (yes, you can join files in a PDF, just like for an e-mail.) In fact, a good practice would be to always join the source with a PDF. This way, even if you stumble upon the file in 10 years, you have all its precious data with it.
Think of it this way: which file (if any) the building’s janitor/technician/owner is most likely to keep and duplicate over the years?2 He’s going to make sure the document with which he works is available. “Oh, but at building-x they know they have to keep the original files preciously!” Right, they will put them delicately in a secure folder. 3 hard drive’s generations later, the files will have mysteriously disappeared.
Still, it doesn’t solve the revision problem. And frankly, I have no idea how to really solve it. (The title is “Version control in mechanical engineering sucks”, not “I solved mechanical engineering version control!”) Joining the source might help, especially with software such as DWG Diff. But in order to search for solutions, we must first realize how much the statu quo sucks. Next time you manually place a cloud, repeat to yourself: “I feel like a monkey. This is unacceptable!”