A while back we renamed the main folder where our project source code is, and for some reason, TFS represents this as a discontinuity in the history:
This is kind of annoying, because whenever I need to look at something from before the rename, I have to keep expanding the child nodes until I can continue to search. I've also just discovered that when enumerating through the history using the API (via VersionControlServer.QueryHistory
), it stops at the rename (changeset 1172).
This is getting very annoying. Is there any way to fix this break in the history? Failing that, is there a way to get QueryHistory
to return the full history, including before the rename?
It appears that there's no way to get the UI to do what I want. But on the API side I realized that the break in the history was actually caused by the way I was searching:
This wasn't finding the changesets before the rename because I'm searching by name and the name is different. So now I just run this twice, once with the new name and once with the old, and merge the results.
For the api question:
I vaguely remember how history was rewritten in Visual Studio 2010. I also peaked at MS.TF.VC.Controls.dll in ilspy, I hope Chad will forgive me ;) What works for sure for files renames (I would hope for parent renames as well) is to use
QueryMergesExtended
and specify to include sourceRenames. A rename in TFS 2010 and later is branch and delete, so you can find source of every rename, by following where it was branched/merged from. It will definitely require some coding on your part.For the UI question (I know I'm backwards here) what exactly are you searching? Comment? Filename? Specific content change?