Branches, Merging & SVN's Place Today

trunk / branches / tags

repo/
  trunk/       ← main line of development
  branches/
    feature-x/ ← a cheap directory copy of trunk
  tags/
    v1.0/      ← a fixed snapshot

This layout is a community convention, not enforced by SVN itself — SVN has no first-class "branch" object. A branch is just a cheap, copy-on-write directory copy of trunk into a new path, which is why merging in SVN has historically been considered more cumbersome than Git's DAG-based commit history (svn:mergeinfo metadata tracks merges, but less robustly than Git's native model).

Locking Unmergeable Files

svn lock lets a user reserve exclusive editing rights to a file — historically important for binary assets that text-based merge tools can't meaningfully combine, preventing two people from making conflicting, unresolvable changes simultaneously.

Why SVN Persists

New projects overwhelmingly choose Git, but plenty of long-lived enterprise, government, and legacy codebases still run on SVN — migrating a long history and established team habits can outweigh the benefits, especially where SVN's centralized model already fits access-control needs. Fine-grained, server-enforced path-based permissions are a genuine advantage some organizations cite for staying centralized.

Trunk-Based Development

Given SVN's merge-tracking pain points, trunk-based development — integrating changes frequently into the main line rather than maintaining many long-lived divergent branches — became a common practice to sidestep the cost of eventually merging widely diverged branches back together.