The shared drive folder everyone recognizes
Open almost any engineering shared drive and look for the CAD folder. You'll find it:
Bracket_v2.step
Bracket_v3.step
Bracket_v3_FINAL.step
Bracket_v3_FINAL_revised.step
Bracket_v3_FINAL_revised_JK.step
This is the naming convention trap. It seems like versioning. It feels intentional. But it's just naming after the fact, and it solves none of the real problems.
When you see this folder, you know something is missing: a source of truth for which file is current, who changed what, when they changed it, or why. When two engineers edit at the same time, one person's work silently vanishes. When an auditor asks for the design history, the only answer is a story reconstructed from memory and email threads.
This pattern shows up across teams and industries wherever proper tools are absent.
What good versioning actually gives a team
Version control is simpler to describe than the _FINAL_revised folder is to manage. A good system does three concrete things:
It tracks who did what and when. Every change carries an author, a timestamp, and a message explaining why the change happened. Not why it's good. Why it happened. When someone edited the bracket, you know their name, the time they committed, and the rationale. That's the beginning of trust.
It never loses work. When you save a file to a shared drive, you overwrite what came before. When you delete a branch, you erase the path you were exploring. Version control remembers both. Every revision exists in history, so you can return to it, compare it, or understand why it was abandoned. Work doesn't vanish because the network hiccupped or someone hit the wrong key.
It keeps related changes together. A real engineering revision touches multiple files: the CAD model, the drawing, the BOM, the simulation deck. Good version control treats them as a single commit. The relationship between a model and its downstream documentation is preserved, so you never open a drawing that's two revisions behind the part it's supposed to describe.
Those three things add up to a fourth: you can answer any question about the design's history clearly and completely. "What changed between revision 5 and revision 7?" The tool shows you. "Who approved this change and when?" The commit message and timestamp tell you. "Did anyone else edit this assembly while I was working on my branch?" The merge process will tell you, and it won't let changes collide silently.
The naming trap and why it persists
The reason naming conventions persist is that they work just well enough to seem sufficient. If everyone follows the same pattern, you can glance at the filename and know roughly where you are in the design cycle. It's a form of version control that costs nothing to implement, which is why it's everywhere.
But it only works when you're alone or when your team is small and disciplined. The moment you add a second person editing the same file asynchronously, or the moment someone forgets to append _v4 before saving, the whole system breaks. And it doesn't fail gracefully. It fails silently. You think you're working from the latest revision, and you're actually working from a three-week-old file, because nobody told you the real current version was in a folder called "Final Designs (REAL)" on someone's desktop.
The naming convention is friction masquerading as simplicity. It looks easy at first, then it becomes a recurring argument about whether v3_FINAL or FINAL_v3 is the official one.
Real version control removes the naming burden entirely. The version lives in the system. You can name files sensibly and know that the version history is always accurate, always visible, and always consistent.
The path from shared drives to version control
Moving from a shared drive to real version control doesn't require replacing everything at once, and it doesn't require specialized enterprise software.
Start by choosing your system. For engineering teams, the system should understand binary files like STEP, SolidWorks parts, drawings, and simulation results. It should work offline, because connectivity is never guaranteed on a job site or in the lab. It should be lightweight enough to adopt without a six-month IT project. Git-based systems with Git LFS handle all of this, and there are open source tools built specifically for engineering workflows that sit on top of them.
Set up a repository. This is simpler than it sounds. A repository is just a folder on a server or in the cloud that remembers every version of every file that's committed to it. Initialize it, point your team at it, and establish a basic rule: all CAD work goes through version control.
Establish a branching pattern. You don't need a complex one. The simplest pattern is: main branch holds the current design, and anyone making a significant change creates a feature branch, commits their work there, then merges back when it's done. The main branch stays stable and always reflects what's in production or under manufacture. Feature branches isolate work in progress, so two engineers can modify the same assembly without colliding.
Document your commit messages. This is the least glamorous step and the one that pays off most. A commit message that says "updated bracket" tells you almost nothing. A message that says "reworked mounting bracket to clear new harness routing per Jim's review" tells you what changed, why it changed, and who the context came from. Six months later, when you're designing a variant and wonder why the bracket is shaped this way, the answer is there.
Plan for the files that can't move yet. Most teams can't move everything to version control immediately. There are archived projects, legacy data, vendor files that you can't modify. Don't block. Version control the active work, and make the decision to include the rest on a schedule that makes sense for your team.
What shifts when you make this move
The first shift is psychological. You stop asking "is this the final file?" because every file in the repository is final until you commit a new revision. You stop reconstructing history from email threads because the history is built in. You stop writing longer and longer filenames as a substitute for proper record-keeping.
The second shift is operational. Your team stops losing work, because overwriting a file in version control requires an explicit merge, and the system won't let you overwrite someone else's changes without acknowledging that you're doing it. Two engineers can work on the same assembly in separate branches, and when they merge, the system tells them where the conflicts are instead of silently picking a winner.
The third shift is structural. Version control becomes the source of truth. The shared drive can get smaller, holding only the current production data. Old versions live where they belong: in the commit history, preserved and retrievable, rather than scattered across a folder nobody dares touch.
Why this matters to people and teams
Good versioning is a practical tool, but it has a human payoff that's easy to overlook until you need it. It removes a class of arguments from your team's life. No more "wait, did you work from the latest file?" No more "I thought you were updating the BOM but apparently you were using the old assembly." No more Friday afternoon discoveries that someone's work from Wednesday disappeared because two people saved over the same file.
It also removes a category of stress. In regulated industries like aerospace, automotive, and medical devices, you eventually have an audit. Someone will ask for the complete design history. Teams without version control dread this. Teams with good version control answer the question in minutes, because the answer is already there in the commit log. That's not just an operational benefit. It's peace of mind.
The path from shared drives to real version control is straightforward, and the tools to do it are available. Your team can start with the approach detailed in our guide to engineering version control, or jump straight to implementation with OpenVault, which is open source and installs in minutes. The cost of staying with the naming convention is accumulating every day. The cost of moving is a deliberate step, taken once.