Types of Version Control: Local, Centralized (SVN), and Distributed (Git)

Version control systems have evolved through three distinct architectural generations, each solving the limitations of the one before it. Understanding this evolution isn't just history trivia — it explains why Git behaves the way it does. Git's most distinctive features (working offline, having a full history on your own machine, fast branching) only make sense once you understand the centralized systems it was designed to replace.

Learning Objectives

Describe local, centralized, and distributed version control architectures.
Explain the single-point-of-failure problem in centralized VCS.
Understand why distributed VCS gives every developer a full copy of history.
Compare SVN and Git at a conceptual level.

Key Terms to Know Before Learning Types of Version Control

Local Version Control: A system where version history is stored only on a single machine, typically as a simple database of changes to files in one location.
Centralized Version Control System (CVCS): A system where a single central server holds the entire project history, and clients check out working copies from it (e.g., SVN, Perforce).
Distributed Version Control System (DVCS): A system where every user clones a full copy of the repository, including its entire history, onto their own machine (e.g., Git, Mercurial).
Single point of failure: A component whose failure can bring down an entire system — in CVCS, this is the central server.
Clone: The act of copying an entire repository, including all history, from one location to another — a defining operation in distributed VCS.

How Types of Version Control Actually Works

**Local Version Control** was the earliest approach. A developer would keep a simple local database that recorded the differences between files over time, often just on their own computer using tools like RCS. This solved the 'which file is the real final version' problem for an individual, but it offered no way to collaborate with anyone else — there was no shared history to work from.

**Centralized Version Control Systems (CVCS)**, such as SVN (Subversion) and Perforce, solved the collaboration problem by introducing a single central server that stores the entire project history. Developers 'check out' a working copy from this server, make changes, and 'commit' them back to the same central location. This made collaboration possible for teams, and administrators could control access from one place. But it introduced a critical weakness: if the central server goes down, or its disk is corrupted, nobody can commit changes — and depending on backup strategy, the entire project history could be lost. Developers also generally need network access to the server to see history or make commits, which is why working offline with SVN is painful.

**Distributed Version Control Systems (DVCS)**, like Git and Mercurial, solve this by giving every developer a full clone of the repository — including its complete history — on their own machine. There's no single point of failure, because every clone is effectively a full backup. Developers can commit, browse history, create branches, and review past changes entirely offline, only needing network access when they want to synchronize with others (via `push` and `pull`). This architecture is also what makes Git's branching model so fast: because everything lives locally, creating and switching branches doesn't require any server round-trip.

This is the key conceptual shift for beginners coming from tools like SVN: in Git, your local repository is not a partial 'checkout' — it is a complete, independent copy of the project's history.

Types of Version Control: Visual Walkthrough

Draw three side-by-side architecture diagrams. (1) Local VCS: one computer icon with a small database icon inside it, labeled 'All history on one machine'. (2) Centralized VCS: one central server icon in the middle, with three computer icons around it connected by arrows pointing only to the server, labeled 'Developers must connect to commit or view history'. (3) Distributed VCS: three computer icons, each containing a full copy of a database icon, connected to each other and to a remote server icon by bidirectional arrows, labeled 'Every clone has full history; sync via push/pull'.

Types of Version Control: Quick Reference Table

Feature	Local VCS	Centralized VCS (SVN)	Distributed VCS (Git)
History location	Single machine only	Central server only	Every clone (full copy)
Works offline	Yes	No (mostly)	Yes, almost entirely
Single point of failure	Yes (that one machine)	Yes (the central server)	No — every clone is a backup
Collaboration support	None	Good, but server-dependent	Excellent, flexible workflows
Branching speed	N/A	Slow, server round-trip	Instant, fully local
Example tools	RCS	SVN, Perforce, CVS	Git, Mercurial

Types of Version Control: Command Syntax and Examples

# Centralized VCS conceptual workflow (SVN-style):
svn checkout http://server/repo   # get a working copy from the server
svn commit -m "Fix bug"           # commit directly to the central server

# Distributed VCS conceptual workflow (Git-style):
git clone https://github.com/user/repo.git   # get a FULL copy, including history
git commit -m "Fix bug"                       # commit locally, no server needed
git push origin main                          # sync local history to the remote, only when ready

Breaking Down the Types of Version Control Example

Notice the structural difference: in SVN, `commit` sends your change directly to the central server — you cannot commit without network access, and there is no independent local history. In Git, `commit` only affects your local repository; the change becomes part of your own full history immediately, and `push` is a separate, later step used to share that history with a remote server. This separation is why Git developers can make dozens of commits on a flight with no internet connection.

How Types of Version Control Is Used on Real Engineering Teams

Many large legacy enterprises (banking, government) still run SVN repositories for older codebases, valuing its simpler centralized permission model for tightly controlled environments.
Google historically used a large monolithic centralized system internally (Piper) for its unique scale requirements, showing centralized architectures aren't obsolete for specialized needs.
GitHub, GitLab, and Bitbucket are all built around Git's distributed model — the 'remote' repository on these platforms is just one more clone among many, not a privileged single source of truth.
Facebook/Meta developed Mercurial-based tooling (and later Sapling) because Git's distributed model, while powerful, faced scaling challenges at their repository size — showing how architecture trade-offs still matter at extreme scale.

Types of Version Control Interview Questions and Answers

Q1. What is the difference between centralized and distributed version control?

In centralized version control, a single server holds the entire project history, and all commits must go directly to that server. In distributed version control, every developer clones a full copy of the repository, including its entire history, so they can commit, branch, and browse history locally without needing network access.

Q2. Why is a single point of failure a concern in centralized VCS?

If the central server in a CVCS goes down or its storage is corrupted, no one can commit changes, and if backups are inadequate, the entire project history could be permanently lost. Distributed VCS avoids this because every clone is effectively a complete backup of the full history.

Q3. Why can Git create branches almost instantly compared to older systems?

Because Git stores the entire repository history locally, creating a branch is just creating a new local pointer to a commit — no network round-trip to a server is required, unlike centralized systems where branching operations often involve server communication.

Types of Version Control Quiz: Test Your Understanding

1. Which type of version control system stores the full project history on every developer's machine?

Local VCS
Centralized VCS
Distributed VCS
None of the above

Answer: C. Distributed VCS

Explanation: Distributed VCS tools like Git give every clone a complete copy of the project's history, eliminating a single point of failure.

2. What is a major drawback of centralized version control systems like SVN?

They cannot track file changes
They require a central server to be available for most operations
They do not support multiple developers
They cannot store binary files

Answer: B. They require a central server to be available for most operations

Explanation: SVN clients depend on connecting to the central server for commits and often for viewing history, making the server a single point of failure and a bottleneck for offline work.

3. In Git, what happens when you run 'git clone'?

Only the latest file versions are downloaded
A complete copy of the repository including full history is created locally
A connection to the server is required for every future commit
The remote repository is deleted and moved locally

Answer: B. A complete copy of the repository including full history is created locally

Explanation: Cloning in Git copies the entire repository history to the local machine, which is the defining trait of a distributed version control system.

Types of Version Control: Common Mistakes Beginners Make

Assuming Git requires a central server the same way SVN does — Git's 'remote' is just a convention, not an architectural requirement.
Believing distributed VCS means there's no way to have an official shared repository — teams still designate one remote (like on GitHub) as the conventional source of truth.
Thinking centralized VCS is obsolete — it's still used in specific enterprise contexts, particularly for large binary assets or strict centralized access control.

Types of Version Control: Exam-Ready Quick Notes

Three types: Local, Centralized (CVCS), Distributed (DVCS) — memorize with one example tool each (RCS, SVN, Git).
Centralized VCS: single server, single point of failure, requires network for most operations.
Distributed VCS: full history cloned locally, no single point of failure, works offline.

Types of Version Control: Key Takeaways

Version control evolved from local, to centralized, to distributed architectures, each solving limitations of the previous generation.
Git's distributed nature means every clone is a full, independent backup of the project's entire history.
Understanding this evolution explains why Git supports offline work and instant branching, unlike older centralized tools.

Frequently Asked Questions About Types of Version Control

Q1. What are the three types of version control systems?

Local version control (history kept on one machine), centralized version control (a single server holds all history, e.g. SVN), and distributed version control (every developer has a full copy of history, e.g. Git).

Q2. Is SVN still used today?

Yes, though far less commonly than Git. Some enterprises with legacy systems or specific centralized-access requirements still use SVN, but the vast majority of new projects use Git.

Q3. Why is Git called a 'distributed' version control system?

Because when you clone a Git repository, you get a complete copy of the entire project history on your own machine, not just the current files. Every clone is a full, independent repository, not merely a checkout of the current state.

Q4. Can I work with Git without an internet connection?

Yes. Since your local clone has the full history, you can commit, browse history, create branches, and even merge entirely offline. You only need network access when you want to `push` your changes to or `pull` changes from a remote repository.

Q5. Does a distributed VCS mean there's no 'official' version of the project?

Not in practice. While technically every clone is equal, teams still agree on one remote repository (e.g., on GitHub) as the conventional source of truth that everyone pushes to and pulls from.

Summary

Version control systems fall into three architectural categories: local (single-machine history), centralized (a single server holding all history, as in SVN), and distributed (every developer holding a full clone of history, as in Git). Centralized systems introduced collaboration but created a single point of failure and a dependency on network access. Distributed systems like Git eliminated that dependency by giving every clone complete, independent history, enabling offline work, fast branching, and resilience against server failure — which is why Git has become the dominant standard in modern software development.