SVN & Git-SVN

Version control is essential for software development, and in 2008 we're in an interesting transitional period. Subversion (SVN) is the dominant centralized version control system, but Git is gaining momentum fast. Many teams use SVN for their repositories but want Git's powerful local branching and workflow features.

Enter git-svn: a bridge that lets you use Git as your local client while working with SVN repositories.

What is SVN?

Subversion (SVN) is a centralized version control system released in 2000 as a better alternative to CVS. It's widely adopted in enterprise and open-source projects.

Key Characteristics of SVN

• Centralized model: Single central repository, everyone commits to it
• Revision numbers: Sequential numbers (r1, r2, r3, etc.)
• Atomic commits: All-or-nothing commits across multiple files
• Directory versioning: Can version entire directory trees
• Efficient binary handling: Better than CVS for binary files

SVN Workflow

Central Repository
        ↑↓
    Developer A
        ↑↓
    Developer B

Everyone works with a working copy checked out from the central repository. Commits go directly to the server.

What is Git?

Git is a distributed version control system created by Linus Torvalds in 2005 for Linux kernel development. Unlike SVN, every developer has a complete repository copy.

Key Characteristics of Git

• Distributed model: Every clone is a full repository
• SHA-1 hashes: Commits identified by cryptographic hashes
• Cheap branching: Create and merge branches effortlessly
• Local operations: Commit, branch, and view history offline
• Powerful merging: Superior merge algorithms

Git's Advantages

• Speed: Most operations are local and fast
• Branching: Create feature branches without fear
• Offline work: Commit, branch, and work without network
• Flexible workflows: Support various team workflows
• Data integrity: SHA-1 ensures repository integrity

The Problem: Using Git with SVN Repositories

Many teams are stuck with SVN repositories for various reasons:

• Corporate policies
• Legacy projects
• Team familiarity
• Tool integration

But developers who've tasted Git's workflow don't want to go back to SVN's limitations. This is where git-svn comes in.

What is git-svn?

git-svn is a Git command that provides bidirectional operation between a Git repository and a Subversion repository. It lets you:

• Clone an SVN repository as a Git repository
• Work locally with all Git's features
• Commit back to the SVN repository
• Pull updates from SVN
• Use Git branches while maintaining SVN compatibility

Think of it as a Git interface to an SVN backend.

Checking Repository Version

A common task is checking what revision the repository is at.

With SVN

To check the current HEAD revision on an SVN server:

$ svn info -r HEAD

Example output:

Path: trunk
URL: http://svn.example.com/project/trunk
Repository Root: http://svn.example.com/project
Repository UUID: 12345678-1234-1234-1234-123456789abc
Revision: 1523
Node Kind: directory
Last Changed Author: john
Last Changed Rev: 1523
Last Changed Date: 2008-11-22 10:30:45 -0500 (Sat, 22 Nov 2008)

The key information here is Revision: 1523.

You can also check specific paths:

$ svn info -r HEAD http://svn.example.com/project/trunk

With git-svn

When using git-svn, you need different commands to get SVN revision information:

Get SVN revision info:

$ git svn info

Example output:

Path: .
URL: http://svn.example.com/project/trunk
Repository Root: http://svn.example.com/project
Repository UUID: 12345678-1234-1234-1234-123456789abc
Revision: 1523
Node Kind: directory
Last Changed Author: john
Last Changed Rev: 1523
Last Changed Date: 2008-11-22 10:30:45 -0500

Find SVN revision for current HEAD:

$ git svn find-rev HEAD

Output:

1523

See SVN revisions in Git log:

$ git log --grep=git-svn-id -1

This shows commits with their corresponding SVN revision numbers embedded in the commit message.

Setting Up git-svn

Installation

Git-svn comes with Git. If you have Git installed, you have git-svn.

Verify:

$ git svn --version

Cloning an SVN Repository

To start using git-svn, clone an SVN repository:

$ git svn clone http://svn.example.com/project/trunk

For projects with standard SVN layout (trunk, branches, tags):

$ git svn clone -s http://svn.example.com/project

The -s flag tells git-svn about the standard layout.

For large repositories, this can take a while as it fetches the entire history. You can limit history:

$ git svn clone -s -r 1000:HEAD http://svn.example.com/project

This fetches only revisions from 1000 onwards.

Basic git-svn Workflow

1. Clone the Repository

$ git svn clone -s http://svn.example.com/project myproject
$ cd myproject

2. Work Locally with Git

Now you have a full Git repository. Use Git normally:

# Create a feature branch
$ git checkout -b new-feature

# Make changes
$ vim file.txt

# Commit locally (as many times as you want)
$ git add file.txt
$ git commit -m "Add new feature"

# More commits
$ git commit -am "Refine feature"
$ git commit -am "Fix bug in feature"

3. Update from SVN

Before pushing to SVN, get the latest changes:

$ git svn rebase

This fetches changes from SVN and replays your local commits on top. It's like svn update but better—it maintains clean history.

4. Push to SVN

When ready, push your commits to SVN:

$ git svn dcommit

This takes your Git commits and creates corresponding SVN commits. Each Git commit becomes an SVN revision.

Important: Only dcommit from your master branch (or the branch tracking SVN trunk).

Advanced git-svn Usage

Working with SVN Branches

List SVN branches:

$ git branch -r

Create a local branch tracking an SVN branch:

$ git checkout -b local-branch remotes/branch-name

Creating SVN Branches from Git

$ git svn branch new-svn-branch

This creates a branch in the SVN repository.

Merging

Use Git's powerful merge capabilities:

$ git checkout master
$ git merge feature-branch
$ git svn rebase
$ git svn dcommit

Viewing History

See both Git and SVN information:

$ git log --pretty=fuller --grep=git-svn-id

Find which Git commit corresponds to SVN revision:

$ git svn find-rev r1523

Find which SVN revision corresponds to Git commit:

$ git svn find-rev abc123

Essential Commands Cheat Sheet

SVN Commands

# Check repository info
$ svn info -r HEAD

# Update working copy
$ svn update

# See current status
$ svn status

# View log
$ svn log -l 10

# Check out repository
$ svn checkout http://svn.example.com/project/trunk

# Commit changes
$ svn commit -m "Commit message"

# See differences
$ svn diff

git-svn Commands

# Clone SVN repository
$ git svn clone -s http://svn.example.com/project

# Get latest from SVN
$ git svn rebase

# Push to SVN
$ git svn dcommit

# Get SVN info
$ git svn info

# Find SVN revision
$ git svn find-rev HEAD

# Create SVN branch
$ git svn branch branch-name

# Fetch from SVN (without rebasing)
$ git svn fetch

# Show SVN log
$ git svn log

Best Practices

1. Always Rebase Before Dcommit

$ git svn rebase
$ git svn dcommit

This ensures your changes are based on the latest SVN revision.

2. Don't Dcommit Merge Commits

Git merge commits don't translate well to SVN. Instead:

$ git rebase master feature-branch
$ git checkout master
$ git merge feature-branch  # Now it's a fast-forward

3. Keep Git Branches Local

Don't push Git branches to SVN unless necessary. Use Git branches for local development, then dcommit from master.

4. Use .gitignore

Git and SVN handle ignored files differently. Create a .gitignore file:

# Build artifacts
*.o
*.class
build/

# IDE files
.idea/
*.swp

# OS files
.DS_Store
Thumbs.db

5. Regular Fetches

Regularly fetch from SVN to stay up to date:

$ git svn fetch

Then rebase when ready:

$ git svn rebase

Common Scenarios

Scenario 1: Quick Fix While Working on Feature

# Working on feature branch
$ git checkout feature-branch
$ vim feature.txt
$ git commit -am "WIP: Feature in progress"

# Need to make quick fix
$ git checkout master
$ git svn rebase
$ vim bug.txt
$ git commit -am "Fix critical bug"
$ git svn dcommit

# Back to feature
$ git checkout feature-branch
$ git rebase master  # Include the fix

Scenario 2: Long-Running Feature Branch

# Start feature
$ git checkout -b big-feature

# Work for days
$ git commit -am "Part 1"
$ git commit -am "Part 2"

# Meanwhile, update from SVN
$ git checkout master
$ git svn rebase

# Merge updates into feature
$ git checkout big-feature
$ git rebase master

# When feature is done
$ git checkout master
$ git rebase big-feature
$ git svn dcommit

Scenario 3: Reviewing Changes Before Commit

# Make changes
$ git add .
$ git commit -m "Implement feature"

# Review what will go to SVN
$ git log master..HEAD

# Test thoroughly with Git
$ git svn rebase  # Get latest
$ run tests

# Satisfied? Push to SVN
$ git svn dcommit

Troubleshooting

Problem: "Working tree has modifications"

Git-svn requires a clean working tree.

Solution:

$ git stash
$ git svn rebase
$ git stash pop

Problem: Conflicts during rebase

Solution:

# Fix conflicts in files
$ vim conflicted-file.txt

# Mark as resolved
$ git add conflicted-file.txt

# Continue rebase
$ git rebase --continue

Problem: Accidental merge commit

Git merge commits confuse git-svn.

Solution:

# Reset to before merge
$ git reset --hard HEAD^

# Use rebase instead
$ git rebase other-branch

Problem: Need to abort everything

Solution:

$ git svn rebase --abort

Why Use git-svn?

Advantages

1. Local branching: Create and merge branches without affecting the repository
2. Offline commits: Commit locally without network access
3. Powerful history: Use Git's superior log, diff, and bisect tools
4. Flexible workflow: Work how you want, push to SVN when ready
5. Speed: Most operations are instant
6. Safety: Experiment locally without risk

Disadvantages

1. Learning curve: Need to understand both Git and SVN
2. Setup overhead: Initial clone can be slow for large repositories
3. Team coordination: If team uses SVN, you're on your own workflow
4. Complexity: More moving parts than pure SVN or pure Git

The Future

Git is growing rapidly. Projects like Ruby on Rails have switched from SVN to Git. GitHub is gaining popularity. Many teams are evaluating the move to distributed version control.

git-svn is a bridge technology—a way to get Git's benefits while infrastructure transitions. Eventually, many projects will move fully to Git or other distributed systems.

But for now, git-svn is an excellent solution for developers who want Git's power while working with SVN repositories.

Conclusion

Version control is evolving. SVN served us well as a replacement for CVS, but Git represents a fundamental shift in how we think about version control—from centralized to distributed, from server-dependent to local-first.

git-svn gives you the best of both worlds: Git's superior workflow and tooling with compatibility with existing SVN infrastructure.

If you're stuck using SVN at work but have experienced Git's branching and merging capabilities, git-svn is your answer. Clone the repository with git svn clone, work with Git locally, and push back to SVN with git svn dcommit. Your team will never know the difference, but you'll be far more productive.

Key takeaways:

• Use svn info -r HEAD to check SVN repository version
• Use git svn info or git svn find-rev HEAD for git-svn
• Clone with git svn clone -s URL
• Update with git svn rebase
• Push with git svn dcommit
• Work locally with full Git power

Version control should empower you, not constrain you. git-svn makes that possible. Last modified: 2026-01-15 WordPress ID: 1006