Clever Geek Handbook

Direct and reverse integration from one solution to another in TFS

I've just migrated my code from Perforce to TFS. Everything looks good, but there is a problem, which is going back and forth from one solution to another. This is a show stopper for me.

There are two different solutions in both solutions and the two projects are shared but have different copies separately. Thus, Forward Integration will unify the entire application from sol1 to sol2, resolving conflicts in common projects. After it's resolved, merge the code back into solution 1 (reverse integration). The point to be understood is that only general projects need to be combined and anything else can be omitted.

Can I do a similar setup in TFS?

+3


source to share


2 answers


I got the exact solution, which is more or less the first Jesse option you provided. Basically, we need to create shared projects for one of the solutions and then split them into the other solution. At a later point in time, we can merge them from solution 1 through 2 to check the merged files in solution 2, and then merge into the 2 by 1 solution and check the merged files in solution 1.



0


source


Yes, this scenario is possible in TFVC, but not very common. You have several options:

  • Create a branch root at the solution level and merge files from one solution into solution two. As part of the merge operation, we exclude files that you do not want to merge. Later you can merge back and forth at the folder level.

  • Create a link to a folder, but don't make folders into branch roots. This allows you to merge one folder with another folder at any time, but does not show those folders as branches per se

  • Create a branch root at each project level and merge each project separately. This has several disadvantages (since in this case you cannot fork the whole solution, since branch roots cannot be nested).



Or, you can approach the problem differently:

  • Create a separate solution that contains shared code and uses package management ( publishing NuGet packages ) to share dependencies between both solutions (essentially creating 3 solutions).

  • Use workspace mappings to keep shared code in one place in source control and to map your code in different locations on disk. You can use directives or compiler configuration or different abstractions (interfaces, abstract classes) in your code to compile sources to different versions.

+1


source






More articles:


All Articles