Configuration:
My team chose the TFS update migration method from 2010 to 2013: take backup copies of the DBMS of existing instances (using the TFSBackup tool), copy them to new servers, restore new SQL instances (using the TFSRestore tool) and install TFS in a new application / Build levels with the option "Refresh".
Further context:
I have VS 2010, 2012 and 2013 installed side by side on my workstation. At the same time, I usually do not use more than one flavor. And still, I use the same personal workspace / collation in all of them. And depending on which new instance of the TFS 2013 update I indicate, the workspace is associated with the correct server value.
What is ...?:
The current dress rehearsal went relatively smoothly. After the update, we did not encounter any problems when opening / manipulating projects, checking files, launching team builders, etc. Projects operate as before, similar to how they relate to source control. However, when checking * .sln files, the value of "SccTeamFoundationServer" is still set to:
http://<oldServer>:8080/tfs/DefaultCollection
... And yet he continues to act as if it does not matter. In fact, looking in the "Change control source" dialog box, the bindings look exactly right, pointing to a new instance ...
http://<newServer>:8080/tfs/DefaultCollection
Question:
This is a rather curious state in which the solution files are located. Can they continue this path if they stay in TFS? Or do we need project owners to change their project bindings? Keep in mind that we are talking about almost 1000 design solutions.
And, of course, if you simply untie and restore the original control, they will receive the wrong server value, unless they first update the correct SccTeamFoundationServer value in the * .sln file manually.