7

Background: In my job, we use SVN, C# and VisualStudio. Part of my task regularly involves global renames. Often I end up with a broken build after renaming something and then merging in changes.

The question: is there a solution out there that can look at my changes, notice the global rename and then apply that to the edit that others have made while merging them in?

Another way to get much the same effect would be some sort of refactor log and then apply that to the incoming edits.

The tool need not be perfect, even if it just noted any references in their edits that referred to something that I have edited would be valuable.

Edit I'm aware of VS's refactor tools. What I'm looking for is something that will allow me to, after I have refactored my working copy, apply the same refactorings to other peoples edits that I now need to merge in.

The ideal solution would be to make sure there are no outstanding edits when I do the refactoring, but that would prevent anyone else from getting anything done for the next week or more. (Because they would have to sync every half hour or so for the next week)

BCS
  • 75,627
  • 68
  • 187
  • 294
  • 1
    Currently a nice (commercial) option seems to be [Code Compare](http://www.devart.com/codecompare/), available on Visual Studio's Extension Manager. – rsenna Apr 18 '12 at 02:09
  • 1
    Have you checked this one?? http://plasticscm.com/sm/index.html You should, it is exactly the c# tool you were looking for – pablo Mar 26 '13 at 06:30
  • So what you actually want is a semantic patch tool. – mbx Oct 05 '17 at 14:53

5 Answers5

9

There is a commercial tool for exactly that use case called Semantic Merge. They provide a 15-day free trial, open source projects may use it for free (contact the support).

The company behind semantic merge also has a git client with integrated Sematic Merge which is currently beta (here, have some short intro videos).

mbx
  • 6,292
  • 6
  • 58
  • 91
1

Keep renaming seperate from other refactorings. They can generally be automated and therefore making the changes is easy. You can even distribute scripts to allow other engineers with merge hell to perform the transformations on there files.

There is no easy way to automate refactorings, so keep it simple. A rename should only take minutes and you should be able to check out and commit with minimal testing.

Dave Hillier
  • 18,105
  • 9
  • 43
  • 87
  • Re that lat bit: In general I agree, however a tool that can recognize some special classes of refactorings (that are automateable) and apply them to other code should be practical. – BCS Oct 28 '08 at 00:50
0

Assuming at least VS 2005 and the global rename is a variable/property/function, there is a Refactor - Rename right-click menu option you could use. By design it propagates the name change in your entire solution.

Austin Salonen
  • 49,173
  • 15
  • 109
  • 139
  • Thats what I'm using in the first bit. It doesn't do much good later as it won't reactor invalid code (and that's what I get after a merge) – BCS Sep 25 '08 at 19:28
0

Wouldn't it be possible to reduce the time needed for you to commit your changes? One or more week seems quite long between commits...

Xavier Nodet
  • 5,033
  • 2
  • 37
  • 48
0

I understood your problem. Unfortunately, I think there isn't a SVN script smart enough to do this job while syncing.

Maybe your team working more appropriately with SVN could make this situation be unpainful. When you do an svn:update in your working copy and realize merging operations, it is a good practice to rebuild the updated solution before do commit the changes.

Having a svn script with the ability to doing it automagically when merging would be great, indeed.

Victor Rodrigues
  • 11,353
  • 23
  • 75
  • 107