I want to perform a major codebase reorganization, but I'm unable to proceed unless I can provide a way for trunk fixes to be easily applied to branches that were taken before the reorganization.
One approach I was considering was to apply the reorganization to to all of the support branches, but this is potentially destabilising.
A preferred approach would be to provide a merge tool that can take into account the updated file locations. Any suggestions on how I could implement this?
My question would be, why do you want to merge a reorganization back into branches? The idea behind branches is that they are (typically) maintenance mode (e.g. trunk is version 4 and you need to go back and fix version 3, you do so in the version 3 branch), or for people to do some side work that they don't necessarily want to have in the trunk right away.
If you are doing a complete re-org of the codebase, that sounds like a good time to break some backwards dependency in code. If you don't do this, you may be limiting what refactoring you can actually accomplish.
I'm in the same situation where branches aren't always just maintenance related nor hotfix related. We often have to maintain multiple active stabilization branches and must merge between them. We don't have the luxury of mixing scope to practice continuous integration on a trunk.
We resort to performing merges at a more granular level. If a folder is moved, perform the merge directly from the old location in one branch to the new location in the other branch. I'd also highly recommend that you use the "svn move" to do the original restructure, it ensures ancestry is understood.
Either way, it's not pleasant and very manual. Keep good records.