How to merge bug fix branch into trunk and release branch

Question

Consider the following situation:

• Development is mainly done in trunk.
• Branches are used when fixing complex bugs or developing new (unstable at first) features.
  Normally these branches are then merged into trunk once development is done.
• 1 branch is used as current release branch (say currently "R-1.0").
• Tags are used for the release (would be "R-1.0.0").

Now a complex bug which is in trunk as well as in the current release 1.0.0 must be fixed:

1. A branch "BG-1" from trunk will be created.
2. The bug will be fixed in this branch.
   At the same time development will continue in the trunk.

How do you proceed to reintegrate the branch into trunk and "R-1.0" now?

• Merge trunk into "BG1", then reintegrate "BG1" into trunk and then into "R-1.0".
  =>This cannot be the solution as this way "R-1.0" would receive all the stuff that was developed in the trunk since release 1.0 which is not the goal.
• Try to reintegrate "BG1" into trunk and then into "R-1.0" without merging the trunk.
  =>This also cannot work as other changes which weren't part of release 1.0 are already part of the "BG1" branch.

Is there any solution to this problem?
The only solution I see would be to start "BG1" from "R-1.0" rather than trunk in the first place. If so, does this mean that for each bug fix branch the developer has to find the oldest supported release which contains the bug and branch from this release branch?

Update:
The practice of doing all development in and from trunk originated from this answer by "Jim T" which is a concept I really like.

Answer 1

I would suggest merging the trunk into BG1, then reintegrating BG1 to the trunk. You could then merge a range of revisions to R-1.0. The commit where you reintegrate BG1 to the trunk should only contain the bugfixes, so you could merge that to R-1.0. Or you could merge the specific commits to BG1 that fixed your bug.

Depending on how much the trunk has changed since R-1.0, you may have to hand edit R-1.0 before committing to make the changes apply to the old code. Such is the nature of maintaining old releases.