How to refactor within Visual Studio without losing source control history?

Question

Using ReSharper to move/rename source files within Visual Studio 2010 is an enormous help when refactoring an application. The Perforce source control integration is not able to cope with these kinds of changes without treating it as an unrelated "delete from here" "add to here", which breaks the history chain. My questions are:

1. Is there any way to coerce the Perforce plugin into doing the right thing in the first place?
2. If not, is there any way to reconcile after the fact externally? (will Perforce have any way to recognize files which have been moved and possibly renamed and had limited content changes?)
3. Is there another source control product that handles this transparently?

Thanks!

Answer 1

This is a failing in other source control systems, not only Perforce. TFS suffers from the same issue.

1. No, there is no way.
2. Apart from commenting in your checkin comments, if you ensure that a commit only includes the delete-and-add, you can kinda keep the link there.
3. I believe Git does. It also handles movements of parts of code between files.

Answer 2

You may want to check out Git. It has no file-specific hangups like other revision control systems in that revision history does not depend on a particularly named file. Each commit is a diff of the previous code irrespective of the files within it.

For integration with Visual Studio you may want to check out Git Extensions. For Explorer shell integration see TortoiseGit.

Answer 3

The new Perforce plugin, P4VS, does a much, much better job of managing moved/renamed files within Visual Studio. If you've only tried P4SCC and been disappointed, please try P4VS. I've found that it does the "right" thing in most of the cases where P4SCC just didn't.

Answer 4

With Perforce 2009.2 and up there is a p4 move command. It's not perfect, you retain the history on the files, but selecting a folder doesn't show the history in p4v.