Subversion (SVN)

Version ControlCentralizedEnterpriseApacheLegacyRepository

Centralized Version Control System

Subversion (SVN)

Overview

Apache Subversion (SVN) is a centralized version control system developed by the Apache Software Foundation. First released in 2000, SVN was designed as a successor to CVS, addressing many of its limitations while maintaining a familiar centralized model. Unlike distributed systems like Git, SVN uses a central repository that all developers work with directly, making it straightforward for teams transitioning from older version control systems.

Details

Subversion follows a centralized architecture where a single repository server holds the master copy of the project. Developers check out working copies from this central repository, make changes locally, and commit them back to the server. This model provides clear authority and makes it easy to understand the current state of the project.

Key features include atomic commits (entire changesets succeed or fail together), directory versioning (renames and moves are tracked), and efficient binary file handling. SVN also supports branching and tagging, though these operations are more heavyweight compared to distributed systems.

The system uses a copy-modify-merge development model by default, though it can be configured for lock-modify-unlock when working with binary files that cannot be merged. SVN repositories can be accessed via multiple protocols including HTTP/HTTPS, svn://, and file://.

Subversion provides excellent support for enterprise environments with features like path-based authorization, hook scripts for custom workflows, and integration with authentication systems like LDAP and Active Directory.

Advantages and Disadvantages

Advantages

Simple Mental Model: Centralized approach is easy to understand
Atomic Commits: All-or-nothing changesets ensure consistency
Directory Versioning: Tracks renames, moves, and directory changes
Binary File Support: Efficient handling of large binary files
Mature Ecosystem: Extensive tool support and enterprise integration
Path-based Authorization: Fine-grained access control per directory
Network Efficiency: Only downloads changes, not entire history
Windows Integration: Excellent TortoiseSVN GUI client

Disadvantages

Centralized Dependency: Requires network connection for most operations
Single Point of Failure: Central server outage affects entire team
Slower Operations: Network latency impacts common operations
Limited Offline Work: Most operations require server connection
Branching Overhead: Branch creation is directory copy operation
Merge Complexity: Manual merge tracking until recent versions
Declining Popularity: Less community support than modern alternatives

Reference Pages

Code Examples

Repository Setup and Basic Operations

# Create a new SVN repository
svnadmin create /path/to/repository

# Import initial project structure
svn import /path/to/project file:///path/to/repository/trunk -m "Initial import"

# Checkout working copy
svn checkout http://svn.example.com/repo/trunk myproject
cd myproject

# Check status of working copy
svn status
svn st  # Short form

# Add new files
svn add newfile.txt
svn add newdirectory/

# Commit changes
svn commit -m "Add new functionality"
svn ci -m "Short form commit"  # Short form

Working with Files and Directories

# Update working copy with latest changes
svn update
svn up  # Short form

# View file history
svn log filename.txt
svn log -v  # Verbose output with changed paths

# Show differences
svn diff filename.txt
svn diff -r 100:200 filename.txt  # Between revisions

# Revert local changes
svn revert filename.txt
svn revert -R directory/  # Recursive revert

# Delete files
svn delete filename.txt
svn rm filename.txt  # Alternative command

# Move/rename files
svn move oldname.txt newname.txt
svn mv oldname.txt newname.txt  # Short form

Branching and Tagging

# Create a branch (server-side copy)
svn copy http://svn.example.com/repo/trunk \
         http://svn.example.com/repo/branches/feature-branch \
         -m "Create feature branch"

# Switch working copy to branch
svn switch http://svn.example.com/repo/branches/feature-branch

# Create a tag
svn copy http://svn.example.com/repo/trunk \
         http://svn.example.com/repo/tags/v1.0.0 \
         -m "Tag version 1.0.0"

# List branches and tags
svn list http://svn.example.com/repo/branches/
svn list http://svn.example.com/repo/tags/

# Merge changes from trunk to branch
svn merge http://svn.example.com/repo/trunk

# Merge branch back to trunk
cd trunk-working-copy
svn merge --reintegrate http://svn.example.com/repo/branches/feature-branch

Repository Information and Analysis

# Show repository information
svn info

# Show detailed log with changed paths
svn log -v -r 1:HEAD

# Show file content at specific revision
svn cat -r 100 filename.txt

# List files in repository
svn list http://svn.example.com/repo/trunk/
svn ls http://svn.example.com/repo/trunk/  # Short form

# Show blame/annotation
svn blame filename.txt
svn ann filename.txt  # Short form

# Export clean copy (no .svn directories)
svn export http://svn.example.com/repo/trunk /path/to/export

Conflict Resolution

# When conflicts occur during update/merge
svn status  # Shows conflicted files with 'C'

# View conflict markers in file
cat conflicted-file.txt

# Resolve conflicts manually, then mark as resolved
svn resolved conflicted-file.txt

# Or use interactive conflict resolution
svn update --accept postpone  # Review conflicts later
svn resolve --accept working conflicted-file.txt

# Accept specific version during conflicts
svn resolve --accept theirs-full conflicted-file.txt  # Use repository version
svn resolve --accept mine-full conflicted-file.txt    # Use local version

Repository Administration

# Create repository with specific format
svnadmin create --fs-type fsfs /path/to/repository

# Backup repository
svnadmin dump /path/to/repository > backup.dump

# Restore from backup
svnadmin load /path/to/new-repository < backup.dump

# Verify repository integrity
svnadmin verify /path/to/repository

# Repository statistics
svnadmin info /path/to/repository

# Create hook scripts (example: pre-commit hook)
#!/bin/sh
# /path/to/repository/hooks/pre-commit
REPOS="$1"
TXN="$2"

# Check that log message is not empty
LOGMSG=$(svnlook log -t "$TXN" "$REPOS" | grep -v "^$" | wc -l)
if [ "$LOGMSG" -lt 1 ]; then
  echo "Empty log message not allowed" >&2
  exit 1
fi

Working with Properties

# Set file properties
svn propset svn:eol-style native filename.txt
svn propset svn:keywords "Date Author" filename.txt

# List properties
svn proplist filename.txt
svn pl filename.txt  # Short form

# View property values
svn propget svn:eol-style filename.txt
svn pg svn:eol-style filename.txt  # Short form

# Set directory properties
svn propset svn:ignore "*.log
*.tmp" directory/

# Remove properties
svn propdel svn:keywords filename.txt
svn pd svn:keywords filename.txt  # Short form

Advanced Operations

# Create patch file
svn diff > changes.patch

# Apply patch
patch -p0 < changes.patch

# Show repository tree structure
svn ls -R http://svn.example.com/repo/

# Lock files for exclusive editing
svn lock filename.txt -m "Editing config file"

# Unlock files
svn unlock filename.txt

# Show locks
svn status -u  # Shows locks and out-of-date files

# Cleanup working copy after interrupted operations
svn cleanup

Integration with Build Systems

# Get revision number for builds
REV=$(svn info --show-item revision)
echo "Building revision $REV"

# Export for deployment (no .svn directories)
svn export http://svn.example.com/repo/tags/v1.0.0 /deployment/path

# Use SVN keywords in source files
# File content: /* Version: $Rev$ */
# After commit: /* Version: $Rev: 123 $ */

# Hook script for automated deployment
#!/bin/sh
# post-commit hook
REPOS="$1"
REV="$2"

# Deploy to staging on trunk commits
if svnlook changed -r "$REV" "$REPOS" | grep "^U.*trunk/"; then
    svn export "$REPOS/trunk" /staging/deployment/
fi