Source control matters

Recently I've been running problems when maintaining multiple concurrent branches or versions of software with subversion. Somehow the merging is a challenge since branches are not "real" branches but more or less just copies of folders. Also switching between branches in web developing can be more pain than gain.

As I started to play with MidCOM 3 I had to introduce myself to the git. The first impression was quite bad since we used repo.repo.or.cz as our storage. My bad impression came mainly because of the commit problems. But now as I've studied git some more it seems more and more the tool that I would like to adapt to every software product I'm dealing with.

Bergie blogged about the new idea where the "trunk" is stable and all new features, bugfixes, versions etc are made as new branches. First I felt a bit sceptical about this but now when I've studied and tried it a bit more I'm sold.

But lets take a look how does this work in your workgroup environtment? First of all instead of working in multiple branches things will not break up unexpected when you update. With one checkout morning checkout too often breaks things up. With branching you can leave it broken if it's your "personal" branch.

Git gives good and fast possibilities for branching. Another great advantage is that you can easily hop into your collegue's branch just by "git checkout another_branch". Merging conventions may need a bit more studying and especially branch branching. These are in my opinion project or organization related conventions. 

Git could make a great improvement to software version controlling when compared to cvs or subversion. It however will need some thinking and adaptation to projects source control conventions if active branching and mergin has not been a used before.