i

Description

Vue plongeante sur un grand faisceau de voies et un atelier ferroviaire sous un ciel nuageux.

Source

Telecineguy · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Overview of Version Control Systems

Understand what version control (VCS) is and why it is the backbone of any project, including data/BI.

In Brief

• Understand what version control (VCS) is and why it is the backbone of any project, including data/BI.
• Distinguish centralized and distributed, pessimistic locking and optimistic merging, snapshots and deltas.
• Place CVS, SVN, Perforce, Mercurial, Plastic SCM, Fossil, TFVC, and Git in history and in their current use cases.
• Know what a versioned object, a hash, a commit, and a branch are.
• Have a /5 rated decision framework to choose the tool based on context.

On this page

1. Why a VCS
2. Minimal vocabulary
3. Centralized vs. distributed
4. Locking vs. merging
5. Snapshots vs. deltas
6. Objects and hashing
7. Tool history
8. Systems One by One
9. Rating Grid
10. Choosing
11. Cross-Cutting Pitfalls
12. See Also

Level: 🟢→🟡

Why a VCS#

🟢 Beginner level

Without VCS, versioning is done by copying folders (rapport_v2_final_VRAI.pbix). That fails in four ways: you don't know who changed what, you can't compare two states, people overwrite each other, and you can't reconstruct what was delivered to a client two years ago. A VCS provides:

1. History: every change is recorded with author, date, and message.
2. Rollback: return to any past state.
3. Parallel work: branches, merges.
4. Traceability: link a change to a ticket, a build, a delivery (see CI/CD: Continuous Integration and Continuous Delivery).
5. Audit: prove what was changed, by whom, before a given production deployment.

Minimal vocabulary#

The terms are covered in the Glossary.

Centralized vs. distributed#

🟢 Beginner level

Centralized: a single server holds the history. The client machine has only the requested version plus metadata. You need the server for most operations (history, commit, branch). Examples: CVS, SVN, Perforce, TFVC.

Distributed: each machine holds the entire repository, including history. Commit is local; then you sync with one or more remote repositories (push, pull). Examples: Git, Mercurial, Fossil, Plastic SCM (distributed mode).

Centralized                         Distributed
   [Server]                          [Repo A] <--> [Reference repo] <--> [Repo B]
   /   |   \                          (full history everywhere)
 Workstation Workstation Workstation                 
 (copy) (copy) (copy)

Locking vs. merging#

🟢 Beginner level

Two people modify the same file. Two philosophies:

• Pessimistic locking (lock-modify-unlock): you “reserve” the file; nobody else can edit it. Advantage: no conflict. Drawback: blocking, forgotten unlocks, impossible parallel work. Suitable for non-mergeable binary files (.pbix, .docx, images).
• Optimistic merging (copy-modify-merge): each person edits their own copy; on save, the tool merges and reports conflicts. Suitable for text files.

TFVC supports both: locking checkout (/lock:checkout) or non-locking (/lock:none), depending on workspace and project configuration. Git only supports merging; for binaries, Git LFS adds locking (git lfs lock) by repository convention. Perforce and SVN handle both.

Snapshots vs. deltas#

🟡 Practical level

Two ways to store history:

• Deltas (CVS, SVN, TFVC, Perforce, many legacy systems): for each file, store the base version then successive differences. Compact for small changes, but reconstructing an old version requires replaying deltas; the notion of “repository version” is a global number (revision, changeset).
• Snapshots (Git): each commit points to a complete snapshot of the tree. Unchanged files are simply reused by reference (same object). Git then compresses into packfiles, computing deltas after the fact between nearby objects: the logical model is snapshot, physical storage is mixed.

The logical difference matters: in a snapshot model, comparing any two versions is direct; renaming is not recorded, it is inferred by content similarity (Git), whereas TFVC explicitly records the “rename” operation (hence its ability to track the history of a moved file, at the cost of rigidity).

Objects and hashing#

🟡 Practical level

A modern system handles few concepts: a content object (the file), a tree (the list of names and objects), a commit (the tree + parents + author + message). In Git, each object is identified by a hash of its content (historically SHA-1, optionally SHA-256). Consequences:

• Integrity: changing an object changes its identifier; any corruption is detectable.
• Deduplication: two identical files occupy only one object.
• Practically tamper-evident history: a commit's identifier depends on its parents; rewriting the past changes all subsequent identifiers.
• Non-sequential identifiers: no “revision 4217,” but b9a971b. TFVC sequential numbers (changeset 45815) are more readable for humans and reports.

Tool history#

🟡 Practical level

Reliable landmark: Git was created in 2005 by Linus Torvalds for the Linux kernel; TFVC originated with Team Foundation Server 2005, and Visual SourceSafe was its de facto predecessor at Microsoft. Microsoft later added Git to TFS (2013) and made Git the default choice.

Systems One by One#

🟡 Practical level

CVS — Ancestor. No atomic commits, no renaming, expensive branches. Migrate if encountered.

Subversion (SVN) — Centralized, atomic commits, global revisions, branches and tags via cheap copy (/trunk, /branches, /tags by convention). Path-based permissions. Still common in legacy environments. Good with large binaries, locking available.

Perforce Helix Core (renamed Perforce P4 in 2025) — Centralized, very high performance on huge repositories and binaries (video games, hardware). Workspaces, changelists, shelving, file locking, fine-grained path permissions. A Git mode (Helix4Git) exists for coexistence. Commercial license.

Mercurial — Distributed, more consistent interface than Git, but ecosystem greatly reduced (Bitbucket dropped Mercurial in 2020). Still used in some large organizations. Existing maintenance, declining adoption.

Plastic SCM (Unity Version Control) — Hybrid distributed/centralized, good with binaries and game art, polished GUI, task branches. Acquired by Unity, renamed Unity Version Control. Niche ecosystem.

Fossil — Distributed, single executable, includes ticketing, wiki, and forum in the repository (SQLite). Ideal for small standalone projects; little enterprise adoption.

TFVC (Team Foundation Version Control) — Centralized, integrated with Azure DevOps Server / Services and Visual Studio. Numbered changesets, branches, shelvesets, check-in policies, native linking to work items, fine-grained path permissions. See 03.

Git — Distributed, object model based on snapshots, trivial branching, unmatched ecosystem. See 02.

Rating Grid#

🟡 Practical level

Expert ratings out of /5, context: team of 5 to 30 developers, project mixing code, SQL, and BI, large repository of a few GB, enterprise-hosted repository. These are assessments, not measurements (see RATING).

Key justifications: Git loses on learning (index, rebase, detached HEAD) but wins on everything else in the ecosystem; TFVC is simple and precise for permissions, but its future is constrained (see 03); Perforce dominates massive repositories; Mercurial has a good model but few platforms.

Choosing#

🔴 Expert level

Simplified decision tree:

Decision criteria to define before choosing the tool:

1. File size and type: mostly text (SQL, TMDL, JSON) → Git is excellent. Mostly binary files of hundreds of MB → Perforce/Plastic, or Git + LFS with discipline.
2. Permission model: need to split folder access for contractors? Git requires separate repositories; TFVC does this natively.
3. Skills: who trains juniors? The job market and documentation overwhelmingly favor Git.
4. Delivery chain: pipelines, pull-request code reviews, branch policies: Git is the lowest-cost path.
5. Support horizon: a VCS at the end of investment carries technical debt risk.
6. Migration cost: history to preserve? work item links? labels? permissions?

Cross-Cutting Pitfalls#

🔴 Expert level

• ⚠️ Pitfall — Confusing backup and versioning: a VCS is not a backup without replication; back up the server (TFVC collection database, remote repositories).
• ⚠️ Pitfall — Kitchen-sink commits: a commit mixing a fix, reformatting, and a new feature makes auditing and revert unusable. One commit = one topic.
• ⚠️ Pitfall — Data in the repository: large reference tables, exports, .bak backups, secrets. See 06.
• ⚠️ Pitfall — Long-lived branches: the longer a branch lives, the more merging costs (cost grows faster than time). See 05.
• ⚠️ Pitfall — Non-standardized encoding and line endings: “whole-file” diffs and corrupted accents. See 06.

See Also#

• Git In Depth · TFVC in Depth · Git vs TFVC: compare, migrate, coexist
• Azure DevOps / TFS In Depth
• Matrix: version control and branches
• CI/CD · Glossary

✻ Written by Claude Sonnet 5.5