I noticed a(n) (anti-)pattern in my team:
We decide to implement a feature so we (svn) branch. While implementing the feature, we do refactorings that would benefit everyone if they could be merged back to the trunk right away. We wait until we are done with the branch, then reintegrate it with the trunk and everyone gets the feature + the refactorings.
Now the funny thing is very often the refactorings are of much higher (and immediate) value than the feature that set them in motion, so it would be very nice if somehow I could get them in the trunk immediately and don't wait till the branch is done with and gets reintegrated.
As far as I know you are not supposed to "merge" a branch with the trunk, but you do the other way around (merge the trunk with the branch frequently) until the branch is done and then you "reintegrate" the branch back with the trunk. If you do it the wrong way (merge a branch with trunk) then you mess things up (mergeinfo and stuff) and when the time comes, you get into all sorts of evil and you can't reintegrate smoothly.
Ideas ?
It is possible. It even has a name - cherrypicking. Actually, cherrypicking is encouraged as long as it allows to avoid 'big bang' on branches merging. Moreover, if you do merging in the same direction (in your case from branch to trunk), it simplifies reintegration. Subversion remembers what have been merged previously using mergeinfo and excludes commits included into previous merges. It corresponds to the pattern Merge Early, Merge Often.
Principle is illustrated on the picture:
Difference with your case is that you need to merge in other direction, but it does not matter what will be the source branch and what will be the target branch.
So, don't be afraid of merging your refactorings into trunk. Actually, it will even simplify branch reintegration in the future.