My machine hangs while resolving conflicts during a merge.

Here's what is happening:

1. I initiate a merge between 2 branches
2. It correctly identifies the conflicting files.
3. I select one of the conflicting files and click on "Resolve" button.
4. The "Resolving Conflicts" window comes up saying that its building a change summary. This process of building change summary keeps spinning.....and my machine hangs. The resolving conflict operation never ends.

Note: This only happens for some files and not others. I tried doing this from multiple machines and got the same result.

Is this a known problem, bug?

Thanks.

1. Do you know why/when this happens? Is there a way to avoid the triggering factor?
2. Do you have any suggestions/pointers to such 3rd party tools.

1. It can happen if there are two identical paragraphs, and both edits insert a (conflicting) change between them, and the diff algorithm is in a certain tricky state.
   
2. See here: http://blogs.msdn.com/jmanning/articles/535573.aspx Note that you can't just set the diff/merge option, since the client always scans the files for merge conflicts (and thus enters the infinite loop) before prompting you whether to use a merge tool -- you'll have to fetch the 3 versions manually. You can also try editing the file subtlely to eliminate the cause.
   

Richard,

I hate to say it, but the issue appears a major showstopper. What you are saying is basically this

1. Merge between branches may hang
2. If it hangs, you must kill the Visual Studio
3. As there is no way of knowing what specific file and what specific condition in file caused the problem, user cannot do merge between branches in TFS and should resort to workaround.

The problem is, that workaround is such that it greatly discards the whole branching model. User must get versions and perform versions merge manually - that is the thing that one can do in any tool without integrated branch/merge even available.

I will try to explain the reasons why I am concerned. Currently, we are performing TFS implementation at client's that is supposed to include iterative development, and sometimes there are two iterations in parallel. We are (or were) going to implement that as trunk and branch, but there is neccessity of frequent merges between branches. If there is situation (and no indication how frequently it may occur) where merge will hang, and user must mess up with merging manually out of TFS entirely, the branches scneario is clearly a no-go.

So could you please be more specific as to

• At what conditions exactly the issue occurs
• When the patch for that bug is planned

It could help us (and I believe the community as a whole) to estimate the severity of the issue.

Yours truly, Eugene

It's important to note that, in addition to what Richard's said, the problem at least appeared to be extremely unusual in our internal Dogfooding. Only one person, with one set of files, found it in months of regular usage (and that was just a week or so after the bug was found by QA, late in the product cycle). The problem is a fairly technical one deep inside the differencing engine mechanics.

It's difficult to characterize the exact conditions - there's at least two different patterns to the files we've found. But, in one case, it came down to when one of the two diffs is being performed for a 3-way content merge, a diff region is sometimes expanded to include an adjacent hunk (as in, one change region instead of two adjacent change regions, or a change, a small unchanged region, and another changed region). If this expansion completely consumes the adjacent hunk (the term we use is 'paragraph' although it's not quite the same thing as you generally think of a 'paragraph'), you'll get this problem.

If you have a set of files that's doing this, a change as simple as injecting or removing a blank line from the problem area may be sufficient to work around it (and allow the automatic merge to proceed). But, for any non-trivial file, it is difficult to identify which diff region is at fault. Looking for lines that are counted as part of a change region (but in reality, are just adjacent to your change) is one possibility.

You might be able to identify the problem area quickly by hacking up your local version before running resolve - e.g. cut out the first or last half of the file, run resolve, see if it locks up, then gradually narrowing down which block of code contains the triggering changes. I think this might be more frustrating than helpful, however, particularly if a file is large, or has many distinct changes (or both).

As Richard said, a QFE is in the works, but I don't know the details (yet). I'll forward this post to the feature dev owner and see if he has further suggestions.

Richard, Chris,

Great thanks for your feedback, it is very important for me to know the severity of the issue. It is good to know that it is something virtually irreproducible.

To conclude, my current impression is that

1. The issue is rare occurence, which means that I bear it in mind to provide solution if there is problem at client's, and that about it as far as prevention is concerned.

2. The workaround is not to identify the problem location in file, but to perform merge outside TFS. Considering that issue is supposed to surface only rarely and for single specific file only, the workaround is adequate.

Overall, I believe that your posts succeeded to "inject" back great measure of confidence as to the stability of the tool. Thumbs up for the effort!

Yours truly,

When I talk to the MSDN support people, they need an article number. Can you supply me with that?

Thanks.

Following up - got the fix and it works. I guess even with the article number the call center has a hard time "seeing" the article, but once you get past them to the technical people, they understand the article number and the hotfix number. Apparently, the article is not "published" yet.

Hi Richard,

thanks for the valuable information you gave to the community. We run into the same problem regarding the infinite loop on merge operations multiple times. Unfortunately it seems to be still difficult to get the mentioned patch, even with providing all the informations about hotfix numbers, kb article numbers etc.

I'm waiting now for 2 days for any answer from the support. I've to mention, that I'm trying to get this patch via the German support, because we are a German company.

Therefore the question: Is there an easier way to ge the hotfix or a direct download link ?

Thanks a lot!

Stefan

I am currently unable to merge *the* most important file in our solution between several branches due to this problem.

I have tried to get the patch from support Norway, but they say that the issue is now archived(!), and that they are unable to give me the patch. wtf?

If this is correct, I assume a SP is, or will be available for the TFS client shortly?

Steinar Herland

Help

We're having the same problem here, and can't merge our branches. I've tried contacting support but they say there's no hotfix connected to the given article and thus can't look it up.

Thus they told us to file a support request. But our experience with MS support response times has been horrible at best. Our support incidents have all taken 3-5 months to get fixes for. Can anyone help me get hold of the hotfix?

Thank you

/Kjell