Branches, Tags, and Merging in SVN

Open almost any SVN repository and you find three top-level directories:

/trunk
/branches
/tags

• trunk is the main line of development, the equivalent of Git's default branch.
• branches holds parallel lines of work: a feature, a release stabilization, an experiment.
• tags holds named snapshots, typically releases like 1.4.0.

The crucial thing to understand: this is a convention, not a built-in feature. SVN itself has no special "branch" or "tag" object. These are just ordinary directories that everyone agrees to use a certain way. That single fact, that branching is done with directories, shapes everything else in this lesson and is the biggest mental shift for someone coming from Git.

If a branch is a copy of trunk, does copying a huge project waste huge space? No, because of cheap copies. When you run svn copy inside the repository, the server does not duplicate the files. It records a small pointer that says, in effect, "this new path is trunk as of revision N." The copy takes a few bytes and is near-instant regardless of project size.

svn copy https://svn.example.com/repos/acme/trunk \
         https://svn.example.com/repos/acme/branches/feature-tax \
         -m "Create feature-tax branch from trunk"

That single server-side copy creates the branch. Nothing is downloaded. Storage only grows as the branch actually diverges from trunk, because SVN stores the differences from that shared starting point. Cheap copies are what make the directory-based approach practical.

Here is the idea that surprises newcomers: in SVN there is no technical difference between a branch and a tag. Both are created the identical way, with svn copy. Both are just directories under your chosen convention.

The only difference is human discipline. A branch is a copy you intend to keep committing to. A tag is a copy you agree to treat as a frozen snapshot and never modify, so /tags/1.4.0 stays a faithful record of exactly what release 1.4.0 contained.

svn copy https://.../trunk https://.../tags/1.4.0 -m "Tag release 1.4.0"

Because SVN does not enforce that a tag is immutable, teams often add a server-side hook to reject commits under /tags. The mechanism is trivial; the meaning is entirely a team agreement.

Once a branch exists, you have two ways to work on it. You can check it out fresh, or you can point an existing working copy at it with svn switch, which efficiently moves your working copy to the branch, transferring only the differences.

# Option A: fresh checkout of the branch
svn checkout https://.../branches/feature-tax

# Option B: switch an existing working copy to the branch
svn switch https://.../branches/feature-tax
# ... work and commit normally; commits land on the branch ...

From here the daily workflow from the previous lesson is unchanged: update, edit, commit. Your commits simply land under the branch path instead of trunk. Meanwhile, other people keep committing to trunk, and the two lines diverge until someone merges them, which is the next step.

Merging brings changes from one line into another, for example folding trunk's recent fixes into your branch, or your finished feature back into trunk. The command is svn merge.

Early SVN made you track by hand which revisions you had already merged, which was error-prone. Since version 1.5, SVN has merge tracking: it records merges in a property called svn:mergeinfo on the target, so it knows which revisions have already come across and will not apply them twice.

# On a trunk working copy, pull in the branch's changes:
svn merge https://.../branches/feature-tax
svn commit -m "Merge feature-tax into trunk"

The merge itself is a normal set of local changes that you review and then commit as one revision. Because svn:mergeinfo is versioned, the record of what was merged travels with the repository.

The shape of a typical feature branch: it is copied from trunk at some revision, receives its own commits while trunk keeps moving, and is eventually merged back into trunk as a single reviewed revision. After the merge, the branch can be deleted; its history remains reachable because everything is just revisions in the one repository.

Many teams keep SVN for some repositories and Git for others, or migrate one to the other. The bridge is git svn, a Git command that speaks the SVN protocol.

# Clone an SVN repo into Git, mapping its standard layout:
git svn clone --stdlayout https://svn.example.com/repos/acme acme-git
# work locally in Git, then send commits back to SVN:
cd acme-git
git svn dcommit

--stdlayout tells git svn about the trunk/branches/tags convention so it maps them to Git branches. git svn dcommit replays your local Git commits back onto the SVN server as SVN revisions. This lets an individual use Git's local workflow against a central SVN repository, and it is the usual first step in a full migration. For a one-way move, dedicated tools like svn2git produce a cleaner Git history.

Putting the cursus together: SVN is a centralized system with global revision numbers and atomic commits, a simple update-edit-commit workflow, and branching built from cheap directory copies with merge tracking since 1.5.

Git is the right default for most new projects, especially distributed teams and branch-heavy workflows. But SVN remains a deliberate choice when you need fine-grained path-based access control, graceful handling of large binary assets, and a single authoritative history, which is why studios, and some enterprise, government, and financial teams keep it. As a skill it is quietly valuable precisely because it is niche: plenty of long-lived, high-value codebases still run on SVN, and fewer engineers can confidently work in it. Knowing both models, and how to bridge them with git svn, makes you useful wherever the code actually lives.