The fundamental difference between Subversion (SVN) and Microsoft Visual SourceSafe lies in their approach to concurrent file access. Martin Fowler’s explanation from Patterns of Enterprise Application Architecture perfectly captures this distinction:
“Let’s suppose that Martin and David both want to edit the Customer file at the same time. With optimistic locking both of them can make a copy of the file and edit it freely. If David is the first to finish, he can check in his work without trouble. The concurrency control kicks in when Martin tries to commit his changes. At this point the source code control system detects a conflict between Martin’s changes and David’s changes. Martin’s commit is rejected and it’s up to him to figure out how to deal with the situation. With pessimistic locking whoever checks out the file first prevents anyone else from editing it. So if Martin is first to check out, David can’t work with the file until Martin is finished with it and commits his changes.”
The Two Locking Philosophies
Optimistic Locking (SVN, Git, Mercurial)
Philosophy: Trust that conflicts will be rare and manageable when they occur.
How it works:
- Multiple developers can edit the same file simultaneously
- Changes are merged automatically when possible
- Conflicts are detected at commit time
- Developers resolve conflicts manually when automatic merging fails
Benefits:
- No blocking - Developers never wait for file access
- Parallel development - Teams can work on related features simultaneously
- Better branching - Supports complex branching and merging workflows
- Offline work - Developers can work without constant server connection
Pessimistic Locking (Visual SourceSafe, SCCS)
Philosophy: Prevent conflicts by ensuring only one person can edit a file at a time.
How it works:
- Developer “checks out” a file, locking it for exclusive access
- Other developers cannot edit the file until it’s checked back in
- No conflicts occur because only one person can modify at a time
- Files must be explicitly unlocked for others to access
Drawbacks:
- Productivity bottlenecks - Developers wait for file access
- Absent colleague problems - Locked files become inaccessible
- False dependencies - Artificial serialization of independent work
- Limited collaboration - Difficult to work on related features together
Real-World Impact
Since adopting SVN, our team’s productivity improved dramatically. We eliminated these common frustrations:
The File Hostage Situation:
“Where’s John? He’s not in today? But he’s got a file checked out that I need.”
The Artificial Dependency:
“Can you check in the project? I need to add a file.”
The Context Switch Nightmare:
“I’m in the middle of debugging, but Sarah needs me to commit so she can continue.”
Why Optimistic Locking Wins
1. Conflict Reality Check
Most source code conflicts are either:
- Non-overlapping - Different functions/classes in the same file (auto-mergeable)
- Trivial - Whitespace or import changes (auto-mergeable)
- Semantic - Require human judgment but are infrequent
Pessimistic locking prevents all concurrent editing to avoid the small percentage of meaningful conflicts.
2. Modern Development Patterns
Today’s development practices favor:
- Feature branches - Parallel development of different features
- Continuous integration - Frequent small commits
- Distributed teams - Asynchronous collaboration across time zones
- Pair programming - Multiple people working on the same code
Pessimistic locking fundamentally conflicts with these patterns.
3. Tool Evolution
Modern version control systems provide sophisticated conflict resolution:
- Three-way merge - Shows base version, your changes, and their changes
- Semantic merge tools - Understand language-specific constructs
- Visual diff tools - Highlight conflicts clearly
- Automated testing - Catches integration issues that manual review might miss
Best Practices for Optimistic Systems
Minimize Conflicts
- Communicate - Coordinate with teammates on overlapping work
- Commit frequently - Smaller changes are easier to merge
- Pull regularly - Stay current with others’ changes
- Refactor - Well-structured code has fewer merge conflicts
Handle Conflicts Gracefully
- Don’t panic - Conflicts are normal and manageable
- Understand both sides - Read the conflicting changes carefully
- Test thoroughly - Ensure merged code works correctly
- Ask for help - Involve original authors when conflicts are complex
Historical Context
Visual SourceSafe represented early thinking about version control when:
- Network connections were unreliable
- Merge tools were primitive
- Teams were smaller and co-located
- Files were larger and more monolithic
These constraints no longer apply to modern development, making optimistic locking the clear choice for team productivity.
The Bottom Line
Optimistic locking transforms version control from a bottleneck into an enabler. While it requires developers to handle occasional conflicts, this small overhead is vastly outweighed by the elimination of artificial blocking and the enablement of true parallel development.
The productivity gains are immediate and measurable: fewer interruptions, faster feature development, and happier developers who can focus on coding rather than coordinating file access.