I'm using VS2013 Update 4 with TFS 2013 Update 4. In Source Control Explorer, whenever I move a file from one folder to another I can see that the file's history is preserved in the new location. However, that history is gone when I check-in the pending changes. The same thing happens when I try to run "tf move" command. So, how can you move a file in TFS and still keep the file's history?
When a file is renamed correctly, the History is not "Gone", it's associated to the "old name" instead. A rename that is done the right way (tracked as a rename and not as an delete+add) has a drilldown option to view the "older" history:
- Changeset 81~82 contain the changes to the old name
- Changeset 83 contains the delete + rename
- Changeset 84 a new change that was checked in after the rename
When a rename is done outside of the Source Control Explorer (or from a very old version of the Source Control Explorer (e.g. VS 2008)) or outside the Solution Explorer, then the change will be detected as two individual actions, one delete and one add. You can use the "Pending Changes" window to promote these to a rename so that the history is preserved:
On the commandline this can only be accomplished using "tf rename" and "tf move". Using the standard "mv" and "ren" commands will fail to preserve the history.
Below is a further example of using all the different methods and clearly showing that history is preserved by looking at the history of the current file name:
As mentioned in the comments, history is stored in the Team Project that contains the items revision. When branching/moving across projects your history will be spread across these projects. Should you delete a Team project than all history that was accumulated in that project will be lost.
I came to this issue from this question.
The issue exists since TFS2010 and is not only a problem for renamed or moved files, but for renamed or moved folders as well. The worst is if you a renamed branch and then look at the folder history. Then you only find your rename changeset.
Here you can see the reaction of MS on this task. Basically they say that they are not doing it because it is a lot of work and makes the history slower.
I could not live with this fact and programmed a fix for this. Recursive history selection happens in SP dbo.prc_QueryHistory. I changed the SP and added the following functionality:
- (as normal search for the last 256 changesets recursively)
- then check the changesets if some of them represent rename/move operations
- if so recursively (in a loop) follow each rename/move to its former ItemId and repeat this step (in case a file/folder was renamed multiple times)
- then find all prior changesets to the former ItemIds as well (moving/renaming changes the ItemId)
- add the newly found changesets to the list of changesets and cut it at row 256
The effect is a slower history (especially if you do it on the root of a deep folder tree), but the issue is fixed. And I rather live with a slow history than with an incomplete.
I could provide you the SP I wrote, but I am not sure if I would be allowed to publish it here, as it contains MS protected code. (And of course I cannot guarantee that the fix will persist when updating the system. - I wrote my SP on a TFS 2013 SP3.)
Update: I asked MS for permission to publish my fix (2nd link in my post)
I don't think jessehouwing fix works for folders. In fact if you use Source Control Explorer of VS 2012+, the move of folders preserves the files history (shows recursive in VS), but not for folders. Folders history is flat.
The solution to this problem:
- Microsoft to fix the way folder history is shown in VS or add a Show Recursive History context menu item.
- Migrate all changesets from one folder to another. Unfortunately I still can't identify a tool capable of doing this for TFS 2013 or VSO.
来源：https://stackoverflow.com/questions/28990323/moving-files-lose-history-in-tfs-2013