Team Foundation Server issues – rename resolving

This is the first part in a series of posts about Team Foundation Server. In an earlier post I promised to write about problems I’ve experienced with the source control part of TFS. I got rather tired of having to explain multiple times to various persons all the problems I’ve encountered in the past, so I decided to list all the issues on my blog.
Some background information to set the tone. I’m the build manager for a large project. Currently the project consists of around 17,000 files and contains ~3.5 million lines of code (blank lines and comments not counted). Code is a mix of C++, Visual Basic 6 and C# (for the largest part).

This project contains multiple applications that are released as a complete suite in a yearly cycle. Some 100 programmers work in different teams on this suite. Each team has their own branch to be able to work in isolation. We maintain a stable trunk principle. The trunk should always build. Breaking the trunk is not a good thing ;-)

When a team is ready to integrate their features, they first merge from the trunk to their branch. Any conflicts are resolved in the branch and a build is started. After a smoke test on that build, they signal the build managers that they want to merge to the trunk.

Because of the stable trunk principle, only build management has merge access to the trunk. We merge their changes to the trunk and start a build on the trunk. If the build is successful, we are finished and we go back to drinking coffee. If the build fails, we get annoyed, yell at the team leader and have to work with the team to solve the breaking build. Fixing the build is top priority.
This structure was defined together with Microsoft and has served us well (so far).

Issue: TFS wants you to resolve every move/rename manually
In the situation I described above I really don’t want to see any merge conflicts popping up when I’m merging from a team branch to the trunk. However, TFS deems it necessary to flag each and every rename of a file in the team branch as a conflict. I have to specify if I want to keep the old name or take the new name from the branch.

Suppose that the team has done a bit of refactoring. They moved some files around to another directory and renamed some files to better represent the meaning of the file. All nice and dandy.
When merging these files have not changed in any way except for the name/location. Yet TFS thinks it is a conflict and it has to be resolved.

I believe that the merge conflict window should only be shown when there actually is a conflict. TFS is able to see that the files have not been changed in the trunk and that they have been renamed in the branch. Therefore the rename should have been done automatically during the merge.

Microsoft says this behaviour is by design. Apparently, some large customers want to see each and every rename. And no, this behaviour cannot be changed.
This may not sound like a big deal to anyone, but I’m a strong believer that tools should support your chosen method of work. Tools should never dictate your method of work.


Popular posts from this blog

Small tip: use QueueBackgroundWorkItem for asynchronous work in ASP.NET

Why you should use git merge --no-ff when rebasing.

Using NUnit for your tests in Team Foundation Service with a Git repository