Using a git frontend with a subversion backend Part 1

I find myself going back to a few unrelated articles about how to use git-svn because I keep forgetting the exact commands. Also not everybody is familiar with the concept of using subversion (svn) and git together.

Why should someone mix those two?

The answer is, like usual, not so simple.

• Maybe your corporate policies do not allow to use another source code management system (scm).

• You have existing infrastructure that you can not or do not want to change.

• You do not need the distributed features of git but like the command line tool because it is a little more closer to the metal than svn.

These are more or less the reasons why I want to use it that way. git brings some refreshing ideas to the command line but I do not need the distributed features that are often associated with it.
Also I find myself working on a regular basis with other developers who need to use Windows for development.
Windows support in git is not the best if it exists at all. svn on the other side is pretty good at it. Having the ability to support both platforms and maybe something else in the future is a good thing to have.

So what are the pros and cons of using either tech:
Subversion

• Longer around: This can be either a good or a bad thing but svn was already a big icebreaker for many companies to start moving away from cvs.

• Many companies have existing infrastructures and see no reason to move away from their investment

• Backups: This hit one of my mates once. A headcrash on his laptop with more than 40 local commits in git and no backup. "Stupid", you might say but it happens more than you think. git with all its possibilities to change a commit after you commited, keeps many developers from pushing there changes to a public viewable repository. "Maybe I forgot something and need to tweak it again", is an often heard excuse and discussed here in more detail.
  

• Path authorization: Some people want the ability to hide certain parts of a repository from others
  

• Apache integration: No need to run a special daemon to host a repository. Most sysadmins are familiar with apache and do not need to learn a new tool or setup new tools to monitor the new daemon.
  


• Platforms: Like I said before subversion supports many plattforms including windows.
  

Git

• The index: The possibility to have a staging station where you can "park" things you want to commit on a patch per file level is awesome.

• patch -i: Commiting only a certain part of an edited file was something I always emulated by using a graphical diff tool. In git this is support natively.

• rebase: Forget to check in a file ends up with a new commit in subversion that is not related to the initial one where you forget the file. In git it is possible to rearrange commits and "squash" them together into one.

• merge: Merging in git is easy. Merge is easy in subversion too now but it first started getting attention when git came around and showed how easy it could be done.

• stash: Stashing is the ability to take changes you have done to a local branch and copy them over to a newly created local branch.

• Offline commits: You do not need a working network connection to commit your changes.

• Http/git protocol: git over http is only one way. It does not allow to push changes back from your local repository to the public repository. If you want that you have to run the custom daemon and use the git protocol.
  

git's distributed features are great if you work on open source projects as it encourages forking the repository and generally more open development. In a more corporate environment you often do not needs these features and luckily git has git-svn which bridges both worlds.

The following articles will show you how I use git in a pure svn environment.