git-svn

Clone an SVN repository

Clone an SVN repository starting at a given revision number
Update local clone from the remote SVN repository
Fetch updates from the remote SVN repository without changing the Git HEAD
Commit back to the SVN repository

git svn <command> [<options>] [<arguments>]

Common commands include:
init: Initializes a new or existing Git repository to track a Subversion repository.
clone: Initializes and fetches the entire history from a Subversion repository.
fetch: Fetches new commits from the tracked Subversion repository.
rebase: Updates your local Git branch with changes from the Subversion repository, rewriting your local history.
dcommit: Pushes your Git commits to the Subversion repository.

--prefix=
    Specifies a prefix for tracking Subversion branches and tags, for example, svn/. This determines how SVN paths appear in your Git remote branches.

-r
    For clone or fetch, specifies a specific revision or revision range to fetch. For example, -r 100:HEAD.

--no-metadata
    Skips adding Git-svn metadata (e.g., git-svn-id) to commit messages. Generally not recommended if you intend to dcommit back to SVN.

--authors-file=
    Specifies a file mapping Subversion authors to Git authors (svn_username = Git User ), useful for consistent commit attribution.

-s
    Assumes the standard Subversion repository layout (trunk, branches, tags). Alias for --stdlayout.

-T
    Specifies the path to the trunk in the SVN repository if not using the standard layout.

-b
    Specifies the path to the branches in the SVN repository if not using the standard layout.

-t
    Specifies the path to the tags in the SVN repository if not using the standard layout.

--dry-run
    For dcommit, shows what would be committed to the Subversion repository without actually performing the commit.

-n
    Alias for --dry-run when used with the dcommit command.

--log-window=
    For fetch, specifies how many revisions to fetch in a single SVN transaction. Can improve performance for large fetches.

-l
    For clone, creates a local repository without a remote Git connection, only tracking the SVN remote. Alias for --local.

git-svn is a Git command that provides bidirectional operation between a Git repository and a Subversion repository. It allows developers who prefer using Git's powerful local branching, staging area, and advanced history management features to collaborate on projects primarily hosted in Subversion.

git-svn functions by maintaining a mapping between Git commits and SVN revisions, enabling users to fetch changes from an SVN repository into a local Git repository and to "dcommit" (push) Git commits back to SVN. This makes it a crucial tool for teams transitioning from SVN to Git or for individual developers working within an SVN-centric organization who wish to leverage Git's advantages locally. It tracks SVN branches and tags as Git remote branches, facilitating a relatively seamless workflow despite the underlying architectural differences between Git's Directed Acyclic Graph (DAG) history and SVN's linear history.

• History Mismatch: Git's Directed Acyclic Graph (DAG) for history is fundamentally different from SVN's linear history. This can lead to complexities; git svn rebase is often preferred over merging to keep history linear for SVN.
• Branching and Merging: While git-svn tracks SVN branches, Git's branching model is more flexible. Merging Git branches that contain non-linear history back to SVN can be problematic, often requiring squashing or careful rebasings.
• Performance: For very large Subversion repositories or deep histories, initial git svn clone and subsequent git svn fetch operations can be slow and resource-intensive due to the need to translate SVN revisions into Git commits.
• Tags: Git light-weight tags have no direct SVN equivalent. SVN tags are typically copies of branches, which git-svn treats as remote branches. Git annotated tags are more analogous to SVN's "tag" concept.
• Empty Directories: Git does not track empty directories, whereas SVN does. This can cause minor inconsistencies when dcommitting if empty directories are significant.
• Authentication: git-svn relies on the svn command-line client for authentication, which might require additional configuration for password caching or SSH keys.

• Cloning: Start with git svn clone <SVN_URL> <local_repo_name>. This creates a local Git repository and fetches all history from the SVN URL.
• Updating: To get the latest changes from SVN, use git svn rebase. This fetches new revisions and applies your local commits on top, maintaining a linear history.
• Committing to SVN: After making local Git commits, push them to SVN using git svn dcommit. This command converts your Git commits into SVN revisions and pushes them sequentially.
• Branching: SVN branches are tracked as Git remote branches (e.g., remotes/svn/branch_name). To work on an SVN branch, create a local Git branch from it: git checkout -b my_local_branch remotes/svn/branch_name.

Subversion tracks authors by username, while Git uses a "Name " format. For proper authorship in Git commits (and vice-versa), an authors-file can be used. This file maps SVN usernames to Git author strings, ensuring correct attribution when converting commits. Example: svn_username = Git User .

git-svn has been an integral part of the Git distribution almost since its inception. It was developed to address the practical need for Git users to interact with Subversion repositories, which were prevalent at the time of Git's rise. Its inclusion allowed developers to leverage Git's superior local workflow features (e.g., fast branching, staging area) without requiring their entire team or project to migrate from Subversion. Over the years, it has seen continuous development to improve performance, enhance compatibility with various SVN configurations, and refine its error handling. While the overall industry trend has shifted away from Subversion towards Git and other DVCS, git-svn remains a vital tool for organizations with legacy SVN repositories or in hybrid environments.

git(1), svn(1), git-rebase(1), git-log(1)