But We Lock Files Before Editing — Moving from Lock-Based SCM to Concurrent Development

There's a question that comes up in nearly every public-sector meeting we do:

"Right now, before anyone edits source code, they lock the file first. How does your solution handle this?"

Organizations that have run a commercial, foreign-vendor SCM for a long time ask this one first. Check out a file, it locks, and nobody else touches it until you check your change back in. From inside that world, "multiple people editing the same file at the same time" doesn't sound like a feature. It sounds like an incident report waiting to happen. It's a legitimate worry, and this post is an attempt to answer it properly.

How is lock-based SCM different from the Git model?

Lock-based SCM prevents conflicts from ever occurring; Git allows them and resolves them at merge time. In academic terms it's pessimistic versus optimistic concurrency control, but the practical translation is this: the lock model buys safety by enforcing "one person per file." The price is that the second person who needs that file waits until the first person is done.

Git goes the other way. Everyone branches, edits concurrently, and the tool merges the changes when they come back together. If two people touched different parts of the same file, no human is involved at all. Only when the same lines change does a conflict appear, and then a person decides which side wins. So the cost you paid as waiting in the lock model, you pay as occasional conflict resolution in Git. In most codebases the second bill is dramatically smaller, because two people editing exactly the same lines over the same period is rarer than it feels.

Honestly, this comparison isn't news. Git won this argument more than fifteen years ago. The real weight of the question is in what comes next.

Without locks, where does the control go?

The control locks used to provide doesn't disappear; it moves from file locking to workflow gates. In the lock model, the lock was quietly doing two jobs. One was preventing concurrent edits (a technical problem). The other was making sure nobody could change things casually (a governance problem). Merging replaces the first, as above. What replaces the second is branch protection and change-request approval.

In CollabOps, production branches carry protection rules: no direct pushes, no force pushes, no branch deletion. Every change must go through a Change Request, collect a required number of approvals, and pass required checks (build, tests, security scan) before it merges. There's a reason we deliberately say "Change Request" instead of PR or MR: it's exactly the unit that change-approval procedures in government and finance are built around.

The decisive difference between a lock and a gate is what moment gets controlled. A lock controls the moment of editing. A gate controls the moment of integration. And what governance actually needs to protect is the latter — not who opened which file, but what entered production code under whose approval. Lock-based setups often lose that evidence precisely because the approval workflow lives outside the SCM, in a separate sign-off system.

So how does version control actually proceed, step by step?

A single change runs as one connected flow, starting at an issue and ending in the audit log. In order:

1. Issue: the requirement or defect is registered. The "why" of the change lives here.
2. Branch: a working branch is cut from the issue. Instead of locking a file, you create your own workspace.
3. Commit: edits are recorded line by line. Who changed which line, and when, is traceable directly in the web UI.
4. Change Request: to integrate, you open a CR. Reviewers are assigned and the approval process starts.
5. Review and pipeline: human approval and automated checks (build, test, scan) run in parallel. Both must pass.
6. Merge and deploy: only changes that clear the gates reach the production branch, and deployment follows from there.
7. Audit log: the entire path is recorded automatically. No screenshots and spreadsheets at audit time.

If you're coming from a lock model, step 3 is the one to look at. Lock-based tools do know who last checked in a file. But following "which requirement caused this line to change, and when" in a few clicks is a different order of capability. History lives at the level of the change and the line, not the file.

What happens to the history in our current SCM?

Existing history comes with you, and there are three transition modes to choose from rather than one. The principle we hold for legacy SCM is simple: we don't make you lose your history.

• Full migration: move to Git with revision history, author mapping, commit messages, and tags preserved.
• Read-only indexing: leave the existing repository in place; browse and trace it from CollabOps. Coexistence without migration.
• Mirror mode: keep both sides in sync and transition team by team.

In an air-gapped network this has to run without internet access, which is what the CLI-based offline import is for. To be straight about limits, though: the migration paths we've documented cover SVN and Git-family hosting. The proprietary storage formats of commercial lock-based tools aren't a standard path, so the transition route has to be designed together, based on what that tool can export. It's an item we answer with "that needs joint review" in meetings, and the answer here is the same.

One more thing. What accumulated on top of the lock model isn't just data, it's a way of working. File-level ownership, check-in turn-taking — those habits don't change because the tool changed. Which is why we recommend starting with one team and one system rather than a big-bang cutover, for the same reason we wrote about in stability is the reference: the incident-free period itself becomes the argument that convinces the next team.

The lock has kept that organization safe for twenty years. A vendor who doesn't respect that fact isn't worth listening to. Our claim is not that you should abandon the lock. It's that the thing the lock was protecting can now be protected more cheaply and more completely, by what has long since become the standard. No waiting, and with better evidence.