Git-SVN

git-svn allows you to work with Git on your local machine and Subversion on the remote server. This means that while using Git's advantages on the client side, you're still able to push changes to a remote Subversion server.

Note: If you have no other option but to use Subversion on the server side, git-svn is a great way to still use Git on the client. However, be aware that git-svn nevertheless remains a workaround. If at all possible you should definitely prefer to work with Git on the client side and on the server.

Please also see our FAQ section about git-svn if you experience any problems.

Cloning a Subversion Repository

To clone a Subversion repository, open the Repositories view and choose "Clone Remote SVN Repository..." from the "+" button menu on the bottom of the sidebar.

In the following dialog, provide the repository's URL (along with any credentials if authentication is required). If the directory layout of your SVN repository doesn't follow the SVN default ("trunk", "branches", and "tags" directories), you need to provide additional path information on where your main branch, branches, and tags reside. Otherwise, git-svn cannot create remote branches for them.

Please note that you might need to be patient: Cloning a large SVN repository can take some time as git-svn needs to import all revisions.

Making Changes

Here is the one thing you should be aware of if you don't want to annoy SVN users on the other side of the repository: if you're working with branches in Git (which is probably the reason why you have chosen to work with git-svn), you have to either squash-merge your changes back to the original branch or rebase with the original branch before merging. If you squash-merge, you will lose individual commits while rebasing will preserve them.

Let's take a look at an example: You create a new branch 'develop' from 'master' and add two files FOO and BAR in two separate commits. If you merge them back and a merge commit is created, only the merge commit itself will be visible to other SVN (or git-svn) users.

The below image shows the history as it appears in the Git repository...

...while this image shows the SVN repository...

...after both repositories have been synchronized. As you can see, all changes will be there, but the individual commit information is lost as SVN will never receive and therefore not know about the commits of the other branch.

Synchronizing with an SVN Remote

Synchronizing with SVN remotes pretty much works the same as with a Git remote: you can fetch, pull and push changes.

The only twist is that each local branch is tied to the SVN remote branch it was derived from. E.g. if your local branch 'master' was created from the SVN remote branch 'trunk', they will be tied forever by the git-svn-id line that every local git-svn commit carries in its message. This git-svn-id line contains an SVN repository identifier and the full SVN URL along with the SVN revision it corresponds to. It's probably a good idea to set up tracking between your local Git branch and your SVN branch so you will receive information about commits ahead and behind.

When you create new commits, they will be missing the git-svn-id. This is because they're not yet associated with an SVN revision as they have not yet been pushed. Once you successfully push them to the SVN repository, each commit you have made will be rewritten locally with the git-svn-id.

Another thing worth noting is that git-svn will always rebase your local branch onto new revisions from the SVN repository (e.g. pull --rebase). This is done to preserve SVN's linear revision history, which rebase is all about. If you're not familiar with rebase, it may be a good time to dive into this topic first.

Just like in Git, it's a good idea to check for changes and pull them in before pushing to an SVN remote. git-svn will automatically update your current HEAD with the latest revisions if you haven't already done so. However, if there are conflicts while rebasing, push will be aborted and you will have to resolve the conflicts and push again - so it's probably more convenient to pull first.

SVN Branch Tracking

Since your local SVN branches are tied to a specific SVN remote branch, Tower considers this information as valid tracking information. Using the "Push HEAD" button in Tower will then offer you to push the current HEAD branch to its tracked SVN remote branch.

SVN Ignores

With git-svn, the information about ignored files will be managed on the SVN remote. You can fetch this information from the SVN remote repository and add it to your local ignores. In Tower, right-click on the remote in the sidebar and select "Add SVN Ignores to Exclude File Patterns". After the ignore patterns have been fetched from the SVN remote, they will be added to your .git/info/excludes file.

Author Names

Subversion identifies users only by their username, not by their full name and email address as in Git. Although new commits in Git will have your full Git user information, once you have published them to the SVN remote, this information will be replaced by the user information from SVN.

There are ways in git-svn to set up a mapping from SVN usernames to Git users, but none of these approaches (or any other) offer a viable solution to gain fully mapped author information (and that is why Tower does not provide support for configuration of author name mapping).

Pruning Obsolete SVN Remote Branches

Pruning obsolete SVN remote branches will not work in git-svn. This means you might find remote branches on your SVN remote that do not exist on the SVN remote any longer.
git-svn preserves a reference to any remote branch ever created on an SVN remote. If a branch was deleted and then later re-created with the same name, you may get strange branch names like 'develop@5'. If a branch with the same name already existed (and therefore exists in git-svn), git-svn will append the revision to its name to distinguish them.

Deleting Branches or Tags on the Remote SVN Repository

git-svn doesn't support deleting branches or tags on the remote SVN repository. You can create them - but you cannot delete them.

Changing an SVN Repository URL

Relocating the SVN repository URL is not supported by git-svn. The reason for this is that git-svn stores the SVN repository URL in each commit and relies on this information. If you wanted to change the SVN repository URL you would have to rewrite the entire commit history to change the URL in each commit. You would also have to completely rebuild the SVN metadata. If you don't have any pending commits, just re-cloning the SVN repository is probably much more comfortable.

If you do have pending commits and want to keep your SVN clone, an option is to add a second SVN remote repository with the new URL and then migrate your changes from the old branches to the new ones by stashing or cherry-picking single changes.