subversion.txt (10446B)
1 # Subversion 2 3 ## What Is Subversion? 4 5 **Subversion** (commonly abbreviated **SVN**) is a centralized version control 6 system (CVCS) created in 2000 by CollabNet and later maintained by the Apache 7 Software Foundation. It was designed as a successor to **Concurrent Versions 8 System (CVS)**, addressing CVS's weaknesses in atomic commits, directory 9 versioning, and rename handling. 10 11 Where Git treats every clone as a full repository with its own history, SVN 12 keeps a single authoritative copy of the project on a central server. Developers 13 check out a **working copy**—a snapshot of files on disk—and commit changes back 14 to that central store. The server assigns each commit a monotonically increasing 15 **revision number** (e.g., r42, r43) that applies to the entire repository, not 16 just one branch. 17 18 Subversion remains in use today, particularly in enterprises, government, and 19 long-lived codebases that adopted it before Git became dominant. It is mature, 20 predictable, and well understood—but it reflects a different design philosophy 21 than modern distributed tools. 22 23 ## Core Concepts 24 25 ### Centralized repository 26 27 SVN has one canonical repository (or a small set of mirrors). There is no local 28 history beyond what the working copy caches; meaningful version metadata lives 29 on the server. If the server is unreachable, you can edit files locally, but you 30 cannot commit, diff against recent history, or browse logs without network 31 access. 32 33 ### Revisions 34 35 Every commit increments a global revision counter for the whole repository. 36 Revision 154 might touch files on `trunk`, a branch, and `tags` simultaneously. 37 This makes it easy to refer to "the state of the entire project at r154," but it 38 also means revision numbers are not branch-specific identifiers. 39 40 ### Working copy 41 42 A working copy is a directory tree on a developer's machine, plus hidden 43 metadata in `.svn` directories (in SVN 1.7+, consolidated into a single `.svn` 44 at the working-copy root). The working copy tracks which revision it is based on 45 and which files have local modifications. 46 47 ### URL-based branching and tagging 48 49 Branches and tags in SVN are not lightweight pointers—they are **directory 50 copies** in the repository. A typical layout looks like: 51 52 ``` 53 /repos/myproject/ 54 trunk/ # main line of development 55 branches/ # feature or release branches 56 tags/ # immutable release snapshots 57 ``` 58 59 Creating a branch means copying `trunk` to `branches/feature-x` on the server. 60 Tags are the same operation, conventionally treated as read-only. 61 62 ### Atomic commits 63 64 Unlike CVS, SVN commits are atomic: either all changes in a commit land 65 together, or none do. Directory adds, deletes, and renames are versioned as 66 first-class operations. 67 68 ## Basic Workflow 69 70 A typical SVN session looks like this: 71 72 1. **Checkout** — `svn checkout URL` creates a working copy from the server. 73 2. **Update** — `svn update` pulls newer revisions from the server into the 74 working copy. 75 3. **Edit** — modify files locally. 76 4. **Diff / status** — `svn diff` and `svn status` show local changes (against 77 the last updated base revision). 78 5. **Commit** — `svn commit -m "message"` sends changes to the server and 79 receives a new revision number. 80 81 Conflicts arise when your working copy is out of date relative to the server. 82 You must run `svn update`, resolve conflicts in affected files, then commit. 83 84 ## Subversion vs Git 85 86 Git and Subversion solve the same problem—tracking changes to files over 87 time—but their architectures diverge sharply. The table below summarizes the 88 main differences. 89 90 | Aspect | Subversion (SVN) | Git | 91 | ----------------- | --------------------------------------- | ----------------------------------------- | 92 | Model | Centralized (CVCS) | Distributed (DVCS) | 93 | Canonical history | Lives on the server | Lives in every clone | 94 | Revision identity | Global integer (`r1234`) | Content-addressed hash (`a3f9c2…`) | 95 | Branching | Server-side directory copy | Lightweight local pointer | 96 | Tagging | Directory copy (convention) | Named pointer to a commit | 97 | Offline work | Edit files yes; commit/log/diff limited | Full history and commits offline | 98 | Clone size | Working copy (often partial) | Full repository (unless shallow) | 99 | Merge tracking | Improved over time; still URL-centric | Native, graph-based merge engine | 100 | Partial checkouts | Supported (`svn checkout` subtrees) | Sparse checkout supported but less common | 101 | Access control | Path-based ACLs on server | Per-repository; hosting platform policies | 102 103 ### Architecture: centralized vs distributed 104 105 SVN assumes a hub-and-spoke model. The server is the source of truth; clients 106 are thin working copies. This simplifies administration in some environments: 107 backup one server, enforce permissions on paths, and audit a single log. 108 109 Git assumes every developer has the full history (or a substantial subset). 110 Commits happen locally first; **push** and **pull** synchronize with remotes. 111 There can be many remotes, forks, and offline workflows. The trade-off is more 112 complexity on the client and a steeper learning curve, in exchange for speed, 113 flexibility, and resilience when the network is unavailable. 114 115 ### Branching and merging 116 117 In SVN, branching is relatively heavyweight: a `svn copy` on the server creates 118 a new directory tree. Merging in SVN historically meant tracking which revisions 119 had already been merged between branches—a workable but often painful process, 120 especially on long-lived branches. 121 122 In Git, a branch is a small file pointing at a commit. Creating and switching 123 branches is nearly instantaneous and local. Git's merge and rebase machinery 124 operates on a directed acyclic graph of commits, which supports workflows like 125 feature branches, interactive rebasing, and cherry-picking with far less 126 friction than classic SVN workflows. 127 128 ### Revision numbers vs commit hashes 129 130 SVN's global revision numbers are human-friendly and sortable across the whole 131 repository. They are also ambiguous across branches: "r500" does not tell you 132 which branch it belongs to without context. 133 134 Git's SHA-1 (or SHA-256 in newer versions) hashes uniquely identify commits by 135 their content and ancestry. They are globally unique within a repository but 136 opaque to humans. Tools and hosting platforms add branch names and tags as 137 readable aliases. 138 139 ### Performance and scale 140 141 For very large monorepos, SVN's ability to check out only a subtree was 142 historically an advantage. Git has caught up with partial clone, sparse 143 checkout, and submodules, but shallow clones and monorepo tooling remain active 144 areas of practice. 145 146 For everyday developer operations—commit, branch, merge, bisect, blame—Git is 147 typically faster because work is local and does not round-trip to a server for 148 each action. 149 150 ### History rewriting 151 152 SVN treats committed history on the server as largely append-only. While 153 administrators can use tools like `svnadmin` or `svnsync` for maintenance, 154 rewriting published history is uncommon and disruptive. 155 156 Git encourages rewriting local history before sharing (`rebase`, `amend`, 157 `squash`). Once commits are pushed to shared branches, rewriting requires 158 coordination; hosting platforms and team policy govern what is acceptable. 159 160 ## Conceptual Mapping 161 162 Developers moving between systems often map operations as follows: 163 164 | Intent | Subversion | Git | 165 | ----------------- | --------------------------- | ----------------------------------- | 166 | Get a copy | `svn checkout URL` | `git clone URL` | 167 | Download updates | `svn update` | `git pull` | 168 | Upload changes | `svn commit` | `git commit` then `git push` | 169 | See local changes | `svn status`, `svn diff` | `git status`, `git diff` | 170 | Create a branch | `svn copy trunk branches/x` | `git branch x` or `git switch -c x` | 171 | Switch branch | `svn switch URL` | `git switch branch` | 172 | Merge | `svn merge -r X:Y URL` | `git merge branch` or `git rebase` | 173 | View history | `svn log` | `git log` | 174 | Revert a file | `svn revert file` | `git restore file` | 175 176 The mapping is approximate. Git separates **commit** (local) from **push** 177 (remote); SVN combines them in a single `commit` that immediately affects the 178 central server. 179 180 ## Strengths and Limitations 181 182 ### Where Subversion still fits 183 184 - Organizations with established SVN infrastructure, path-based permissions, and 185 trained operations staff. 186 - Workflows that prefer a single canonical server and simple mental model. 187 - Environments where developers always have reliable network access to the 188 repository. 189 - Legacy projects where migration cost outweighs the benefit of moving to Git. 190 191 ### Where Git is usually preferred 192 193 - Distributed teams, open-source collaboration, and fork-based workflows. 194 - Heavy branching (feature branches, release trains, hotfix branches). 195 - Offline or intermittent connectivity. 196 - Ecosystem integration: GitHub, GitLab, and most modern CI/CD and code-review 197 tooling assume Git as the default. 198 199 ## Summary 200 201 Subversion is a centralized version control system built around a single server, 202 global revision numbers, and URL-oriented branches. It improved substantially on 203 CVS and served as the dominant open-source VCS through much of the 2000s. 204 205 Git is a distributed system where every clone carries history, branches are 206 lightweight, and merges are graph-driven. It has become the de facto standard 207 for new projects and most tooling ecosystems. 208 209 Choosing between them today is less a question of raw capability—both can 210 version code reliably—than of workflow, team habits, infrastructure, and whether 211 a centralized or distributed model better matches how the organization works. 212 For greenfield work, Git is the norm; for existing SVN estates, migration tools 213 (`git svn`, `svn2git`) and phased transitions remain the practical path when a 214 move is warranted.