Recently, I have read a post in MSDN, and that reminded me of important issue I meant to raise for quite some time.
The scenario is rather simple - let us say that you branch folder that contain Visual Studio solution (or project); then you perform development in both branches. At some stage you merge one branch onto another.
While it is obvious how code files (C#, C++ etc.) are merged, for Visual Studio project and solution files it is less so. Even if you do not peform advanced changes in those files (for example, specifying different custom pre-/post- build steps), Visual Studio itself may change the file (see the problem is described in the post). And when you merge, usually there is no conflict and changes are merged automatically and thus you can end up with invalid solution or project file!
It appears there is no magic bullet solution for the issue in current version of TFS. What I do is essentially manual procedure: the idea is to check whether any solution/project files were merged. In most cases there are no conflicts to resolve, so I manually review the merged solution/project files before checking them in, to make sure that automatic merge changes make sense. It may be paranoid but is way better than broken solution.
More than that, after some thought on the subject, I do not see how it may be handled (aside from customized merge wizard specifically for Visual Studio solutions and projects). Any thoughts on the subject would be appreciated (I believe Microsoft guys will thank you as well).
Friday, September 15, 2006
Merging Visual Studio solutions
4 comments:
What you can do is disable merging of .sln files by configuring the Team Foundation Server project. This means that any time a solution is checked out it is locked by the user. Changes to solution files will still show up as a merge candidates, but you will not be able to merge them in the merge tool (nor will TFS attempt to merge the files for you).
Trygve
I am not sure that disabling merge is a complete solution; let's say that I am trying to check the changes in and is unable to do the merge - but then you will probably will need get changes across anyway, and do so manually.
But it is surely better in a sense that you know that you have changes _before_ check in and not after.
I absolutely agree that this is not a complete solution. MS should definitely offer a tool that "knows" the solution format and is able to merge it.
While we eagerly wait for this tool we need to handle this and I consider the chance of something going seriously wrong if the solution is merged to be to great to risk. That means we have to move the changes manually. It's a hassle but the alternative is much worse :)
Trygve
MS should simply come up with a format that's mergeable. And VS shouldn't change 80% of the file every time I make a little change (like add or remove a project). Problem solved.
Post a Comment