Merge and wild rearrangements

Question

Currently we have a MAIN branch, and then there are a couple of version branches, currently 15.20, 16.10 and 16.20. Under each version there is a tree of modules for instance Apple, Pear and Banana. Each module has code C#, WPF, SQL and whatnots. All SQL code is under $/Project/Branches/16.20/Apple/SQL etc.

At some point we need to rearrange this so that the SQL for some of these modules are gathered under a common hat like $/Project/Branches/16.20/FruitSalad/SQL. This SQL directly will encompass all SQL code that currently is under Apple/SQL, Pear/SQL and Banana/SQL. However, for many other modules, the SQL code will stay where it is. But the FruitSalad collection is around 25% of all stored procedures, so it's a lot.

We will also need to move a lot of individual procedures around, so that a procedures that are in IceCream/SQL may go to Coconut/SQL. Then there is a bunch of code in SourceSafe that we want to move to TFS, but that's another story.

We are thinking that we need to do at least the first step in all branches, including MAIN, or else merging changes from the lower versions to the higher will be a big pain.

Or am I wrong? Will TFS automatically find its way from from 16.10/Apple/SQL to MAIN/FruitSalad/SQL to 16.20/FruitSalad/SQL?

This is a big system, in total we have over 7000 stored procedures, although about only half of them is in TFS right now. Add all C# code, and you realise that Merge here is a difficult endeavour with big risk for errors. An alleviating factor is that none of these versions are in production currently, however there is a very important shipment date ahead, so there is all reason to tread carefully.

---

Erland Sommarskog, SQL Server MVP, [e-mail]

Answer 1

TFS will be able to find the files to a certain extent as long as you truly move the files in source control. If you copy the files to their new location on disk and then check them in, TFS will lose the link between the old and the new name.

If you move the files in source control, there are some limitations:

https://connect.microsoft.com/VisualStudio/feedback/details/508246/merging-items-back-to-parent-trunk-after-a-move-operation-in-tfs

https://vsarbranchingguide.codeplex.com/discussions/257869

I also recommend you use the following add-in, it improves the move/rename experience in the Source Control Explorer:

http://visualstudiogallery.msdn.microsoft.com/c6642e7f-1a58-4ff0-aef9-0322dcc2b28d

---

My blog: blog.jessehouwing.nl

Answer 2

Whatever you do, first do it on a test environment if this is critical.

---

My blog: blog.jessehouwing.nl

Answer 3

Thanks Jesse!

If I understand this correctly, we should be able to make the restructuring in 16.20 (or 16.30 or whatever) without having to touch earlier versions. that would be great! The if $/Project/16.10/Apple/SQL/some_sp.sp is change, TFS will merge the change to $/Project/16.20/FruitSalad/SQL/some_sp.sp.

And if I understand the Connect item correctly, if I change some_sp in 16.20, TFS will merge it to Apple of want to move the change in that direction.

Several files will be changed as part of this operation, and the changes will come in from the side, so will have to check out everything and check in. But from what you say, we should move and commit that first and then do the next step.

An interesting question though is when we change MAIN. Initially, MAIN might be better off with the old structure, but in the long run that it would be untenable.

Then again, the way we work currently (still to a great extent in a SourceSafe mind-set), MAIN is not that useful, and we could just as well make each new version a branch of the previous.

Yes, we will definitely to this in a test environment first. That is, back up the collection and restore it on a different server. I want the whole operation to be automated, because there will be too many steps to make manually.

---

Erland Sommarskog, SQL Server MVP, [e-mail]

Answer 4

tf.exe and tfpt.exe are your greatest friends for the upcoming days then :)

---

My blog: blog.jessehouwing.nl

Answer 5

tf.exe and tfpt.exe are your greatest friends for the upcoming days then :)

Or Perl and the API. :-)

---

Erland Sommarskog, SQL Server MVP, [e-mail]