Sep 1, 2011 at 4:51 PM
Edited Sep 1, 2011 at 4:52 PM
Thanks for the quick reply, Bill. I forgot to mention that we're evaluating TFS 2010. MKS can be quite clunky.
To answer your questions, MKS does not have automated build support (or if it does, we aren't using it). Code is built on the developer's machine and the binaries are stored with the source. Not the best solution, but our software is all internal so it works
for us. Most of our software uses a simple client-server architecture, so it's a simple switch of a setting to connect to our test database or the production database.
MKS labels are mutable, but checkpoints are not. Labels happen at a file level, while checkpoints happen at the project level. It is simple to go into the project history and choose a checkpoint to look at. If changes are needed, a branch can be created
from this checkpoint, changes made, and then the changes merged back into the trunk/main.
You say no check-ins happen in the main branch. So bug fixes for bugs found in the main branch would happen in the dev branch and then it would be merged back to the Main branch for testing?
I understand the Standard plan inserts a Hotfix/SP branch to handle addressing problems in the Release branches, which would keep the Release branch read-only. This would probably better duplicate the MKS checkpoint functionality.
To make sure I'm understanding things, this is what the branches would look like if we labeled all merges and check-ins.
Dev -> checkin---checkin---1.0 sent to main---bugs fixed, checkin---1.0.1 sent to main---checkin---checkin---1.0.2 merged with 1.1 work>
Main ->1.0---tested, bugs found, sent back to dev---1.0.1---no bugs, sent to release---1.0.2---1.0.2 sent to dev--->
Release -> 1.0.1---bugs found---bugs fixed, checkin---tested, good---1.0.2 release, sent to main--->