Two philosophies

Subversion (SVN), released in 2000, is a centralised version control system. The repository lives on a server; clients check out working copies, commit back to the server, and update from it. Git, released in 2005, is distributed: every clone is a full repository with complete history, and there is no architecturally privileged server.

Mental models

SVN's mental model is the file cabinet: one shared place, everyone goes there to read and write. Git's model is more like email: every participant has the full history, and "publishing" means pushing to a server everyone agrees to treat as canonical.

What SVN got right

• Simple to explain - one central server, working copies, commits.
• Fine-grained access control at directory level.
• File locking for binaries that cannot be merged.
• Linear, monotonic revision numbers (r12345) easy to reference.
• Stable for very large repositories of mixed content (text and binary).

What Git got right

• Cheap, fast branches and merges encourage experimentation.
• Full local history enables offline work and instant log/diff.
• Distributed model survives server outages and host changes.
• SHA-based content addressing detects corruption automatically.
• The ecosystem - GitHub, GitLab, hooks, CI integrations - is vast.

Day-to-day commands compared

# SVN
svn checkout https://svn.example.com/repo
svn update
svn add file.txt
svn commit -m "Add file"
svn log

# Git
git clone https://git.example.com/repo.git
git pull
git add file.txt
git commit -m "Add file"
git push
git log

Where the philosophies bite

In SVN, "commit" means publishing to everyone immediately. In Git, "commit" is local; "push" publishes. SVN users sometimes find this disorienting; Git users sometimes find SVN's lack of staging frustrating. Neither model is universally right - they suit different workflows.

Branching

SVN branches are server-side directory copies. They work, but the metaphor leaks - a branch is just a folder, and switching branches means swapping working copies. Git branches are lightweight refs. Switching branches in Git is an instant pointer move; in SVN it can be a multi-minute file shuffle.

# SVN branch
svn copy https://svn.example.com/repo/trunk \
         https://svn.example.com/repo/branches/feature -m "Branch"

# Git branch
git checkout -b feature

Why Git won market share

Three factors: GitHub's network effects from 2008 onwards; the dominance of Linux and the kernel's choice of Git; and the rise of cloud and remote development, where distributed semantics map naturally. SVN did not get worse - the world changed around it.

When SVN remains a sensible choice

• Large binary repositories where merging is impossible and locking is essential.
• Tightly controlled environments with strict per-directory access control.
• Established tooling pipelines (build systems, IDE integrations) that depend on SVN.
• Single-site teams that never work offline and value simplicity.

Coexistence

Tools like git-svn let teams use Git locally against an SVN server. This is a pragmatic transition path or a permanent solution where SVN must remain the system of record. The catch: history rewrites and complex merges in Git do not translate cleanly back to SVN.

SVN was the right answer for its decade. Git is the right answer for the current one for most projects, but "most" is not "all".