Centralized vs Distributed VCS: Architecture, Trade-offs, and When to Use Each

Compare centralized (SVN, CVS) vs distributed (Git, Mercurial) version control systems — their architectures, trade-offs, and when to use each approach.

published: March 31, 2026 reading time: 27 min read author: Geek Workbench updated: March 31, 2026

Introduction

Version control systems are not all created equal. The fundamental architectural decision that separates them is where the repository history lives: on a single central server, or on every developer’s machine. This choice cascades into everything from daily workflow to disaster recovery, from offline productivity to team collaboration patterns.

Centralized version control systems (CVCS) like SVN, CVS, and Perforce dominated the industry for decades. They operate on a client-server model where a single authoritative server holds the complete repository, and developers check out files to work on them. Distributed version control systems (DVCS) like Git, Mercurial, and Bazaar flipped this model by giving every developer a complete copy of the repository — history, branches, tags, and all.

Understanding the architectural differences between these two paradigms is essential for choosing the right tool for your team, your project, and your constraints. This guide breaks down the technical architectures, trade-offs, and real-world scenarios where each approach shines.

When to Use / When Not to Use

Use Centralized VCS when:

Your organization requires strict access control at the file or directory level
You manage large binary assets that should not be replicated to every developer
Your team works in a regulated environment with centralized audit and compliance requirements
Repository size is massive (hundreds of GB) and cloning to every machine is impractical
You need fine-grained permissions where different teams access different parts of the repository

Use Distributed VCS when:

Your team works across multiple time zones or needs offline capabilities
You want fast local operations (commits, diffs, logs, branches) without network latency
Branching and merging are core to your workflow (feature branches, pull requests)
You need redundancy — any clone can serve as a backup of the full history
Your project is open source or has external contributors who should not need server access

Neither is ideal when:

Managing large binary assets without Git LFS (consider Perforce or dedicated asset management)
Tracking datasets or machine learning models that exceed VCS design limits
You need real-time collaborative editing (use Google Docs-style tools instead)

Core Concepts

The distinction between centralized and distributed VCS comes down to three architectural principles: data ownership, network dependency, and branching model.

Data ownership determines who holds the complete history. In a CVCS, only the server has the full repository. In a DVCS, every clone is a complete repository.

Network dependency determines what operations require connectivity. CVCS requires a network connection for commits, history viewing, and most operations. DVCS performs all operations locally — the network is only needed for sharing changes.

Branching model determines how parallel development works. CVCS branching typically involves copying directories on the server, which can be slow and expensive. DVCS branching is a lightweight metadata operation that creates a new pointer in milliseconds.

Centralized VCS (CVCS) Architecture

graph TD
    S1[Central Server<br/>Complete Repository]
    C1[Client A<br/>Working Copy Only]
    C2[Client B<br/>Working Copy Only]
    C3[Client C<br/>Working Copy Only]
    C1 <-->|Network Required| S1
    C2 <-->|Network Required| S1
    C3 <-->|Network Required| S1

Distributed VCS (DVCS) Architecture

graph TD
    S2[Server<br/>Complete Repository]
    D1[Client A<br/>Complete Repository]
    D2[Client B<br/>Complete Repository]
    D3[Client C<br/>Complete Repository]
    D1 <-->|Optional Sync| S2
    D2 <-->|Optional Sync| S2
    D3 <-->|Optional Sync| S2
    D1 <-->|Peer to Peer| D2
    D2 <-->|Peer to Peer| D3

The CVCS diagram shows clients holding only working copies. The DVCS diagram shows each client holding a complete repository and syncing peer-to-peer.

Architecture or Flow Diagram

Centralized VCS Commit Flow

sequenceDiagram
    participant Dev as Developer
    participant S as Central Server
    participant R as Repository DB

    Dev->>S: Checkout
    S->>R: Lock files
    R-->>S: Files
    S-->>Dev: Working copy
    Note over Dev: Make changes
    Dev->>S: Commit
    S->>R: Store revision
    R-->>S: Confirmed
    S-->>Dev: Updated

Distributed VCS Commit Flow

sequenceDiagram
    participant Dev as Developer
    participant Local as Local Repo
    participant Remote as Remote

    Note over Dev,Local: Clone (one-time)
    Remote->>Local: Full history
    Note over Dev: Make changes
    Dev->>Local: Commit (offline)
    Local-->>Dev: Confirmed
    Note over Dev: Work offline
    Dev->>Local: Create branch
    Dev->>Local: Commit
    Note over Dev: Ready to share
    Dev->>Remote: Push
    Remote-->>Dev: Accepted

Step-by-Step Guide / Deep Dive

Centralized VCS: How SVN Works

Subversion (SVN) is the most widely used centralized VCS. Its architecture follows a straightforward client-server model:

Repository storage: A single server holds the complete versioned file system using either a Berkeley DB or FSFS (file system-based) backend.
Checkout: Developers check out a working copy, which contains only the files they need — not the full history.
Lock-modify-unlock or copy-modify-merge: SVN supports both models. In lock mode, a file is exclusively locked to prevent concurrent edits. In copy-modify-merge mode, multiple developers can edit the same file and conflicts are resolved at commit time.
Commit: Changes are sent to the server, which assigns a global revision number. Every commit increments this number across the entire repository.
Update: Developers pull the latest changes from the server to sync their working copy.

SVN’s global revision numbers are a notable feature: revision 1000 means the entire repository is at state 1000. This makes it easy to reference a specific point in time across all files.

Distributed VCS: How Git Works

Git’s architecture is fundamentally different:

Repository storage: Every clone contains the complete object database — all commits, trees, blobs, and tags. The .git directory is the repository.
Clone: When you clone a repository, you receive the full history, not just the latest files. This is a one-time cost that enables all subsequent local operations.
Snapshot model: Git stores snapshots, not deltas. Each commit captures the complete state of all tracked files. Unchanged files are referenced via pointers to previous snapshots, making this efficient.
Commit: Commits are local operations. They are instantaneous and require no network connection. Each commit has a unique SHA-1 hash derived from its content.
Push/Pull: Sharing changes requires explicit network operations. Push sends your commits to a remote. Pull fetches and merges remote commits into your branch.

Git’s content-addressable storage is its secret weapon. Every object is identified by a cryptographic hash of its content, which means:

Data integrity is guaranteed — corrupted content produces a different hash
Deduplication is automatic — identical content is stored only once
History is immutable — changing any commit changes all subsequent hashes

Operational Comparison

Operation	SVN (Centralized)	Git (Distributed)
Commit	Requires server connection	Instant, local only
View history	Requires server connection	Instant, local only
Create branch	Server-side copy (slow)	Local pointer (instant)
Diff between versions	Requires server connection	Instant, local only
Blame/annotate	Requires server connection	Instant, local only
Offline work	Limited to uncommitted changes	Full functionality
Clone/checkout	Fast (files only)	Slower (full history)
Repository size on client	Small (working files only)	Larger (full history)
Disaster recovery	Server backup required	Any clone restores everything
Access control	Fine-grained (per-path)	Repository-level only

Production Failure Scenarios

Scenario	CVCS Impact	DVCS Impact	Mitigation
Server hardware failure	Complete outage — no commits, no history access	No impact on local work — push fails but commits continue	CVCS: maintain hot standby. DVCS: any clone can become the new remote
Network outage	All version control operations blocked	Zero impact — all operations are local	DVCS eliminates this failure mode entirely
Corrupted repository on server	Data loss if backups are stale	Any developer’s clone contains the full history	DVCS provides natural redundancy across all team members
Accidental deletion of branch	Recoverable from server backups	Recoverable from any clone that has the branch	Both systems support recovery, but DVCS has more recovery points
Disk corruption on developer machine	Working copy lost — server history intact	Working copy and local commits lost — remote history intact	Both require pushing to remote for safety
Malicious actor with server access	Can alter or delete entire history	Can alter remote history, but local clones preserve truth	DVCS makes history tampering detectable via hash chains
Network partition (split-brain)	Complete isolation — all version control blocked	Local work continues — merge conflicts possible on reconnection	DVCS handles partitions gracefully; resolve conflicts when network restores

Trade-off Analysis

Factor	Centralized VCS	Distributed VCS
Architecture	Client-server, single authority	Peer-to-peer, every node is equal
Network dependency	Required for most operations	Only needed for sharing changes
Branching	Heavyweight, server-side operation	Lightweight, local metadata operation
Merge capability	Basic, often painful	Advanced, with sophisticated algorithms
Performance	Network-bound for most operations	Fast local operations, slower initial clone
Storage per user	Minimal (working files only)	Full repository history
Access control	Fine-grained per-path permissions	Repository-level only
Binary file support	Better (files not replicated)	Requires Git LFS for large binaries
Learning curve	Simpler mental model	Steeper — requires understanding of distributed state
Audit trail	Centralized, easy to monitor	Distributed, requires aggregation
Offline productivity	Minimal	Complete
Adoption	Declining (legacy systems)	Industry standard (Git dominates)

Implementation Snippets

SVN: Basic Workflow

# Checkout a working copy from the central server
svn checkout https://svn.example.com/repo/project project
cd project

# Make changes to files
echo "New feature" >> feature.py

# Check what changed
svn status

# View differences
svn diff

# Commit changes to the central server
svn commit -m "Add new feature"

# Update working copy with latest server changes
svn update

# Create a branch (server-side copy)
svn copy https://svn.example.com/repo/project/trunk \
         https://svn.example.com/repo/project/branches/feature \
         -m "Create feature branch"

# Switch to the branch
svn switch https://svn.example.com/repo/project/branches/feature

# Merge branch back to trunk
svn switch https://svn.example.com/repo/project/trunk
svn merge https://svn.example.com/repo/project/branches/feature
svn commit -m "Merge feature branch into trunk"

Git: Basic Workflow

# Clone the full repository (one-time)
git clone https://github.com/example/project.git
cd project

# Make changes to files
echo "New feature" >> feature.py

# Check what changed
git status

# View differences
git diff

# Stage and commit locally (no network needed)
git add feature.py
git commit -m "Add new feature"

# Push changes to the remote server
git push origin main

# Pull latest changes from the remote
git pull origin main

# Create a branch (instant, local)
git checkout -b feature/new-endpoint

# Merge branch back to main
git checkout main
git merge --no-ff feature/new-endpoint -m "Merge feature branch"

# Resolve conflicts if any, then complete the merge
# git add <resolved-files>
# git commit (if merge was not auto-completed)

Git: Working Offline

# All of these work without any network connection:

# View full history
git log --oneline --graph --all

# Create and switch branches
git branch feature/experiment
git checkout feature/experiment

# Commit changes
git add .
git commit -m "Experimental changes"

# Compare any two commits
git diff HEAD~3 HEAD

# See who changed each line
git blame app.py

# When network returns, push all local commits
git push origin feature/experiment

Observability Checklist

Logs: Enable server-side audit logging for CVCS to track all checkout, commit, and access events
Metrics: Track repository clone times (DVCS), commit latency (CVCS), and branch creation frequency
Traces: Use git log --graph to visualize branch topology and identify merge bottlenecks
Alerts: Monitor server disk space for CVCS — a full server blocks all development
Audit: For CVCS, review access logs regularly. For DVCS, use signed commits to verify authorship
Health: Run git fsck periodically on DVCS clones to detect object corruption
Backup: CVCS requires automated server backups. DVCS benefits from multiple remote mirrors

Security & Compliance Considerations

Centralized VCS security advantages:

Fine-grained access control allows restricting specific directories or files to authorized teams
Centralized audit logs provide a single source of truth for compliance reporting
No risk of repository history leaking through developer laptops — only working copies exist on clients

Distributed VCS security advantages:

Cryptographic hash chains make history tampering detectable — any modification changes all subsequent hashes
Signed commits (GPG/SSH) provide cryptographic proof of authorship
No single point of failure — compromising the server does not destroy the truth stored in clones

Audit trail comparison:

Centralized VCS maintains a single, authoritative audit log on the server. Every checkout, commit, and file access passes through one point, making it straightforward to generate compliance reports, track who accessed what, and detect anomalous behavior. Regulatory frameworks like SOX and HIPAA favor this model because the audit surface is bounded and centralized.

Distributed VCS distributes the audit trail across every developer’s machine. Each commit is locally authored and only becomes visible when pushed. This means:

Audit data must be aggregated from the remote server’s push logs, not the commit logs themselves
Commits can be authored offline and pushed later, creating a gap between authorship time and visibility time
Signed commits (GPG/SSH) provide stronger cryptographic proof of authorship than CVCS username-based attribution
The immutable hash chain makes it impossible to alter history without detection, providing a stronger integrity guarantee than centralized logs

Shared concerns:

Both systems can accidentally expose secrets committed to history
Both require careful access management to prevent unauthorized changes
Both benefit from server-side hooks that enforce policies (commit message format, file size limits, secret scanning)

For Git-specific configuration, see Git Config and Global Settings.

Common Pitfalls / Anti-Patterns

Treating Git like SVN: Committing directly to main, avoiding branches, and pushing every single change defeats Git’s distributed advantages
Ignoring clone size in DVCS: A repository with years of large binary history can take hours to clone. Use shallow clones (git clone --depth 1) or Git LFS
Over-relying on centralized access control in Git: Git’s permission model is repository-level. Use platform-level controls (GitHub orgs, GitLab groups) for fine-grained access
Not pushing frequently in DVCS: Local commits are not backed up until pushed. Push feature branches regularly to avoid losing work
Using CVCS for open source: Requiring server access for contributors creates an unnecessary barrier. DVCS allows anyone to fork and contribute
Assuming DVCS eliminates the need for a central server: While technically true, a designated remote (GitHub, GitLab) provides essential coordination, CI/CD integration, and code review workflows

Quick Recap Checklist

Architecture Diagram: Client-Server vs Peer-to-Peer Topology

The following diagrams compare the network topology of centralized (SVN) versus distributed (Git) version control systems:

Centralized VCS — Client-Server Topology

graph TD
    S1[("SVN Server<br/>Single Source of Truth")]
    C1[Developer A<br/>Working Copy Only]
    C2[Developer B<br/>Working Copy Only]
    C3[Developer C<br/>Working Copy Only]
    C1 <-->|HTTP/SSH Required| S1
    C2 <-->|HTTP/SSH Required| S1
    C3 <-->|HTTP/SSH Required| S1

Distributed VCS — Peer-to-Peer Topology

graph TD
    S2[(Git Remote<br/>Conventional Hub)]
    D1[Developer A<br/>Full Repository]
    D2[Developer B<br/>Full Repository]
    D3[Developer C<br/>Full Repository]
    D1 <-->|Optional Push/Pull| S2
    D2 <-->|Optional Push/Pull| S2
    D3 <-->|Optional Push/Pull| S2
    D1 <-->|Direct Peer Sync| D2
    D2 <-->|Direct Peer Sync| D3
    D1 <-->|Direct Peer Sync| D3

Key architectural differences:

Centralized: All clients depend on a single server. If the server is unreachable, no version control operations are possible. The server is the only node with complete history.
Distributed: Every node is a complete repository. The “server” is merely a conventional meeting point — any clone can serve as a backup or collaboration hub. Direct peer-to-peer synchronization is possible without any central infrastructure.

Interview Questions

1. Why is branching in Git faster than branching in SVN?

In SVN, creating a branch performs a server-side copy of the entire directory tree, which involves reading and writing all files on the server. In Git, a branch is simply a lightweight pointer to a specific commit — creating one only writes a 41-byte file containing the commit hash. No files are copied, making branch creation instantaneous regardless of repository size.

2. What does it mean that Git uses content-addressable storage?

Git stores every object (blobs, trees, commits, tags) in its object database identified by a SHA-1 hash of the object's content. This means the address of an object is derived from what it contains, not where it is stored. If two files have identical content, Git stores only one copy. If any bit of content changes, the hash changes, making corruption detectable and history immutable.

3. Can a distributed VCS work without any central server?

Yes. In a DVCS, every clone is a complete repository. Developers can exchange patches directly via email, USB drives, or peer-to-peer sync without any central server. However, in practice, teams designate a conventionally central remote (like GitHub or GitLab) for coordination, code review, and CI/CD — not because the architecture requires it, but because it simplifies workflow.

4. What are the compliance implications of choosing CVCS over DVCS?

CVCS provides a single point of audit — all commits pass through one server, making it easier to log, monitor, and report on all changes for compliance frameworks like SOX or HIPAA. DVCS distributes history across all developer machines, which means audit data must be aggregated from multiple sources. However, DVCS signed commits provide stronger cryptographic proof of authorship than CVCS username-based attribution.

5. Explain the difference between a "working copy" in SVN and a "clone" in Git.

Key differences:

SVN working copy: Contains only the files you checked out, plus hidden `.svn` directories storing metadata about the repository URL and revision. You do not have history — just your current files.
Git clone: Contains the complete repository — all history, all branches, all tags. The `.git` directory holds the full object database. A clone is a self-contained backup of the entire project.

Result: SVN requires server contact for history; Git does not. SVN working copies are lightweight but dependent; Git clones are heavier but fully autonomous.

6. How does SVN's global revision number differ from Git's commit hashes, and what are the practical implications?

SVN uses sequential global revision numbers (r1, r2, r3...) that increment across the entire repository. Revision 1000 means the entire repo is at that state — all files across all directories.

Git uses SHA-1 hashes (e.g., `a1b2c3d4...`) derived from commit content. Each commit hash is unique to that specific snapshot and cannot be predicted or sequential.

Practical implications:

SVN revision numbers are human-readable and concise; Git hashes are opaque but can be abbreviated
SVN revisions guarantee a single linear sequence; Git allows parallel histories via branching
Git hash chains make history tamper-evident; SVN relies on server-side controls
Git allows cross-repository cherry-picking via hash references; SVN requires server access

7. What is the lock-modify-unlock model in version control, and when is it appropriate?

Lock-modify-unlock is a concurrency model where a file must be explicitly locked before editing. Only one developer can edit a locked file at a time.

When to use:

Merging binary files that cannot be diffed (art assets, compiled binaries)
Regulated environments where audit trails require exclusive file ownership
Files requiring sequential approval workflows (legal documents, contracts)

Drawbacks: Blocks productive parallel work, causes merge debt when locks are held long, and requires server connectivity to check/release locks. Most text-based code benefits from merge models instead.

8. Why does Git's snapshot model actually save storage efficiently despite storing full copies?

Git uses delta compression behind the scenes. When you make a commit, Git stores:

New files as full objects (blobs)
Changed files as compressed deltas against the previous version
Unchanged files as pointers to existing objects

A "full snapshot" in Git means every commit captures the tree structure — but objects are stored once and referenced by multiple commits. Identical content across branches or time is stored only once via content-addressable deduplication. The `.git/objects` directory grows incrementally, not by duplicating entire trees.

9. What happens to your work if your laptop dies during active development with DVCS versus CVCS?

With DVCS (Git):

Uncommitted work in your working directory is lost — the filesystem holds it, not Git
Committed work is safe — it lives in your local `.git` directory
If you had pushed recently, remote has your commits. If not, work exists only locally
Solution: frequent `git push` to remote; `git stash` for work-in-progress

With CVCS (SVN):

Uncommitted work is lost — only the server holds committed history
Committed work is safe on the server
Working copy loss is less catastrophic for committed changes since server has them
Solution: frequent `svn commit` to server; don't keep local changes uncommitted

10. Describe the workflow for migrating a large SVN repository to Git without losing history.

Migration steps:

Step 1: Install `git svn` tool — `git clone --stdlayout https://svn.example.com/repo`
Step 2: Clone with auth: `git svn init --username=dev https://svn.example.com/repo && git svn fetch`
Step 3: Convert tags: `git tag -a $(git rev-parse HEAD~1) -m "converted from SVN"` or use `git2svn` for more complete conversion
Step 4: Clean up: remove `git-svn` metadata, verify author mapping
Step 5: Push to new Git remote: `git remote add origin https://github.com/org/repo.git && git push --all && git push --tags`

Considerations: Large repos take hours to clone. Author mapping must be pre-configured. SVN externals need conversion. Branch structure may require manual restoration.

11. What are the security implications of storing a complete repository copy on every developer's machine?

Security implications:

Data leakage risk: Entire history — including deleted code, old secrets, and sensitive branches — exists on every client. If a laptop is stolen, full history is exposed.
Secret sprawl: Secrets accidentally committed to history persist in every clone. `git filter-branch` or `BFG Repo-Cleaner` can remove them, but they existed in the wild.
Access control complexity: Git cannot revoke access from clones — once someone clones, they have the full history. Access control must happen at the remote platform level (GitHub org, GitLab group).
Positive side: No single point of failure — server compromise does not destroy history stored on every developer's machine.

12. How would you design a branching strategy for a 50-person team using Git?

A practical approach for a team of 50:

Main branch: `main` — always deployable, requires PR + review to merge
Integration branches: `staging` or `release/X.Y.Z` for deployment previews
Feature branches: `feature/ticket-description` — short-lived, one ticket per branch
Team branches: For larger features spanning multiple sprints, a temporary team branch that eventually merges into main and gets deleted

Key rules: branch from `main`, keep branches short-lived (max 3-5 days), delete after merge, require CI passing before merge, enforce code review. Use `git worktree` for developers working on multiple features simultaneously.

13. Compare the merge strategies in Git versus SVN. Why does Git handle complex merges better?

SVN merges: Uses a simplified algorithm — tracks merge history but often fails to detect scenarios like "changes on both branches to the same line." Conflicts must be manually resolved. Merging the same branch twice requires `--reintegrate` flag.

Git merges: Uses the recursive three-way merge algorithm, considering the common ancestor, both branch tips, and the merge base. Handles complex scenarios like criss-cross merges. Uses `octopus` strategy for merging multiple branches.

Git's staging area (`git add` to mark resolved files) versus SVN's need-to-edit-conflict-markers-in-files makes resolution systematic. Git's philosophy — "commits are local, merges can be retried" — enables experimentation.

14. What is `git reflog` and how does it serve as a safety net in Git?

`git reflog` tracks every reference update in your local repository — branch checkouts, commits, rebases, merges, resets. It maintains a chronological log of where your HEAD pointed.

Safety net uses:

Recover from accidental `git reset --hard` — find the commit hash before reset and reset back
Find commits after a failed interactive rebase
Identify where a branch was before a mistaken force push
Understand when a detached HEAD state occurred

Limitation: `reflog` is local only — not pushed to remote, not replicated in clones. It does not help recover from a dead local machine. It is not a replacement for pushing to remote.

15. When would you recommend CVS over Git in 2026?

Honest answer: almost never. CVS is deprecated, unmaintained, and lacks modern features. However, specific legacy constraints might justify it:

Extremely old codebases with decades of CVS history that cannot be migrated without business-breaking history rewriting
Organizations with existing CVS infrastructure and no budget/time to migrate
Regulatory environments where audited tool choices are locked in by compliance documents

Even in these cases, Git with `git cvsimport` for migration is preferable. CVS has no advantages in feature set, community support, or tooling. SVN would be the minimum upgrade from CVS.

16. Explain the concept of "distributed workflow" and why it enables better code review than centralized models.

Distributed workflows (forking model) work like this: every developer clones the main repo into their own fork, works on changes there, then opens a pull request to merge back. No one pushes directly to the central repo.

Why this enables better code review:

Reviewers can see the diff before merge — no code enters main without review
Forking provides natural isolation — experimental work does not pollute main
Maintainers control which forks have merge rights, enabling hierarchical review
Continuous integration can run on the PR, not on main, catching failures before integration
Offline code review is possible — reviewers clone and comment without real-time collaboration

This model is why GitHub became the dominant platform — `git clone` + PR creates a natural asynchronous code review workflow that SVN's centralized model cannot match.

17. What is shallow clone (`git clone --depth N`) and when should you avoid it?

Shallow clone downloads only the most recent N commits, discarding full history. This reduces clone size and time for large repositories.

When to avoid:

Long-running projects: Shallow clones age poorly — as new commits accumulate, the shallow clone diverges, and `git fetch --unshallow` retrieves the full history anyway
Branching and bisect: `git bisect` requires full history to find regressions; shallow clones cannot reliably bisect
Code review and archaeology: Understanding why code was written requires history; shallow clones destroy this capability
CI/CD with Docker layers: Each clone pulls same shallow history, negating cache benefits

Better alternative: clone once, then use `git fetch --depth=1` to incrementally update without full history.

18. How does Git LFS solve the binary file problem in distributed version control?

Git LFS (Large File Storage) stores large binary files outside the Git repository. Only a text pointer (.git/lfs/objects/) is committed to history instead of the actual binary.

How it works:

When you commit a file tracked by LFS, the actual bytes are uploaded to a LFS server (GitHub, GitLab, self-hosted)
Your Git commit contains a pointer (OID) to the LFS object, not the binary itself
When others clone, they download pointers first; actual binaries are fetched on checkout

Trade-offs: LFS introduces external dependency — if the LFS server is down, you cannot push. Storage costs increase. Some workflows (offline development, air-gapped environments) become complicated. Git-annex and git-multipack are alternatives for decentralized binary management.

19. Describe a scenario where CVCS access control provides value that DVCS cannot replicate.

Scenario: Regulated financial institution with multi-team repository

Consider a bank where the trading system repo is divided into sections: market-data (read-only for trading team), risk-calculations (read-write for risk team), compliance-logging (audit-only access for compliance team). SVN's per-directory permissions natively enforce this — developers cannot even checkout directories they lack access to.

With Git, access control is repo-level. Trading team developers would have read-write access to the entire repo, even directories they should not access. Fork-based isolation helps but doesn't solve the problem elegantly — the trading fork would still contain references to restricted directories in history.

GitHub's repository rules (path-based restrictions) attempt to solve this but are not native to Git — they require platform-specific configuration and do not apply to local clones. For true per-directory access control, SVN's model has genuine advantages in regulated environments.

20. What metrics would you track to evaluate whether your team is using version control effectively?

Key metrics:

Commit frequency: Daily commits per developer indicate active work. Zero-commits days may indicate work hoarding or blockers.
Branch turnover rate: How quickly feature branches are created, merged, and deleted. High turnover indicates active development; stale branches indicate abandoned work.
Merge conflict rate: Frequency of conflicts on merge. High conflict rate signals branches living too long.
Push latency: Time between local commit and remote push. Long gaps indicate developers hoarding work locally.
History rewrite ratio: How often `git rebase` or `git reset` appear in reflog. Frequent history rewrites can indicate workflow issues.
Code review coverage: Percentage of commits that are PRs with review. 100% review coverage is a DVCS best practice.
Offensive language detection: In CVCS, server-side hooks can scan commits. In DVCS, client-side hooks or CI pipelines must enforce this before push.

Conclusion

Understanding both paradigms makes you a more versatile developer. You will appreciate Git’s design decisions rather than fighting them, and you will know which model’s strengths to lean on when evaluating trade-offs in your own projects.