I know this is old but it's still the first thing that comes up in Google when you search for the infinite build issue in BuildMaster. The infinite builds are because applying a label is technically a check-in in DVCSs like Mercurial and Git. So when you apply the label BuildMaster sees a new check-in and starts a new build, which applies a new label, which creates a new check-in, ... I haven't found a good workaround yet.

Do you know if you are running the BuildMaster web application through the integrated web server, or if it's hosted by IIS? For the integrated web server, ensure that its service runs under Administrator as well. If you're using IIS, you'll have to verify that the app pool's identity is running as the Administrator account in addition to the BuildMaster service. Right now we are in the process of writing a knowledge base article that will give step-by-step instructions with regards to connecting to GitHub since that seems to be the most common hosted solution for our Git integration.

The Branch Action is designed for "tagging" builds (Subversion and CVS), and actually, it's been renamed in 3.2 and will only be displayed if you have one of those providers. You're definitely on the right track for labeling each build, but merging... it's not really something you can do on an automated basis because of conflicts. That said, if you do want to merge, you can simply call tf.exe merge.

We just released our TFS2012 extension - http://inedo.com/buildmaster/extensions/tfs2012

Yes, as long as BuildMaster supports (see http://inedo.com/buildmaster/integration) the source control provider. It is a best-practice to label your code with a release and build number combination such that it can be retrieved at any point in the future, and more specifically, if you are promoting your code to a further environment. You can set up your BuildMaster action to use the built-in variables %RELNO% and %BLDNO% to accomplish this.