The Core Subversion Workflow

SVN's day-to-day rhythm is three steps repeated: update, edit, commit.

• Update (svn update): pull the latest changes from the central repository into your working copy, so you are building on current code.
• Edit: change, add, or remove files.
• Commit (svn commit): send your changes back as a new revision.

Because the repository is central (from the previous lesson), update and commit both talk to the server, and every commit creates the next global revision number. The habit that keeps you out of trouble is to update before you start and again before you commit, so your changes apply on top of what everyone else has already committed. The rest of this lesson fills in the commands around that loop.

Before committing, you check what you have done. svn status lists changed paths, each prefixed by a one-letter code:

svn status
# M       src/invoice.py
# ?       notes.txt

svn diff shows the actual line-level changes in a familiar patch format, and svn diff -r 100:120 file compares two revisions. Reading status and diff before every commit is the single best habit for keeping history clean: it stops you committing a stray debug file or a change you meant to revert.

SVN does not version a new file until you tell it to. The commands schedule an operation locally; it becomes real in the repository on your next commit.

svn add newmodule.py        # schedule for addition (A)
svn delete oldmodule.py     # schedule for deletion (D)
svn move a.py b.py          # rename/move, tracked as a move
svn commit -m "Restructure billing module"

Two things to remember. First, always use svn move and svn delete rather than your operating system's move or rm; a plain OS delete leaves SVN seeing the file as missing (!) rather than intentionally removed. Second, nothing you add, delete, or move touches the repository until you commit, so you can stage a set of structural changes and send them as one coherent, atomic revision.

A commit bundles your staged changes into the next revision. Always write a message that says why:

svn commit -m "Fix rounding in invoice totals (bug 812)"
# Committed revision 4218.

The server responds with the new global revision number. To read history, svn log walks backward through revisions with their author, date, and message:

svn log -l 5              # last 5 revisions
svn log -v -r 4218       # revision 4218 with the list of changed paths

Because history lives on the server, svn log and svn diff across old revisions are network operations, unlike Git where they are local. In exchange, there is exactly one authoritative log, and a revision number in a commit message or bug tracker points everyone at the same repository-wide state.

By default SVN uses a copy-modify-merge model, the same collaborative idea as Git: two people can edit the same file at once, and SVN merges their changes automatically when they do not overlap.

When they do overlap on the same lines, svn update reports a conflict (status C) and writes conflict markers into the file plus a few helper files. You resolve it by editing the file to the correct final content, then telling SVN it is settled:

svn update
# Conflict discovered in 'invoice.py'.
# ... edit the file, keep the right lines ...
svn resolve --accept working invoice.py
svn commit -m "Merge tax logic"

Conflicts are normal, not errors. They simply mark the spots where SVN cannot safely guess whose change wins, and hands the decision to you.

Copy-modify-merge assumes files can be merged. Binary files, a Photoshop file, a compiled asset, a Word document, cannot: there is no sensible way to combine two people's edits line by line. For these, SVN offers the older lock-modify-unlock model on demand.

svn lock design.psd -m "Editing the hero banner"
# ... edit exclusively ...
svn commit -m "New hero banner"   # releases the lock

While you hold the lock, others cannot commit changes to that file. To make locking mandatory for a file type, set the svn:needs-lock property on those files, so anyone who checks them out gets them read-only until they explicitly lock. This is exactly the workflow that makes SVN attractive to teams with lots of binary assets, where silent parallel edits would mean lost work.

SVN can attach named properties to files and directories, versioned alongside the content. A few earn their keep on almost every project:

• svn:ignore: on a directory, a list of patterns SVN should stop reporting as unversioned (build output, editor temp files), the equivalent of a .gitignore entry.
• svn:eol-style: normalizes line endings across Windows, macOS, and Linux so a mixed team does not thrash on invisible whitespace.
• svn:needs-lock: the lock-first flag for binaries from the previous step.

svn propset svn:ignore "build/" .
svn propget svn:ignore .
svn commit -m "Ignore build output"

Properties are versioned like everything else, so changing one is a normal commit that shows up in the log.

Two different undos, for two different situations.

To throw away uncommitted local edits and return a file to its checked-out state, use svn revert. It touches only your working copy, so it is safe and local:

svn revert invoice.py        # discard local edits to one file
svn revert -R .              # discard all local edits, recursively

To undo a change that was already committed, you do not delete history; you make a new commit that reverses it, using a reverse merge:

svn merge -c -4218 .         # apply the inverse of revision 4218
svn commit -m "Revert bad rounding change (r4218)"

The negative revision tells SVN to apply that commit backward. History stays intact and auditable, and the reversal is itself a new, numbered revision. That is the whole daily toolkit; the next lesson moves up to branches, tags, and merging.