As I have said (here) before, MS is a massive company so anyone making as statement like "MS does X" is almost assuredly wrong.
Devdiv, to my knowledge, as a whole (VS, CLR, etc..) uses TFS. The fork of Perforce the original commentor is talking about is probably Source Depot. When I started at Microsoft we (VS) were still using Source Depot. As I understand it the primary reason was because we had been using it forever (okay, well back to the SLIME days) and there was a massive amount of history in there. Porting it all immediately to another source control provider was a large task. I 'fondly' remember the transition during development of VS 2010. Though to be fair the TFS team was great aboout finding/fixing issues exposed by suddenly onboarding the entire VS team and our possibly 'interesting' source control requirements. I believe Windows still uses Source Depot, likely for similar reasons (the amount of history they have in SD makes the devdiv history seem like a tiny blip).
As for merging problems, I don't know. We routinely merge huge branches with hundreds of thousands of files, including many project files, other XML config files, etc.. and I don't recall many 'insane merging problems' (just your garden variety merging problems that occur with that many files). Then again I am not intimately involved in the merges (other than for occasional fire-drills on files I may have modified). I suppose it also depends on what the changes were on both side of the merge.
I wonder when exactly MS took the old SLM servers down. It was mentioned on Raymond Chen's blog that it is difficult for even employees to access source control history of Windows prior to 2000.
Devdiv, to my knowledge, as a whole (VS, CLR, etc..) uses TFS. The fork of Perforce the original commentor is talking about is probably Source Depot. When I started at Microsoft we (VS) were still using Source Depot. As I understand it the primary reason was because we had been using it forever (okay, well back to the SLIME days) and there was a massive amount of history in there. Porting it all immediately to another source control provider was a large task. I 'fondly' remember the transition during development of VS 2010. Though to be fair the TFS team was great aboout finding/fixing issues exposed by suddenly onboarding the entire VS team and our possibly 'interesting' source control requirements. I believe Windows still uses Source Depot, likely for similar reasons (the amount of history they have in SD makes the devdiv history seem like a tiny blip).
As for merging problems, I don't know. We routinely merge huge branches with hundreds of thousands of files, including many project files, other XML config files, etc.. and I don't recall many 'insane merging problems' (just your garden variety merging problems that occur with that many files). Then again I am not intimately involved in the merges (other than for occasional fire-drills on files I may have modified). I suppose it also depends on what the changes were on both side of the merge.