JPz'log Coin Coin and Plop da Plop

Subversion + Git: when to choose one or the other?

You may have read from my recent posts that I have started to play with Git in conjunction with Subversion for working on IzPack.

Having a distributed SCM tool (here Git) that is able to work with a central repository (here SVN) is a huge advantage as it gives you more flexibility workflow-wise. Think branches, commit as you go, interact with non-commiters, etc.

I am however no fanboy: I still see value in Subversion and its centralized model. Much like I advocate polyglot programming, I advocate polyglot SCM If you are not convinced, try something like Mercurial for yourself: it has many merits such as fitting the requirements of a large majority of projects, or being way easier to use than Git.

After a few weeks of practice, I have now my mind clear on which use-cases fit better than others for Git or Subversion. This is biased to the way I work on IzPack, but I suppose that this applies well to most other projects.

• Create stable release branches and tags.
• Merge changes from a stable branch back to the trunk.
• Apply a patch that someone attached to a JIRA issue and that won't need rework.

• Create new features: work on a topic branch, commit often, keep synchronized with SVN and merge back to it when no more polishing is needed.
• Interact with external contributors. They can just clone from SVN, or clone my Git branch that I keep synchronized with SVN.
• Do some work offline. The "work offline" is certainly over-exaggerated by distributed SCM proponents, but there are times where it actually happens.
• Work on many things at the same time, Git branches and stash-ing really help.

Do you have similar feelings with both tools used in a project?

Related posts:

1. Howto: fork a Subversion project with Git
2. Working on IzPack with Git and Subversion
3. Making a stable release from a Subversion trunk… with Git
4. Start in Git, push to Subversion then work with git-svn
5. IzPack Git repositories on GitHub