VS2013 TFS branching and merging

Question

I am using VS2013 TFS, my scenario is

1'st version of code checked in TFS and released. (Local Path is C:\Development\DEV )

2'nd version coding started and not completed.

Now client is asking issue fix on top of first version ? how to do that ?

The same issue fix should be included in 2nd version also. how to do?

Answer 1

Assuming you have no branches yet, it goes something like this:

• Get History on your main (v2) branch and work out the changeset or date/time at which you originally built v1.

• Right click your main branch (v2) and create a new branch (for v1). Choose "from a changeset" or "from a date/time" and enter the information from the first step to identify where (or rather when) the branch should be taken from. Commit this branch. You mow have two separate independent branches, with the v1 branch using the historical code you had for the v1 release, and your main branch still containing v2.

• Now you can fix the issue, in either branch. You will need to use the Source Control explorer to map both the branches into separate folders your PC so that you can work on them. (If your source code is not relocatable then you will have to switch between the branches by remapping them to the same location. This can be confusing but not too difficult if you do things carefully and make sure you get a clean copy of a branch before you start working on it. The pain of this is a good way of learning to make your code relocatable the next time :-)

• Now you need to replicate the fix in the other branch. If the branches are quite different you may find it easier to just write the fix a second time in the other branch, or you can right-click on the fixed branch and Merge into the second branch. TFS will do as much as it can for you but you will then need to resolve any merge conflicts to apply the changes you made for your fix to the second branch without breaking anything. (This can be quite tricky, so take care, and if you are unsure remember that you can undo your changes and re-start the merge at any time)

• Once you have finished the fix and tested your merged code locally, diff it once more against the previous/workspace version to be sure that you can's see anything you might have screwed up in the merge, and then check it in.

• Finally, if your release needs to be built by your build server, then you will need to point your build system at the v1 branch to get it to build the (fixed) v1 version for a new release (for a once-off build you just have to redirect your source control mappings for the v1 branch so that the build server gets from v1 instead of v2 when it 'Gets' the source code from source control, and when you are finished, remap the source back to the v2 branch)

As long as you think through each step and take care, it's fairly straight forward. But if you have never done it before, I suggest you work through each of the steps above and do some searches to learn more about how to branch, how to map source control folders, and how to merge.

Answer 2

Branching and merging is a complex topic and there are many patterns that you could follow. Without knowing more about your requirements it's impossible to give you good advice. You need to consider things like: How many clients consume the code. Is this for a shrink wrap application with multiple versions available concurrently or a production system where there is only 1 version "live" at one time. You'll also need to take in to account how you test your code (environments etc) and what kind of build process and deployment process you have.

The best advice I can give you without more information is to read the ALM Rangers guidance on TFS version control. Then come back with more specific questions. Also, keep it simple, don't over think it or you'll get in to a mess.