All posts for the month May, 2013

Working in a fast paced but ultimately easily managed way, sometimes these seem contradictory. Working with Git and Subversion you can have your cake and eat it. Github, and similar, allow access you repository using either, but what about those working in environments where Subversion is mandated for projects, but want to use Git for a more agile, more frequent, more personal checkin pattern? 

The Promised Land

There does not seem to be much debate in the software community these days that Git is taking the version control world by storm. This is happening for many sound reasons. Which is great, unless you work in a company where Subversion/SVN is the order of the day.


Choice of version control tool is very much like choice of editor – everyone knows which one is best – except they do not agree with one another. Some people even try to impose personal tools, rather than adopt a policy of “use what makes you happy”. Those people are obviously bananas.

Subversion isn’t really suitable for “Personal Agile”.

Git and Personal Agile

“Personal Agile, what do you mean by that?” I hear you ask. Well…
1) Drive the code forward
2) If it turns out good check it in
3) If it turns out bad role back
4) If it is really not going to plan roll further back
4) Repeat until you get the code where you want to go

This is a pretty aggressive way of working, and in order for it to work partially working/half-baked/frankly embarrassing efforts get recorded along the way; it has to be quick; it has to avoid impacting upon other people and branch’n’merge has to be right in there. Git lets you do all that. SVN does not.

Subversion – it’s in with the Bricks

Many companies have a significant history using Subversion. SVN is perfectly fine for control and good for controlling projects.  People with an SCCS, DSEE, RCS, CVS, ClearCase, SourceSafe background find it is easy to follow.

Version control is however a team collaboration tool so there has to be agreement, respecting what each of these tools can offer and the momentum of history.

One day when the Subversion fans have all retired, the world will see the light and move to Git, but until then… let me tell you a secret…the choice between SVN and Git is a false one because they can co-exist.

Living sided by Side

One thing that many people don’t appreciate is that you can run Git and SVN on the same directory at the same time. This has been eased by the latest version of SVN client adopting the Git convention of a single .svn/.git directory at the top of the tree rather than throughout) which makes things a good deal tidier.

Provided that .git and .svn are listed in the .ignore files it works just peachy – so you can run your own private Git with local “commit/push to Git as often as you like”/rollback policy; and commit/update with SVN only at suitable landmarks e.g. each bugfix / feature introduction.

Tortoise Git and Tortoise SVN work fine in this configuration (with the exception of the icons, which is sugar anyway).

The usual rule of thumb of not leaving it out of SVN too long still applies.

# Ignored files
# Placed in the public domain by Springsmith Ltd in 2013
# Note: the first few lines are commented out as they concern
# deliverable executables and without a Maven repository you
# probably want to tie these in with the code that generated them.
# *.exe
# *.jar
# *.dll
# *.apk