The architectural difference

Subversion is centralised: one server holds the canonical repository; clients hold working copies that are mostly snapshots. Without the server, you can edit files but not commit, log, branch, or merge.

Git is distributed: every clone is a complete repository. You can commit, branch, merge, view history, run blame, and rewrite locally without any network. Sharing happens via push and pull, but it is layered on top, not fundamental.

What "distributed" enables

• Offline commits - work on a plane, commit, push when you land.
• Local experimentation - branch, mess up, throw away, all without the server caring.
• Disaster recovery - if origin disappears, any clone has the history.
• Multi-master workflows - several teams can push to different mirrors and reconcile via merge.
• Decoupling code from a vendor - migrating from GitHub to GitLab is a few hours; from a bespoke SVN host, far more.

What centralisation enables

• Single source of truth - the server's state is the project's state.
• Per-path access control - SVN can hide subdirectories from specific users.
• Sequential revision numbers - r12345 is unambiguous; Git SHAs are slightly less human-friendly.
• Locking - binary files can be locked exclusively, preventing concurrent edits.

Practical comparison

# Offline in Git
git commit -m "WIP"
git log
git diff HEAD~5
git checkout -b experiment

# Same operations in SVN, offline:
svn commit       # error: cannot connect to server
svn log          # error: cannot connect to server
svn diff -r 100   # error: cannot connect to server (for arbitrary revs)

SVN does support some offline operations - svn status, svn diff against the base revision, file edits - but the moment you need history older than your working copy or want to branch, you need the server.

Mobile and remote work

The decade between SVN's and Git's primes saw the rise of mobile development, train commutes, conferences, and (more recently) global remote work. Engineers expect to work on a flight; expect to commit a bug fix from a hotel; expect tooling that does not collapse when wifi flickers. Git was designed when this was novel; it now matches expectations natively.

Disaster recovery

If a Git server's storage fails, recovery is straightforward: pick any clone, push to a new server, done. Even a developer's laptop usually has all branches plus tags. SVN recovery means restoring server backups; clients have only working copies.

# Git: recover central repo from a clone
git clone --mirror /path/to/laptop/clone backup.git
cd backup.git
git remote add origin git@new-host:repo.git
git push --mirror origin

# SVN: requires server-side dumpfile
svnadmin dump /var/svn/repo > repo.dump
# restore on new server

Caveats with distributed

• Distributed creates a coordination question - which clone is canonical? Conventions and tooling (origin, branch protection) answer this socially.
• Forks can diverge silently if no one merges; central servers force a single timeline.
• Auditing and access control require explicit infrastructure - Git itself has minimal access control built in.

Hybrid

Tools like git-svn bridge the two: clone an SVN repo as a Git working repo. You commit, branch, rebase, and rewrite locally; git svn dcommit publishes back to SVN. This is a practical option during migrations or when corporate policy requires SVN as the system of record.

Distributed is not always better - just often. Pick deliberately, with the actual work environment in mind.