I refactor my and other people’s code all the time. When I work in a branch and not in Trunk, this sometimes results in some extremely painful merges, especially if I don’t merge back to Trunk regularly (the code at the branch slowly shifts away from the Trunc, and when people modify Trunk I have to figure out manually how to apply this to the branch).
The solutions I know are either
- Constantly merge to and from Trunk – reduces painful merges, but then why work in a branch at all?
- Whenever you need to refactor something, switch to Trunk, do the refactoring there and merge to your branch – I don’t find this very practical, since the actual cost of switching environments for every refactoring is huge.
What do you do?
Refactoring on a large scale needs to be done at the right time in the development timeline. If you do huge amounts of refactoring near release you’ll end up hurting yourself because you’ll introduce painful merges at a time when changes should be minimized. The more disruptive your refactoring will be the earlier in the development cycle it should happen (and the more special process there should be for it, e.g. stop edits to the affected files as much as possible for a period of time).
Constantly merging to and from trunk is generally good practice.
Why work in a branch at all in that case? Because you have more control (you can stop merging into trunk to stabilize it for release, for example, without stopping checkins to your development branch). Because you can place a high level of validation around merging to/from trunk without impacting checkin velocity to the development branch much.