My development team has worked with subversion for quite some time. The way that manage the trunk and branches is as follows:
We (almost) always release from t
So assuming I've got your model right here: You develop major changes to the project in a branch (off of trunk) which can get quite old.
You continue to do other development on trunk which always holds the 'live' software, so these changes are minor updates and bug fixes. You're getting problems when you merge the monumental development branch back into trunk.
You can only effectively manage 2 concurrent product versions with that model, which may be enough for now, but might bite you in other ways anyway and will get worse if you ever need to manage 3 or 4 versions. Can I suggest inverting the way you work?
Have a Version branch for each release. This should be branched from trunk (at any revision). The only way you modify the version branch is to merge in revisions from trunk.
This means you can work primarily on trunk instead of in a large development branch. You also apply your bug fixes directly to trunk - so you've got no major integration issues being stored up for the next release. To release bug fixes to the previous versions, just merge the required trunk revisions into the appropriate Version branch.
This way you can keep everything you want to release in branch, but only actually ever release what you're happy with, because that's all you merge in to the version branch.
You can still take development branches if you need, but you can keep them targetted and small, perhaps individual features rather than large projects.
This will allow you to manage multiple versions in a sane way and keep a good track of what's in each release using svn's merge-info.