Branching and Merging in VSTS

Question

How effective is merging when folders and projects have been renamed in your solution?

Answer 1

We've had problems with TFS 2005 dealing with branching and merging which has had some convoluted changes. However, for the most part we have had no issues with renames and branching/merging. TFS 2008 supposedly has fixed a lot of the corner cases surrounding branching/merging in TFS 2005.

Answer 2

In my experience TFS can track renames, as long as you do all the renaming within the SourceControlExplorer (TFS).

The problems tend to occur when you have other people making changes to the original files while someone else is doing massive renames/moves, while someone else is editing the renamed version.

Where possible I would say that if you are doing large scale renaming and moving it is worth informing team mates, and if possible get them to hold off making changes until you've checked yours in.

As with all branch/merge issues the problem is greatly reduced by checking in and merging little and often.

Answer 3

We've had lots of success with TFS 2005 when it comes to file deletes/renames, with a few very specific exceptions, namely:

1. Files which have been renamed in both source and target branches (this is usually trivially solved with a click on "Ignore server changes");
2. Files which have been renamed in the target branch but deleted in the source branch. I recall one case where the merge would not work no matter what we tried, and we were forced to "revert" the change on the source branch and re-do after the merge.

Supposedly TFS 2008 solves a lot of these issues, but honestly aside from occasional merge hickups TFS is stable, and hierarchical merges are a lot simpler and quicker than with SVN.

Answer 4

We've had lots of problems with TFS 2005 and deletes in general. I haven't determined the cause yet, but a number of my team members have run into problems merging in changes that involved a renamed or deleted folder. This seems particularly true if there was a lot of refactoring (and renaming, and re-renaming) in the branch where the renames occurred. I haven't figured out the reason or reproduction steps, as I haven't been personally involved in any of the situations where it didn't work.

I've seen some other general deletion problems like this: 1 in Branch A, reduce permissions in subdirectory 1 to read-only 2. Create Branch B (branched from A to B) (check in) 3. Delete Branch B (check in) 4. Create a new branch from A, give it the same name as branch B 5. Get a weird permissions error related to TFS still "seeing" the read-only permissions on the deleted branch B.

Only way we've found to avoid it is to insert step 2a: rename Branch B to _Branch B (check in)

Overall, TFS has been great for us, but there's something flakey going on with deletes, renames, and merges. We hope to upgrade to 2008 soon, and I am hoping that it addresses our issues.

Answer 5

I've had experience with mass file and folder moves with TFS 2008. This was done to make our source code structure more consistent. All I had to do was drag and drop (and wait) in Team Explorer, then commit the changes.