$ mv requester sampler
# svn agony after renaming a directory
$ svn st
?       sampler
!       requester
!       requester.rb
A       sampler.rb

The tool to use when using Git with Subversion is, of course, git svn.

git svn works very well as long as you remember that Subversion is not Git. It does not handle merging well, and it will bite you if you don't respect that. So what does this actually mean? It means:

Always keep the Git master in sync with Subversion

To do this you have two commands you can use.

# Rebases the commits from the upstream Subversion server with your local master.
$ git svn rebase

You should only git svn rebase in your Git master, and you should ALWAYS do it before you git svn dcommit anything to the subversion repository. git svn rebase keeps the upstream subversion in sync with your local master by pulling down the changes, kind of like svn update.

# Commits the changes you have in your local master to the upstream Subversion server.
$ git svn dcommit

When you have changes ready to commit, you commit them to subversion with git svn dcommit. You should ALWAYS git svn rebase before you do the update, or it will fail.

That's it! As long as you follow these two simple rules, your life with git svn will be easy. If you forget to follow them, you will be bitten. When you get bitten, the cool thing about Git is that even if you screw up, it is always possible to sort it out.

It that was all there was to it, there would be no reason to use Git instead of Subversion. Git really shines when it comes to branching and merging. You may create as many local branches as you like with git branch branch_name or git checkout -b branch_name. You can hack around in these local branches as much as you want and merge them together. But, before you merge them into the master branch, you must rebase with master! Not merge, rebase! Rebase means replay the commits on top of the named branch. It creates new commits, the same content, but with a different SHA-1.

# Example session

(master)$ git svn rebase
(master)$ git checkout -b dev
hack, hack, hack, ...
(dev)$ git commit -am 'Commit the changes' 

(dev)$ git checkout master
(master)$ git checkout -b bugfix
hack, hack, hack, ..., done

(bugfix)$ git checkout master
(master)$ git svn rebase
(master)$ git checkout bugfix
$ git rebase master
(bugfix)$ git checkout master
(master)$ git merge --ff bugfix # --ff only fast-forwards, merges that don't need to merge. 
(master)$ git svn dcommit
(master)$ git branch -D bugfix # delete the branch it is not needed anymore

(master)$ git checkout dev
hack, hack, hack, ..., done

(dev)$ git checkout master
(master)$ git svn rebase
(master)$ git checkout dev
(dev)$ git rebase master
(dev)$ git checkout master
(master)$ git merge --ff dev # --ff only fast-forwards, merges that don't need to merge.
(master)$ git svn dcommit

Another thing to be aware of is that git svn dcommit creates an extra commit, so even if you haven't changed anything in the master you need to rebase the local branch with the master. This is only needed if you don't delete the branches after you are done with a commit.

In the example above, I ended with a git svn dcommit and I didn't remove the dev branch.

(master)$ git svn dcommit # from above
(master)$ git co dev
(dev)$ git rebase master # rebases the extra commit created by git svn dcommit

If you forget to rebase or something else happens that hinders a clean merge into the master. You can always back out of it with git reset --hard.

(master)$ git svn dcommit
... failed miserably, because I failed to git svn rebase, bollocks!
(aa..88dd|MERGING)$ git reset --hard
(master)$ git svn rebase
(master)$ git svn dcommit # Nice and clean commit

To get started you need to clone a subversion repository.

$ git svn clone http://svn.example.com/project/trunk
$ cd trunk
(master)$ git ...

Now, is a good time to start using Git. Get yourself anything by Scott Chacon, such as the book or the screencasts.

However, if your project is set up to use the Maven automatic build versioning as provided by the buildnumber-maven-plugin you will run into problems if it is set to get the build numbers from the Subversion revision number. Since your local checkout is against Git, and not Subversion, the build will fail since the Subversion commands won't work.
One solution for this could be to alter the plugin configuration to get the build number from the date or something similar, but that's not always possible. You might have a build server setup that depends on the build number matching the revision number, and imposing such a change might break other functionality or processes.

Instead you can add an additional profile to the Maven POM which will only be triggered in the absence of a .svn directory (i.e. when not using Subversion). In this profile you can override the default configuration for the build number generator to instead use the date for build numbers. This means that your builds will have different build numbers from the integration builds, but at least it will compile on your git checkout.

The profile will look like this:

<profile>
  <!--
  This profile is here for triggering when another scm than svn is
  used (for example git). Instead of getting the version build number
  from svn we will use the build date and the user name.
  -->
  <id>buildnumber-git</id>
  <activation>
    <file>
      <missing>.svn</missing>
    </file>
  </activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>buildnumber-maven-plugin</artifactId>
        <executions>
          <execution>
            <phase>generate-resources</phase>
            <goals>
              <goal>create</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <doCheck>false</doCheck>
          <doUpdate>false</doUpdate>
          <format>{0,date,yyyy-MM-dd_HH-mm}_{1}</format>
          <items>
            <item>timestamp</item>
            <item>${user.name}</item>
          </items>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

This way Subversion and Git users can live happily together in the same project.

I unpack it in "C:\Program Files\Subversion". To get the commands to work you have to add the bin to your path. In my case I add "C:\Program Files\Subversion\svn-win32-1.5.6\bin" to the path. After this I open up a command window and do the following:

mkdir subversionRepository
cd subversionRepository
svnadmin create project1

Now, in order to make Subversion work in Eclipse I add http://subclipse.tigris.org/update_1.6.x to my update sites. After downloading this I restart my Eclipse and go to Window -> Show View ->Other->SVN -> SVN Repositories.
I right click in the opened view and create a new repository location. Instead of writing a http adress in the URL window I now type "file:///C:/subversionRepository/project1". Notice the three forward slashes after "file:".

I now have an empty repository that I want to put my project into so I right click on the repository and add a new remote folder that I call trunk. Right clicking on the trunk I can now import my project by importing the folder that contains the .project file. I hit F5 to refresh the view and can see that the trunk is now filled with my first version of my project.

But I also have to associate the repository version with Eclipse, so now I right click in the Package Explorer and choose Import -> SVN -> Checkout Projects from SVN. I pick my previously created repository, click next, mark the trunk and then click finish. I get a question if I want to overwrite my previously created project with the same name and say ok. I won't need that now that I got a versioning system!

I can now finally continue my studies of the tool I was looking into.

I had seen somewhere that you could get the 403 error if you were using SSL (which I was) and the Sourceforge server svn.sourceforge.net. The correct server is the PROJECTNAME.svn.sourceforge.net, where PROJECTNAME in my case was springframework. So the correct URL to use is https://springframework.svn.sourceforge.net/svnroot/springframework/. This meant changing the checkout URL, which Subversion can do on an already checked-out working copy, using the switch command. Cool. When I tried this, it failed because it couldn't find the new server. The problem was that the DNS servers I was using at some point didn't find this server, and probably cached this negative hit. Eventually I found a DNS that could locate this server and performed the switch. Things have been working much better since.

Using the incorrect server, which most likely is a proxy server of some sort, could possibly have resulted in different physical servers being used for different requests during the Subversion transaction. It's not allowed to perform a svn copy operation between repositories. You'll get a 403 if you try it. Perhaps that rule applied to my situation as well.