My new project uses branching in TFS. Every project to improve the product is done on a branch. This is correct use of TFS, since it is a Application Lifecycle Management tool. In this post I’ll describe how I merged back to the Main branch and created a new branch for the next project on the same product.
The source explorer shows 4 branches. One branch is the mother of the other branches, this is called Main. The other branches are named after the project. To see the hierarchy in Source Explorer select a branch and choose View Hierarchy in the context menu.
In the hierarchy view you can compare two branches by selecting both. Then choose Compare in the context menu. You’ll get a dialog with the source and target for the compare set to the branches.
Together with the history of both branches I noticed some potential issues.
- A file was added to Main after the branch was made. How will the merge process handle this?
- A file was edited in both branches after the branch was made. Which is the correct version?
I consulted the persons who performed the checkins. We looked into the files and decided what the result of the merge should be. During the merge process (select the branch to merge to Main) TFS had one conflict it could not resolve. This was the extra file (1) in the list of potential issues above. With merge changes in merge tool I included both changes into the project file. The rest was auto resolved and a clean build showed no issues. To make it really sure I checked the edited file (2) from the list of potential issues above. It was handled correctly.
After the merge process I made a new branch. TFS notified me that this is an administration only and couldn’t be rolled back. I clicked Yes.
Prepare for the worst and hope for the best
Benjamin Disraeli
TFS did most of the heavy lifting. My work was limited to one manual merge and a clean build. Now I’m ready to start the project with a shinny new branch.
