R.S.N

Hi¡­.

I have a question about Branching and Merging¡­

In the source control we have two lines, one of them for the main branch and the second one for the versions¡­.it look likes this

Main

|

Version1

| |

| Version 1.1

Version2

we use (branch per release) strategy, so at the beginning of each iteration, we create a branch (version 1, for example) from the Main and we merge this branch into the Main at the end of iteration..

After that, we create a new branch (version 2, for example) from the Main for the second iteration and so on¡­

While we are working on the second branch we received few change requests from the our customer ¡­ we went back to (version 1) branch, and created a new branch (version 1.1) from it to do the requested changes on this new branch ¡­.actually we didn¡¯t work on (version2) branch because the developers worked on new major changes while the customer requested few changes¡­

I have the following questions:

  • To apply the new changes, we created a new branch (version 1.1) from the whole solution and we worked on just four files to apply those changes ¡­Can I create a branch that has only those files If yes, how can I test those files after we change them Each file of them uses 90% of the whole solution¡­

  • Currently, we are working on version2 and we applied other changes on version 1.1 ¡­..how can I merge the version 1.1 changes into version 2 The same files were changed in version 1.1 and in version 2..

  • In general, Is there a better way to do that What is the best practice say

Please guide me ¡­ Thanks in advance for any help



Re: Team Foundation Server - Version Control Question about Branching/Merging

Richard Berg MSFT

I would not suggest creating a branch with just 4 files. Life is much easier if all of your branches can be built & tested independently.

You will have to do a baseless merge from 1.1 to 2.0, or make the changes by hand. There is no way to do a "real" merge without going thru 1.0 & Main, unfortunately.

If you're going to do work in 1.1 that will eventually become part of 2.0, you should consider branching 1.1 from Main instead of from 1.0. That way you don't have to do any baseless / manual merging. To me, creating a child branch from 1.0 -> 1.1 indicates "we will never do reverse integrations, only forward."





Re: Team Foundation Server - Version Control Question about Branching/Merging

R.S.N

Thanks so much Richard for your reply¡­.

But I have the following questions:

1- Some people recommend ¡°branching the files that we need to change, not the whole project¡±¡­ do you have idea how can they build & test their solution

2- Suppose that I created the (v1.1) branch from the (main) branch, and I did different changes in v1.1 & v2¡­ to apply v1.1 changes to v2, I will need to merge v1.1 into the main branch.. Then merge the main branch into v2.

In this case, how is the merge going on How it will work

Will it keep v2 changes and apply v1.1 changes to it or what

Thanks so much Richard¡­ and I¡¯m waiting your reply¡­





Re: Team Foundation Server - Version Control Question about Branching/Merging

Richard Berg MSFT

  1. Either they are doing a lot of tedious workarounds with workspace mappings, or they are using a different product. Some other source control systems support "sparse branching" or "lazy branching". We don't. We feel like our normal branch operation is cheap enough (resource-wise) & fast enough to use all the time.
  2. When you did the merge from Main -> v2, there would be conflicts. Some of them can be resolved automatically; some of them would probably need to be resolved manually in a 3-way merge tool.




Re: Team Foundation Server - Version Control Question about Branching/Merging

Eddie Garcia

I would suggest that you don't branch at all. It is all 1.0 based work so Label your 1.0 tree at the tip(or the point you released it) and do the work in that tree. Once it is tested, and is ready to ship to the customer you can merge that back to main and then down to 2.0 again.

2 good rules to follow when branching:

  • Branch only when necessary.
  • Branch late.