views:

318

answers:

4

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)

A: 

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
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
A: 

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
see addendum to edit
BCS
A: 

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
+1  A: 

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
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