Version control is great stuff, and being able to combine different version control mechanisms is even better. Subversion is a very popular version control system and a lot of repositories (public or otherwise) use Subversion to manage files. Git is another popular one, but what happens if you are working on a project where Subversion is used but Git is your preferred version control system?

With the git-svn plugin, you can have the best of both worlds. You can convert a Subversion repository to Git, use Git tools, then push the changes back to Subversion.

To begin, you will need the git-svn plugin installed. Most likely, if your distribution of choice provides Git, it will also provide git-svn. On Fedora, install it using:

# yum install git-svn

Then use git-svn to check out your Subversion repository into Git format:

% mkdir -p ~/git/code
$ cd ~/git/code
% git svn init
Initialized empty Git repository in /home/user/git/code/.git/
% git svn fetch
This may take a while on large repositories
r267 = 079b7c1cff49187d1aabc4b16f316102088fdc0d (refs/remotes/git-svn)
W: +empty_dir: trunk
r268 = 3f1944530a092c811c55720bd9322b8c150a535b (refs/remotes/git-svn)
r351 = e2af3c12e5ed174d23ffc5917f03a6136f8ebb6b (refs/remotes/git-svn)
Checked out HEAD: r351

At this point, the Subversion repository located at has now been checked out in Git format. On individual files and directories, you can use the git log command as you would the svn log command in order to get history information on the item in question. With git, you will also see the Subversion commit that corresponds to the log entry, for instance:

commit 23f705cd87e1e9c6dd841ca88a14d808e0c4292a
Author: user@HOST.COM <user@HOST.COM@7a5473d1-2304-0410-9229-96f37a904fa4>
Date:   Sat Mar 20 18:25:38 2010 +0000
    correct logic on the buildrequires extractor, add stats on BuildRequires to showdbstats output
    git-svn-id: 7a5473d1-2304-0410-9229-96f37a904fa4

With the above, you can see that user@HOST.COM did the commit, see the log message, and the Subversion revision (r350).

To work with these files, make changes as normal. git diff works like svn diff does, to see the changes made. To commit changes, use git commit like you would use svn:

% git commit -m "some minor change" file
[master 2454be1] some minor change
 1 files changed, 2 insertions(+), 0 deletions(-)

To update your local copy from Subversion, instead of using svn update use git svn rebase. This will merge in any changes found in the Subversion repository.

When committing files using git commit, you are committing your changes to the Git repository. None of these changes are pushed to the Subversion repository until you specifically tell Git to do so. This is done with the git svn dcommit command, which then takes each commit made to Git and pushes them to Subversion as individual commits, which will retain all of your history and log comments:

% git svn dcommit
Committing to ...
       M      trunk/rqp
Committed r352
       M      trunk/rqp
r352 = 0557314a580c4390ff646380baa3aa33d1f6a5cd (refs/remotes/git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn
Unstaged changes after reset:
M      trunk/rqp
       M      trunk/rqp
Committed r353
       M      trunk/rqp
r353 = 249e97283ad28126bf84ccaffb32873e12d15b7b (refs/remotes/git-svn)
No changes between current HEAD and refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn

Now, if you were to look at the changed file(s) in Subversion (via another Subversion working copy or something like ViewVC), you will see the individual commits. Above, there were two changes made to the trunk/rqp file, each committed locally to Git. The “dcommit” command pushed those changes as individual commits to the Subversion repository. In this way you can do all local development with Git and when you have something you want to commit to the Subversion repository, you can push all of the relevant changes at once, retaining each separate commit.

Using the git-svn plugin makes it extremely easy to use Git locally with a remote Subversion repository. If you are in a project or organization that, for whatever reason, does not want to convert to Git, you can continue to work with that Subversion repository, without the restriction of using Subversion yourself.

Get the PDF version of this tip here.