commit 30537df2e4412a23276683d339fbb794123b4362
parent 9f104f1063038c5a2ce952f47e87509f47df2d2c
Author: ling0x <ling0x@users.noreply.github.com>
Date: Mon, 8 Jun 2026 16:27:19 +0100
subversion
Diffstat:
1 file changed, 214 insertions(+), 0 deletions(-)
diff --git a/networking/subversion.md b/networking/subversion.md
@@ -0,0 +1,214 @@
+# Subversion
+
+## What Is Subversion?
+
+**Subversion** (commonly abbreviated **SVN**) is a centralized version control
+system (CVCS) created in 2000 by CollabNet and later maintained by the Apache
+Software Foundation. It was designed as a successor to **Concurrent Versions
+System (CVS)**, addressing CVS's weaknesses in atomic commits, directory
+versioning, and rename handling.
+
+Where Git treats every clone as a full repository with its own history, SVN
+keeps a single authoritative copy of the project on a central server. Developers
+check out a **working copy**—a snapshot of files on disk—and commit changes back
+to that central store. The server assigns each commit a monotonically increasing
+**revision number** (e.g., r42, r43) that applies to the entire repository, not
+just one branch.
+
+Subversion remains in use today, particularly in enterprises, government, and
+long-lived codebases that adopted it before Git became dominant. It is mature,
+predictable, and well understood—but it reflects a different design philosophy
+than modern distributed tools.
+
+## Core Concepts
+
+### Centralized repository
+
+SVN has one canonical repository (or a small set of mirrors). There is no local
+history beyond what the working copy caches; meaningful version metadata lives
+on the server. If the server is unreachable, you can edit files locally, but you
+cannot commit, diff against recent history, or browse logs without network
+access.
+
+### Revisions
+
+Every commit increments a global revision counter for the whole repository.
+Revision 154 might touch files on `trunk`, a branch, and `tags` simultaneously.
+This makes it easy to refer to "the state of the entire project at r154," but it
+also means revision numbers are not branch-specific identifiers.
+
+### Working copy
+
+A working copy is a directory tree on a developer's machine, plus hidden
+metadata in `.svn` directories (in SVN 1.7+, consolidated into a single `.svn`
+at the working-copy root). The working copy tracks which revision it is based on
+and which files have local modifications.
+
+### URL-based branching and tagging
+
+Branches and tags in SVN are not lightweight pointers—they are **directory
+copies** in the repository. A typical layout looks like:
+
+```
+/repos/myproject/
+ trunk/ # main line of development
+ branches/ # feature or release branches
+ tags/ # immutable release snapshots
+```
+
+Creating a branch means copying `trunk` to `branches/feature-x` on the server.
+Tags are the same operation, conventionally treated as read-only.
+
+### Atomic commits
+
+Unlike CVS, SVN commits are atomic: either all changes in a commit land
+together, or none do. Directory adds, deletes, and renames are versioned as
+first-class operations.
+
+## Basic Workflow
+
+A typical SVN session looks like this:
+
+1. **Checkout** — `svn checkout URL` creates a working copy from the server.
+2. **Update** — `svn update` pulls newer revisions from the server into the
+ working copy.
+3. **Edit** — modify files locally.
+4. **Diff / status** — `svn diff` and `svn status` show local changes (against
+ the last updated base revision).
+5. **Commit** — `svn commit -m "message"` sends changes to the server and
+ receives a new revision number.
+
+Conflicts arise when your working copy is out of date relative to the server.
+You must run `svn update`, resolve conflicts in affected files, then commit.
+
+## Subversion vs Git
+
+Git and Subversion solve the same problem—tracking changes to files over
+time—but their architectures diverge sharply. The table below summarizes the
+main differences.
+
+| Aspect | Subversion (SVN) | Git |
+| ----------------- | --------------------------------------- | ----------------------------------------- |
+| Model | Centralized (CVCS) | Distributed (DVCS) |
+| Canonical history | Lives on the server | Lives in every clone |
+| Revision identity | Global integer (`r1234`) | Content-addressed hash (`a3f9c2…`) |
+| Branching | Server-side directory copy | Lightweight local pointer |
+| Tagging | Directory copy (convention) | Named pointer to a commit |
+| Offline work | Edit files yes; commit/log/diff limited | Full history and commits offline |
+| Clone size | Working copy (often partial) | Full repository (unless shallow) |
+| Merge tracking | Improved over time; still URL-centric | Native, graph-based merge engine |
+| Partial checkouts | Supported (`svn checkout` subtrees) | Sparse checkout supported but less common |
+| Access control | Path-based ACLs on server | Per-repository; hosting platform policies |
+
+### Architecture: centralized vs distributed
+
+SVN assumes a hub-and-spoke model. The server is the source of truth; clients
+are thin working copies. This simplifies administration in some environments:
+backup one server, enforce permissions on paths, and audit a single log.
+
+Git assumes every developer has the full history (or a substantial subset).
+Commits happen locally first; **push** and **pull** synchronize with remotes.
+There can be many remotes, forks, and offline workflows. The trade-off is more
+complexity on the client and a steeper learning curve, in exchange for speed,
+flexibility, and resilience when the network is unavailable.
+
+### Branching and merging
+
+In SVN, branching is relatively heavyweight: a `svn copy` on the server creates
+a new directory tree. Merging in SVN historically meant tracking which revisions
+had already been merged between branches—a workable but often painful process,
+especially on long-lived branches.
+
+In Git, a branch is a small file pointing at a commit. Creating and switching
+branches is nearly instantaneous and local. Git's merge and rebase machinery
+operates on a directed acyclic graph of commits, which supports workflows like
+feature branches, interactive rebasing, and cherry-picking with far less
+friction than classic SVN workflows.
+
+### Revision numbers vs commit hashes
+
+SVN's global revision numbers are human-friendly and sortable across the whole
+repository. They are also ambiguous across branches: "r500" does not tell you
+which branch it belongs to without context.
+
+Git's SHA-1 (or SHA-256 in newer versions) hashes uniquely identify commits by
+their content and ancestry. They are globally unique within a repository but
+opaque to humans. Tools and hosting platforms add branch names and tags as
+readable aliases.
+
+### Performance and scale
+
+For very large monorepos, SVN's ability to check out only a subtree was
+historically an advantage. Git has caught up with partial clone, sparse
+checkout, and submodules, but shallow clones and monorepo tooling remain active
+areas of practice.
+
+For everyday developer operations—commit, branch, merge, bisect, blame—Git is
+typically faster because work is local and does not round-trip to a server for
+each action.
+
+### History rewriting
+
+SVN treats committed history on the server as largely append-only. While
+administrators can use tools like `svnadmin` or `svnsync` for maintenance,
+rewriting published history is uncommon and disruptive.
+
+Git encourages rewriting local history before sharing (`rebase`, `amend`,
+`squash`). Once commits are pushed to shared branches, rewriting requires
+coordination; hosting platforms and team policy govern what is acceptable.
+
+## Conceptual Mapping
+
+Developers moving between systems often map operations as follows:
+
+| Intent | Subversion | Git |
+| ----------------- | --------------------------- | ----------------------------------- |
+| Get a copy | `svn checkout URL` | `git clone URL` |
+| Download updates | `svn update` | `git pull` |
+| Upload changes | `svn commit` | `git commit` then `git push` |
+| See local changes | `svn status`, `svn diff` | `git status`, `git diff` |
+| Create a branch | `svn copy trunk branches/x` | `git branch x` or `git switch -c x` |
+| Switch branch | `svn switch URL` | `git switch branch` |
+| Merge | `svn merge -r X:Y URL` | `git merge branch` or `git rebase` |
+| View history | `svn log` | `git log` |
+| Revert a file | `svn revert file` | `git restore file` |
+
+The mapping is approximate. Git separates **commit** (local) from **push**
+(remote); SVN combines them in a single `commit` that immediately affects the
+central server.
+
+## Strengths and Limitations
+
+### Where Subversion still fits
+
+- Organizations with established SVN infrastructure, path-based permissions, and
+ trained operations staff.
+- Workflows that prefer a single canonical server and simple mental model.
+- Environments where developers always have reliable network access to the
+ repository.
+- Legacy projects where migration cost outweighs the benefit of moving to Git.
+
+### Where Git is usually preferred
+
+- Distributed teams, open-source collaboration, and fork-based workflows.
+- Heavy branching (feature branches, release trains, hotfix branches).
+- Offline or intermittent connectivity.
+- Ecosystem integration: GitHub, GitLab, and most modern CI/CD and code-review
+ tooling assume Git as the default.
+
+## Summary
+
+Subversion is a centralized version control system built around a single server,
+global revision numbers, and URL-oriented branches. It improved substantially on
+CVS and served as the dominant open-source VCS through much of the 2000s.
+
+Git is a distributed system where every clone carries history, branches are
+lightweight, and merges are graph-driven. It has become the de facto standard
+for new projects and most tooling ecosystems.
+
+Choosing between them today is less a question of raw capability—both can
+version code reliably—than of workflow, team habits, infrastructure, and whether
+a centralized or distributed model better matches how the organization works.
+For greenfield work, Git is the norm; for existing SVN estates, migration tools
+(`git svn`, `svn2git`) and phased transitions remain the practical path when a
+move is warranted.
