SVN Basic Terms and Commands

Summarizes the meaning of SVN repositories, revisions, trunk, branches, and tags, along with basic command usage such as import, checkout, commit, update, diff, blame, and lock.

Tags:

SVN (Subversion) is a version control system that manages source code and change history around a central repository. Unlike Git, where each developer clones the full repository history locally, SVN is typically used by checking out a project from the central repository into a working copy, modifying it, and committing it back.

This document summarizes common terms and basic commands that developers new to SVN often encounter, organized around practical workflows.

Basic Terms

Repository

A Repository is the central storage location for a project’s files and change history. It stores not only source code, but also history such as file additions, modifications, deletions, and directory structure changes.

SVN repositories are usually placed on a server and accessed by multiple developers over a network. Depending on the environment, access methods such as http://, https://, svn://, svn+ssh://, and file:// can be used.

https://svn.example.com/repos/sample
svn+ssh://svn.example.com/svn/sample
file:///var/svn/sample

In production, choose either to separate repositories by project or to keep multiple project directories in one repository. If permission management, backup scope, or deployment units differ, separating repositories is usually easier to manage.

Revision

A Revision is the repository change number. In SVN, revision numbers do not increase separately for each file. Instead, the whole repository revision number increases whenever a commit occurs.

For example, even if only one file, sample.c, is modified and committed, the repository revision increases from r10 to r11. You can use this revision number to retrieve source code from a specific point in time or compare change history.

svn log -r 10:20
svn diff -r 10:11 sample.c
svn checkout -r 10 https://svn.example.com/repos/sample/trunk sample-r10

trunk

trunk is the main development line of a project. Daily development work is generally done in trunk.

sample/
  trunk/
    src/
    pom.xml

Rules vary by team, but it is best to keep trunk buildable at all times. Large feature development or long-running changes should be separated into branches and merged back into trunk after stabilization.

branches

branches are development lines branched from trunk. They are used when work must be separated from trunk, such as release maintenance, large feature development, or experimental work.

sample/
  branches/
    feature-payment/
    release-1.0/

A branch may look like a directory copy, but SVN internally manages it as a copy that preserves change history. When creating a branch, use svn copy instead of normal file copying.

svn copy https://svn.example.com/repos/sample/trunk \
  https://svn.example.com/repos/sample/branches/feature-payment \
  -m "Create feature-payment branch"

Basic Workflow

The basic SVN workflow is to fetch source code from the repository, modify it locally, check the changes, and commit them to the central repository.

svn checkout svn+ssh://svn.example.com/svn/sample/trunk sample
cd sample

svn update
svn status
svn diff

svn add new-file.c
svn commit -m "Add new file"

Before committing, it is good practice to run svn update to incorporate the latest changes, and then check what you will upload with svn status and svn diff.

Main Commands

import

svn import is used to initially register a local directory that is not yet managed by SVN into a repository. It is mainly used when uploading a project to a repository for the first time, and it is not a command commonly used in an already checked-out working copy.

svn import sampledir svn+ssh://svn.example.com/svn/sample/trunk \
  -m "Initial import"

import uploads the local directory to the repository, but it does not automatically turn that local directory into a working copy. After the initial registration, it is safer to check out the project again and continue development from that checkout.

svn checkout svn+ssh://svn.example.com/svn/sample/trunk sample

checkout

svn checkout fetches files from a repository into a local working copy. The working copy includes actual source files as well as metadata used by SVN to track change status.

svn checkout svn+ssh://svn.example.com/svn/sample/trunk sample

You can also use the short alias co.

svn co svn+ssh://svn.example.com/svn/sample/trunk sample

Inside a checked-out directory, you can edit code like normal files. However, file additions, deletions, moves, and renames should be handled with SVN commands whenever possible so repository history remains accurate.

export

svn export is used when you want to retrieve only the pure files without version control metadata. It is useful when you need a deployment source package or a temporary directory for checking files.

svn export svn+ssh://svn.example.com/svn/sample/trunk sample-release

You can also fetch files from a specific revision.

svn export -r 120 svn+ssh://svn.example.com/svn/sample/trunk sample-r120

A directory received through export is not a working copy, so commands such as svn update, svn commit, and svn status cannot be used. If you need a directory for continued development, use checkout instead of export.

update

svn update applies the latest repository changes to the current working copy. In an environment where multiple people use the same repository, it is good to run it before modifying and before committing.

svn update

You can use the short alias up.

svn up

Use the -r option to set the working copy to a specific revision.

svn update -r 120

If multiple people modified the same part of the same file during update, a conflict can occur. When a conflict occurs, check the file contents, resolve them manually, tell SVN that the conflict is resolved, and then commit.

svn status
svn resolve --accept=working sample.c
svn commit -m "Resolve conflict in sample.c"

status

svn status checks changed file status in the working copy. It is a command you should always check before committing.

svn status

Common status characters are as follows.

Status	Meaning
`M`	Modified
`A`	Scheduled for addition
`D`	Scheduled for deletion
`?`	File not tracked by SVN
`!`	File tracked by SVN but missing locally
`C`	Conflict occurred

Example:

$ svn status
M       src/main.c
A       src/new-file.c
?       build.log

Files marked with ? are not committed. To upload a new file to the repository, run svn add first.

add

svn add registers a new file or directory as a version-controlled target. Registering it does not immediately upload it to the repository. You must run commit afterward.

svn add sample.c
svn commit sample.c -m "Add sample.c"

When adding a directory, internal files may also be scheduled for addition, so check with svn status before committing to make sure unnecessary files are not included. Files that should not be committed, such as build artifacts, logs, or IDE settings, should be excluded with the svn:ignore property or client ignore settings.

commit

svn commit applies working copy changes to the repository. When a commit succeeds, the repository revision increases.

svn commit -m "Fix login validation"

You can use the short alias ci.

svn ci -m "Fix login validation"

You can also commit only a specific file.

svn commit src/login.c -m "Fix login validation"

Write commit messages so the reason for the change is clear. If you leave only vague messages such as fix, update, or test, it becomes difficult to trace history later with svn log.

The pre-commit check flow is as follows.

svn update
svn status
svn diff
svn commit -m "Fix login validation"

log

svn log checks repository change history.

svn log

Use the -v option if you want to see the changed file list as well.

svn log -v

You can also view logs for a specific revision range or file.

svn log -r 30:100 sample.c

If you specify a remote repository URL directly, you can check history even in an environment without a working copy.

svn log https://svn.example.com/repos/sample/trunk

diff

svn diff compares changes in the working copy. By default, it shows the difference between local changes and the base revision.

svn diff

You can compare only a specific file.

svn diff sample.c

Use the -r or --revision option to compare with a specific revision.

svn diff -r 4 sample.c
svn diff -r 10:20 sample.c

Before committing, check the changed file list with svn status and review the actual code changes with svn diff. This helps catch debug code, temporary logs, or unnecessary formatting changes mixed into the commit.

blame

svn blame shows which revision and author changed each line of a file. It is useful when investigating the background of problematic code.

svn blame sample.c

Some SVN clients also support aliases such as praise, annotate, and ann. However, instead of blaming the author based only on blame results, check the log at the time and related changed files together.

svn log -r 120 -v
svn diff -c 120 sample.c

lock and unlock

svn lock is used to lock a specific file so other users cannot modify it. It is mainly used for binary files, design files, and document files that are difficult to merge.

svn lock sample.docx -m "Edit release note"

Use svn unlock to release a lock.

svn unlock sample.docx

For text source code, working with merge as the default is usually more efficient than locking. If every file is habitually locked, collaboration can slow down, so define team rules for file types that require locking.

delete, move, copy

In SVN, it is safer to use SVN commands for deleting, moving, and copying files rather than normal file system commands. This keeps repository history accurate.

svn delete old-file.c
svn move old-name.c new-name.c
svn copy trunk branches/feature-a

Delete and move operations are not reflected in the repository immediately. They remain scheduled changes in the working copy and are finalized only after commit.

svn status
svn commit -m "Rename old-name.c to new-name.c"

File Backup and Recovery

Use svnadmin dump and svnadmin load when backing up an entire repository or moving it to another server. These are administrative commands that directly handle the server repository directory, not regular svn commands run in a working copy.

svnadmin dump /var/svn/sample > sample.dump

To restore a dump file into a new repository, create the repository first and then run load.

svnadmin create /var/svn/sample-new
svnadmin load /var/svn/sample-new < sample.dump

When backing up a production repository, check the following items together.

Do not confuse the repository path with the project URL.
Store backup files on another server or storage.
Perform recovery tests regularly.
Also back up repository hooks, access permission settings, and Apache or svnserve settings.

Common Work Examples

When creating a new file

SVN does not automatically track new files. You must add the file and then commit it to upload it to the repository.

touch sample.c
svn status
svn add sample.c
svn commit sample.c -m "Add sample.c"

When modifying an existing file

For files already tracked by SVN, you can check status and differences immediately after modifying them and then commit.

svn update
vi sample.c
svn status
svn diff sample.c
svn commit sample.c -m "Fix sample calculation"

When applying the latest repository contents

Use svn update to fetch changes made by other developers.

svn update

If a conflict occurs, clean up the conflicted file, mark it as resolved, and commit.

svn status
vi sample.c
svn resolve --accept=working sample.c
svn commit sample.c -m "Resolve merge conflict"

Practical Cautions

Check update, status, and diff before committing

Because SVN collaboration is based on a central repository, it is important to make a habit of applying the latest changes before committing. If you commit from an old working copy without running svn update, you may discover conflicts late or miss the context of other changes.

svn update
svn status
svn diff

Handle file operations with SVN commands

Use svn add for file additions, svn delete for deletions, and svn move for moves and renames. If you only use the operating system’s rm, mv, or file explorer, SVN may not accurately track the intended changes.

Define trunk, branches, and tags rules as a team

SVN does not enforce a directory structure. trunk, branches, and tags are widely used conventions, but the actual operation method should be defined as team rules.

Common rules are as follows.

Keep trunk buildable at all times.
Do long-running feature development in branches.
Leave released source code in tags and do not modify it.
Restrict permissions for creating tags and release branches.

Define a locking policy for binary files

For files that are difficult to merge automatically, such as images, documents, and design files, using svn lock can be safer. On the other hand, excessive locking of text source code makes parallel development difficult. Decide whether to use locking by file type, and set a rule for leaving lock messages.