Moving files lose history in TFS 2013

Question

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?

Pepsinate

See also: #27492084 – Forepart

Depending on the reason for your move, you can also use branch reparenting to work around this issue. What type of change are you making? – Jiggered

It also happens when I merge a branch – Curmudgeon

Answer 1

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.

Forepart

Thanks @Forepart for your thorough answer! I actually ran the "tf move" command and like you said it did preserve the history. It's just that I was not aware of the drilldown option! Now that I go back I can see the "older" history. – Pepsinate

what about moved folders? The only solution I know is use tf history or go to the files under it, or show the deleted folders in Source Control Explorer and query the history there. – Orlene

@Orlene history is stored on items, not really on folders. It has to do with the way history is stored. Viewing deleted items is indeed the only way to find this information. – Forepart

@jessehouwing, we still need the recursive history in Visual Studio. You can vote for it here: visualstudio.uservoice.com/forums/121579-visual-studio/… – Orlene

@Forepart Wonderful answer. I'm a little confuse with rename/move ,add/delete in the using of TFS API. Would you mind to give a hand in this question #42662027 to help OP figuring out the issue. – Shellyshelman

Had the same issues. @Forepart thanks for the "history is stored on items, not really on folders" tip and the drilldown on that. I really thought my history was disapearing on checkin! – Sciamachy

Just want to point out that if you are moving files from one Project/Repo to another and then you delete the origin Project/Repo i seem to loose all my changeset history that was moved over. :( – Sciamachy

@nugs correct, data is stored in the project where the changesets was checked into. You will loose history when you delete the project containing the history. – Forepart

@Forepart thx... they sure do use the word "move" loosely! – Sciamachy

@Sciamachy you'd would have been equally fazed if they removed the history from the source project. History is created and stored in the project where the data is stored at that point in time. It's the only logical thing. – Forepart

@Forepart how do you get your history to show hierarchical like that with collapsible sections? – Length

Answer 2

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)

Photomicrograph

WARNING: This will officially put your TFS installation into an unsupported state. – Forepart

The migration workaround does work, having used it before, though it also assign the account used to perform the migration as the author of the changes. On the plus side, that information is not lost, as it is appended to the description of the changes. So if you can live with that, I'd recommend that. – Jiggered

The Visual Studio user voice suggestion no longer exists. Did MS ever approve you publishing this? – Fictionist

Answer 3

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:

1. Microsoft to fix the way folder history is shown in VS or add a Show Recursive History context menu item.
2. 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.

Orlene

Answer 4

Please find my tf move experience

There was main branch in the TFS. I've created main-rest on the same hierarchy level as main. Then I tried to move main-rest to another subfolder (to move experimental branches from the $ root to the subfoler.

I've removed local folder mapping and executed

tf move $/projectName/main-rest $/projectName/experimental/main-rest

The command listed all files in the branch in the output. Then I've committed my changes.

It looks fine, but * there is no branch folder history any more * merge does not see the changesets to merge

There was a possibility to merge from the main-rest to the main branch before movement. It is still available but no changesets to select when merging.

There is only one "moved" changeset in the "merge selected changeset only" option. It has happened after the main-rest was moved to the experimental subfolder.

I hope that it is possible to merge the whole master-rest branch (but it is not right time to test)

I've used tf.exe command line utility that is shipped with the VS2017 (patched with the latest update available for today). Source code is hosted on the cloud tfs (https://dev.azure.com)

Regards

Sherylsheryle