3

I have a Team Project in TFS where tasks are submitted daily. I would like to work on each task independently and then merge it into the main line after testing.

Currently there is a MAIN branch and a DEV branch which is a child of MAIN. Changes are worked on in the DEV branch and then merged into MAIN when they are ready. This is done via a "cherry-pick" merge. I've been reading everywhere that cherry-pick merges are bad and you should avoid them whenever possible.

I am having trouble wrapping my head around branching and merging in TFS and was wondering if anyone had any suggestions on how to achieve this goal in TFS without having to do cherry pick merges.

Any help is appreciated.

If I left out any key information please leave a comment and I will edit my post.

thiag0
  • 2,199
  • 5
  • 31
  • 51

2 Answers2

3

I think this Codeplex documentation will be a big help:

http://tfsbranchingguideiii.codeplex.com/

The download has several PDFs that outline different scenarios and strategies and give excellent Q&A on different approaches.

The key for your scenario would be to merge all changes up to a specified version from Dev to Main. Run all tests each time code is checked into Dev (and developers get the latest Dev code, then run all tests before checking in). Ideally, if the build in the Dev branch is successful after Dev checkin, merging into Main would be a good idea. Merge frequently from Dev to Main, and run all the tests in Main after each checkin.

So even though developers work individually on specific pieces, once they check into the Dev branch they are essentially saying "this code is ready to integrate." And when merging from Dev to Main, you no longer deal with specific pieces--you merge the whole enchilada. If Developers need source control for work-in-process code, they should use TFS shelvesets and wait to check into Dev until they are "done."

Shawn
  • 8,374
  • 5
  • 37
  • 60
  • Currently, we check-in daily changes into DEV. Once the change is ready to be released into production, it is merged into MAIN. The issue I'm facing is that sometimes a change that was checked-in prior to a new change is not yet ready to go into production. This prevents me from merging to latest version and forces me to do a cherry pick merge so I can choose only the changes that are ready to be released. – thiag0 Apr 19 '11 at 17:37
  • Then options include: 1) not check in code until it is ready for production and target all changes for the same production release, or 2) alter your branching strategy so that you have two "in-process" branches--one for the first release, and one for the second release--that don't merge into the Main trunk until they are ready to go to production. The latter sounds like the approach that would fit best for your situation. – Shawn Apr 20 '11 at 00:07
  • I can see both ways as a solution in this situation because it requires weekly releases. Method 1 can be accomplished by utilizing shelvesets to store the changes that are not ready on the tfs server. Method 2 can be achieved by creating one branch for changes that will most likely be completed before the next release and the other branch for changes that take longer to complete. Due to the cost of creating branches I think your first suggestion will work out better. Thanks! – thiag0 Apr 20 '11 at 02:34
2

You might find Timpani Software's MergeMagician tool interesting. It is a branch management and automated merging solution that works with TFS (and also Subversion). You create publish/subscribe relationships between branches, and then the server automates the merges.

MM can be used to implement all of that patterns discussed in the TFS Branching Guide that Shawn mentioned.

FYI, it is a commercial tool. I don't know of any open source tools that do anything like this that work with TFS.

Check it out at http://www.timpanisoftware.com. There's a good overview video on the home page.

user292103
  • 31
  • 2