Legal Version Control is 30 Years Out of Date
...and law firms are exposed to millions of dollars in liability
The cost of outdated version control can be measured in millions.
Last year, I attended a friend's wedding in my home state of Michigan. At the wedding, I spoke with an engineer named John who worked for an auto parts manufacturer. As we made small talk and discussed our work, I described how I was building a git-like version control system for documents.
This caught his attention. John leaned in and told me about a disaster that had just cost his company millions.
His firm had landed a contract with one of the big-three Detroit auto companies to design an engine part. After the initial prototypes, the client requested modifications. Simple enough — John and a colleague split the work. Both downloaded the latest CAD file from their cloud system and got to work on their respective changes.
When they finished, each uploaded their version. A few minor revisions later, the part went into production. Ten thousand units rolled off the line and shipped out.
Then the client called. Where were the modifications they'd requested?
John was baffled. He knew he'd implemented those changes. He could remember doing it. But when they investigated, the truth emerged: his colleague had saved his version after John, unknowingly erasing every change John had made. Neither engineer had any idea until those 10,000 incorrect parts were already in customers' hands.
The production line had to run again. Millions of dollars, gone—all because their version control system couldn't handle two people working on the same file.
When I published my essay “On Building Git for Lawyers” last fall, several people pushed back. "Don't document management systems and SharePoint already have version control? Aren't you building something that already exists?"
(Another common question—"Why don't lawyers just use Google Docs?"—deserves its own discussion, which I covered in my previous essay.)
John's multi-million dollar disaster illustrates why these systems are inadequate. They use linear version control — a paradigm software developers abandoned in 1986. The modern standard, Git, uses concurrent version control instead. And that changes everything.
Here's how we fix it — and why the transformation is inevitable.
Alice and Bob collaborate
Standard Linear Version Control
Alice and Bob are roommates who share a digital grocery list. Their system creates a new version every time someone saves—V1 becomes V2, V2 becomes V3, forming a straight line. This is linear version control.
They both check the list:
Alice opens V1 and adds butter and eggs.
At the same time, Bob has V1 open and adds apples.
Alice saves first—creating V2 with her butter and eggs. Bob saves next—creating V3 with his apples.
The problem: V3 doesn't have Alice's butter and eggs. Bob's save completely overwrote her changes. She added butter to the list, but it vanished when Bob saved his version.
This is a race condition—the same type of problem that cost John's engineering firm millions. Two people editing one file, and changes disappearing without anyone realizing.
Fortunately, there are ways to prevent this. The solution is called a "concurrency mechanism," and there are two approaches: pessimistic (taking turns) and optimistic (working simultaneously). Let me show you how each one works.
Locking Linear Version Control
The first version control systems solved this with a straightforward approach: only one person could edit at a time.
Bell Labs introduced this in 1972 with SCCS (Source Code Control System). The concept is like checking out a library book — while you have it, no one else can modify it.
Here's how Alice and Bob's grocery list would work:
Alice checks out V1 to add her items
Bob tries to edit but sees it's checked out — he must wait
Alice adds butter, removes bread, and checks in V2
Bob can now check out V2, add apples, and check in V3
V3 contains all the changes from both collaborators. The race condition is prevented.
The downside is clear: Bob had to wait for Alice to finish. In professional settings with urgent deadlines, this bottleneck becomes a serious limitation.
Concurrent Version Control
But what if Alice and Bob need to make changes simultaneously? This is where concurrent version control comes in.
Software engineers developed several systems over the years—RCS in 1982, CVS in 1986, Subversion in 2000, and finally Git in 2005. These systems assume most edits won't conflict and let everyone work at once.
Here's how it works with Git:
Alice checks out V1
Bob also checks out V1
Alice adds her items and checks in V2
Bob adds his items, but before creating V3, Git requires him to "merge" Alice's changes from V2 into Bob's working copy
When Bob checks in V3, it contains both sets of changes
No waiting. No lost work. Both collaborators can work simultaneously, and the system handles the coordination.
Legal Version Control
Now let us return to the objections that people raised to my previous essay.
What are the options that lawyers currently have at their disposal?
Option 1 — Standard linear version control
Most document storage systems use standard linear version control. As we've seen, this creates a fundamental problem: race conditions.
When two lawyers download the same contract, make different edits, and save their versions back to the system, whoever saves last erases the other's work. There's no warning, no conflict detection—changes simply vanish.
This creates constant uncertainty. Did your colleague's save overwrite your redlines? Is the "final" version in the document management system actually missing critical edits? When millions of dollars depend on contract language, this ambiguity is more than an inconvenience—it's a liability.
Option 2 — Locking linear version control
Some systems like SharePoint address the race condition problem by adding locks. Users "check out" documents for editing, and colleagues must wait until they're "checked in" before making changes.
But locking creates its own problem: bottlenecks. When it's 11pm and a deal needs to close by morning, you can't wait for someone to finish their changes before starting yours. The legal profession operates on parallel timelines—multiple specialists often need to review the same document simultaneously.
So what actually happens? Lawyers have developed an elaborate workaround.
One person checks out the document from the system, then emails copies to all the specialists who need to review it. Each specialist marks up their copy independently. Then comes the painful part: someone (usually a junior associate) sits with multiple redlined versions open, manually copying changes from each document into a master version. Only after this manual merge process does the document get checked back in.
This isn't efficient collaboration. It's a workaround for a broken system.
Don’t pave the cow path
Legend has it that in the early days of Boston’s urban development, city planners noticed the paths that cows created from walking over them repeatedly and paved them. Rather than designing a logical street grid, they created the notoriously convoluted set of roads that now make up Boston’s historic districts.
The legal profession has been forced down a similar path. Without tools that support simultaneous editing, firms have had to develop creative solutions: detailed naming conventions to track versions, careful coordination protocols, and the manual merge process I described above. These practices have become so standard that it's easy to forget they exist solely to work around technological limitations.
But these shouldn't be permanent features of legal practice. They're detours around a problem that concurrent version control solves entirely.
Option 3 — Concurrent Version Control
Concurrent version control allows lawyers to make changes at the same time without fear of overwriting each other’s changes.
Multiple lawyers can work on the same document simultaneously without overwrites or bottlenecks.
Here's how it works:
Each lawyer edits their own copy of the document independently
When ready, they merge their changes back into the main version
Document versions are displayed visually The system automatically combines non-conflicting edits
For conflicting changes (when two people edit the same paragraph), the system flags the conflict and lets a lawyer decide which version to keep
Every edit is tracked—you can see exactly who changed what and when.
No more manual merging. No more waiting for check-ins. No more anxiety about lost changes.
This is the system software developers have used for decades. The time has come for lawyers to enjoy the same benefits.
The Future of Legal Version Control
When software engineering adopted concurrent version control, it didn't just change how developers saved files—it transformed the entire profession.
Git and similar systems eliminated bottlenecks and enabled truly parallel workflows. Developers could work on separate features without blocking each other or fearing overwrites. This technological shift reshaped how software teams organized themselves. Small, autonomous teams could tackle different parts of complex systems simultaneously. New methodologies like Agile and DevOps emerged, built on the foundation of rapid iteration and parallel development. The tools didn't just support the work—they fundamentally changed how the work got done.
Law faces a similar transformation.
First, the immediate benefits: no more elaborate workarounds. No more arcane naming conventions like "Contract_v3_FINAL_JB_edits_CLEAN.docx". No more policies about who can check out documents when. The system handles the complexity, letting lawyers focus on the law.
But the deeper changes will reshape legal practice itself. When teams can truly collaborate in parallel, new workflows become possible. Perhaps we'll see legal methodologies that mirror Agile—rapid iterations on contract language, parallel specialist reviews that merge seamlessly, faster deal velocity without sacrificing quality.
And concurrent version control opens doors for AI workflows that linear systems can't support—but that's a topic for another essay.
The tools are changing. The profession will follow.