Move a file in TFS, which is dragged from on project to another instead of remove and add it
Until now, Visual Studio removes and adds a file in the TFS if it get traged/moved between different projects. Visual Studio should move the file instead to prevent the CC history.
The same could also be used for cut & paste a file.
As explained in this blog post (http://blogs.msdn.com/b/visualstudioalm/archive/2015/10/08/how-we-use-user-voice-to-make-a-better-product.aspx), we had updated the status of this suggestion to “Under Review” to let you know we are tracking it on our backlog. To better indicate which one we are actively working on or which ones are on our 6-month plan, we introduced the states “Started” and “Planned”. The goal is to give an update on in progress suggestions at least every 3 months. This suggestion is still on our backlog, but they are not part of the 6-month plan.
Workaround: After moving a file in Visual Studio across projects go to pending changes and undo the file add and remove in pending changes (not the project files). Then in tfs source control explorer do drag and drop of the file again. This way the files get the missing tfs move operation and the file history gets preserved.
I got reply from Aaron Wang [MSFT]: "When you make some operations about some files, they only three Change state(add, delete, edit)."
I request that there is a forth change state operation move. A move operation is done by user and several source control systems support these including Microsoft TFS. But it is missing from Visual Studio.
Brian Tyler commented
Yes, I would say this is the major pain point in restructuring a solution.
Still not working in Visual Studio 2017
Carl Walsh commented
Our team has string code quality guidelines, and one of those is that moved files may not be added and deleted. My current workaround is to make the move change in VS so the project files get updated, then tf undo the add and delete, copy any changes to a temporary file, delete the now-untracked file, tf move the file, then copy the changes back to the moved file.
Any action that requires copying changes out of version control is a huge potential for mistakes!
Anthony Gregg commented
This would be a much better way of handling a "move". Support this idea wholeheartedly.
Ian Prest commented
This is extremely annoying.
I vote for this too. Refactoring is made cumbersome because of this
William Wegerson commented
I concur when a file is "Moved" in the solution view its history should be kept.