LinuxCommandLibrary

git-svn

Use Git as a Subversion client

TLDR

Clone an SVN repository

$ git svn clone [https://example.com/subversion_repo] [local_dir]
copy

Clone an SVN repository starting at a given revision number
$ git svn clone [[-r|--revision]] [1234]:HEAD [https://svn.example.net/subversion/repo] [local_dir]
copy

Update local clone from the remote SVN repository
$ git svn rebase
copy

Fetch updates from the remote SVN repository without changing the Git HEAD
$ git svn fetch
copy

Commit back to the SVN repository
$ git svn commit
copy

SYNOPSIS

git svn command [options]

PARAMETERS

clone [git_repository]
    Clone a Subversion repository into a new Git repository.

fetch
    Fetch new revisions from the Subversion repository.

rebase
    Rebase your local commits on top of the latest Subversion revisions.

dcommit
    Push your local commits to the Subversion repository.

branch
    Create a new branch from a Subversion repository.

init
    Initialize a new Git repository to work with a Subversion repository.

-s, --stdlayout
    Assume standard Subversion repository layout (trunk, branches, tags).

-T
    Specify the trunk path in the Subversion repository.

-b
    Specify the branches path in the Subversion repository.

-t
    Specify the tags path in the Subversion repository.

-r
    Specify the starting Subversion revision to fetch.

--prefix
    Specify a prefix for Subversion branch and tag names in Git.

--authors-file
    Specify a file to map Subversion usernames to Git authors.

DESCRIPTION

The git-svn command provides a bidirectional bridge between a Git repository and a Subversion repository. It allows you to use Git locally for branching, merging, and other version control operations, while still being able to interact with a remote Subversion repository as if you were using a standard Subversion client. This is particularly useful for projects that are hosted on Subversion but you prefer the features and flexibility of Git.

git-svn fetches Subversion revisions into Git commits, and allows you to push local Git commits back to the Subversion repository. It supports various workflows, including tracking a single branch, tracking multiple branches, and even tracking the entire Subversion repository. However, due to the fundamental differences between Git and Subversion, some Git operations (like rebasing public branches) may cause problems when interacting with Subversion.

Using git-svn requires some understanding of both Git and Subversion concepts. It's important to understand the implications of the different options and commands to avoid data loss or corruption. It is useful for migrating projects from SVN to Git, and also for teams that have some developers preferring Git but need to keep the main project repository on SVN.

CAVEATS

Subversion and Git have fundamentally different version control models. Rebasing public branches that have been dcommitted can cause serious problems. Git operations that rewrite history can be problematic when interacting with Subversion. Not all Subversion features are supported by git-svn.

CONFIGURATION

git-svn relies on several configuration options stored in the Git configuration file. These options control aspects such as the Subversion repository URL, the layout of the repository (trunk, branches, tags), and the mapping of Subversion usernames to Git authors. It is crucial to properly configure these options before using git-svn to ensure that the command operates correctly.

LIMITATIONS

git-svn does not support all Subversion features. Some complex features, such as property changes, may not be handled correctly. Also, because Git allows more freedom in rewriting history, operations such as rebasing or amending commits that have already been dcommitted to the Subversion repository should be avoided, as they can lead to inconsistencies and data loss.

HISTORY

git-svn was developed as part of the Git project to enable interaction with Subversion repositories. It has been widely used for migrating projects from Subversion to Git and for allowing developers to use Git locally while still collaborating with teams using Subversion. It's continued to be actively maintained and improved over the years, although its usage has decreased as more projects have migrated directly to Git.

SEE ALSO

git(1), svn(1)

Copied to clipboard