8

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!

Carl Manaster
  • 39,912
  • 17
  • 102
  • 155
jlew
  • 10,491
  • 1
  • 35
  • 58
  • I am not sure I am understanding, as certain refactors will always be seen as a "remove then add" type of change. It really depends on what you are doing. Now, if Perforce sees a simple rename, etc, as a "remove then add", there is an issue. – Gregory A Beamer Apr 26 '11 at 19:55
  • Perforce will do the right thing if you, for example, do a Move/Rename from the command line or the Perforce GUI. Not if you do the same from within VS. – jlew Apr 26 '11 at 21:08

10 Answers10

3

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.
Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • Subversion handles this ok i think? if you rename then you can still see a single unified log of the file (at least i can with tortoisesvn). for the record am not the down voter. – wal Apr 27 '11 at 13:22
  • @wal - It does the delete-and-add thing though. – Oded Apr 27 '11 at 13:29
  • which does __not__ break the history chain? – wal Apr 27 '11 at 13:35
  • @wal: The point here is the VS integration. Perforce will maintain the history link if you use `p4 move`. But I bet ReSharper, P4SCC, or other refactoring tools won't know enough to call that command for renamed files. – JasonMArcher May 11 '11 at 16:55
  • @Wal / Oded : TortoiseSVN has the command "fix rename", which you can execute before checking in when one file is added and the other one is missing. – Schiavini Mar 15 '12 at 13:27
  • @Schiavini - The OP is asking about Perforce, not subversion. – Oded Mar 15 '12 at 13:29
  • You're correct, but wal commented about SVN since you also talked about Git and TFS – Schiavini Mar 15 '12 at 13:31
2

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.

Dan K
  • 720
  • 10
  • 8
  • Thanks. We switched to Git a while back (for other reasons) and it solves this issue nicely – jlew Nov 29 '12 at 16:42
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.

Paul Sasik
  • 79,492
  • 20
  • 149
  • 189
  • Interesting... Are you saying Git has no concept of an individual file's history, or that it can somehow tell that Dir1\Dir3\foo.cs became Dir2\Dir4\bar.cs? – jlew Apr 26 '11 at 21:14
  • It treats the whole repository as a unit and so individual files and even folders become much less important. It cannot tell that one thing became another, just that they are different. If you perform your update/commit and push/pulls frequently enough, the history is basically preserved. – Paul Sasik Apr 26 '11 at 21:19
  • So how do you track a particular class history (for example) back in time to find the point at which it broke? – jlew Apr 26 '11 at 21:23
  • You have to go through the revision history and also follow the file add/remove. There is no revision system out there that will perform the kind of tracking you're looking for, not yet anyway. Git is an improvement but you still need to be careful with your codebase. Besides, file/class renames do happen but they should not be that frequent that it becomes your primary concern in choosing a rev. ctrl system. – Paul Sasik Apr 26 '11 at 21:27
  • 1
    That's not true, perforce can track the revision of a file across renames, and moves just fine. Just make sure you are using 2009.2 or later. – aflat Apr 27 '11 at 00:36
  • @George: Right, it does it fine through the native client, but not when you do the operation from Visual Studio. – jlew Apr 27 '11 at 14:04
  • 1
    We ended up switching to Git, which does great in this situation. It turns out to be a bit more sophisticated in its tracking than Paul indicates above. If you move/rename AND modify a file in the same commit, it will still track it in most cases (if a certain % of the file remains unchanged) – jlew Jul 25 '12 at 17:00
  • 2
    Switch to another vcs doesn't help for someone using perforce. – Andy Sep 29 '13 at 23:08
1

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.

aflat
  • 4,329
  • 1
  • 20
  • 23
  • Perforce move/rename does the right thing invoked manually, but my scenario deals with batch operations that are happening inside Visual Studio as the result of a Resharper refactoring. – jlew Apr 26 '11 at 21:11
1

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.

johnB
  • 536
  • 1
  • 6
  • 14
0

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.

Community
  • 1
  • 1
brgerner
  • 4,287
  • 4
  • 23
  • 38
0
  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.

rjnilsson
  • 2,343
  • 15
  • 20
0

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.

Greg Whitfield
  • 5,649
  • 2
  • 30
  • 32
0

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

it does not work. It shows the dialog

enter image description here

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.

brgerner
  • 4,287
  • 4
  • 23
  • 38
0

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

Dale Brubaker
  • 393
  • 5
  • 6