I’ve been a build master a number of times and built/configured automated build systems that have worked quite well. In those cases I mostly used SVN, Cruise control and a couple of other plugins. Being a Build Master is a tough job and unless you lay down the ground rules at the start of a project it will be hard to maintain source control discipline.
One of the most important rules is commit early and commit often, this way changes can be easily merged or retracted when needed. With both GIT and SVN Trunk, branching and tagging is essential to allow multiple streams of development for rapid release cycles. A strong test system is also required to allow for automated testing to pick up problems early with the build. I don’t believe in 100% coverage because of the usual budget constraints but if standard test best practice is follow your problems should be kept to a minimum.
Both Git and SVN are great source control tools but are both quite different in their implementation and challenges for the build master. SVN is more centralised and requires you to be able to connect to the server to do checkin’s and query the repo and logs. GIT is a self contained source control with the advantage that you can commit and query as much as you like offline. You then sync your source with each of the teams GIT repos or a central GIT repo which everyone syncs to.
The one you choose comes down to the type of team you have. If you have free thinking developers who have good initiative and are experienced with source control then GIT is the way to go. As a build master most of the issues with GIT is ensuring that the team merges regularly. If you have a team of developers who need a fair bit of oversight then SVN is a better way to go. Most of the issues with SVN is with people who don’t commit often enough and with SVN it’s easier to see who is checking in when and what so issues can be picked up early.