开发者

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

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 开发者_Go百科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!


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.


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.


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.


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.


You can see the full history by looking at the file revision graph.

The steps to take are: 1) Go ahead an do your rename 2) Right click and view history of the newly named file 3) It only shows the current version, but, if you right click on that version and select the revision graph you can see the full history with a link where the delete / add occurs. 4) You can select nodes on the graph and do a diff to see changes between the different files.

It's an extra step and not very obvious, but it works for me.


  1. No, not that I'm aware of. Try contacting Perforce support.

  2. I wouldn't go that way.

  3. Not another source control product really, but you could try VS2P4 instead of P4SCC, which seems to work with ReSharper's rename class refactoring. I made the transition some time ago and really like it, even though it's got its own set of quirks. Available for installation through the VS2010 Extension Manager.


Here's a convoluted solution if you really need to keep this info:

  1. Create a Mercurial clone of the Perforce depot (or sub section) using the Perfarce extension.
  2. Install the VisualHg SCC plugin, which is an integration of Mercurial into VS
  3. Do your refactoring - VisualHg does, I believe, cope with renames properly. It certainly does in the manual case of renaming a file from withn Visual Studio, and so I am assuming that Resharper will work too.
  4. Push changes from Mercurial back to Perforce. This should include the proper branch-and-delete (move) operations that you are after.

Note I've not tried this as I don't have Resharper, but the Perforce->Mercurial->Perforce link works well with Perfarce, and VisualHg is vastly superior to other SCC plugins that I've used. So it may be worth a go. You could probably quickly the out the Resharper/VisualHg link first, and if that goes OK then do the Perforce->Mercurial step.


I tried VS2P4 with ReSharper's context help "Rename file to match type name". And...

it does not work. It shows the dialog

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

and if I click "Continue with change" it really does what the warning said. It deletes and adds the files without informing Perforce about that. Only the project file is checked-out.


FWIW, Version 1.74 of VS2P4 released today has major performance improvements, especially for solutions with thousands of files.


VS Macro

I have written a macro for adding a "p4 move -k" action to Visual Sudio's Rename event. See answer of "How to keep change history while renaming files in Visual Studio using Perforce".

With that macro you can do at least a correct file rename within Visual Studio.
I think it is not possible to correctly rename class and file at once (as it e.g. ReSharper does) because renaming and changing a file in one changelist is not possible in Perforce.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜