What's generally done (and what we do during the development of the cloudportal) is the following:
We have a master (trunk, I use these two names interchangeably), branches and tags, obviously. Trunk always represents what's running in production and should always be releasable (considering it should already have been released at some point in time).
Whenever we develop features, we do that in separate branches. The tricky part comes when we want to release, as this may contain zero, one or more feature branches. We branch again from master into a "release" branch. This branch will eventually end up in production. Then we either perform small fixes (in the case of zero new features) and/or merge the changes from the features branches to this release branch. Old merged branches are deleted (it's SVN anyway, so going back should never be a problem).
We then stage & test this release branch, determine whether it's production ready and then put it into production. Release branch is merged back intro trunk and deleted, as it doesn't represent anything anymore.
That being said, that doesn't completely answer your question. You want changes from an upstream branch in your feature branch. So let's say I'm developing some major feature and in the meantime, someone else has released a new version and merged back into trunk. While you 'could' merge those changes directly back into your branch (trunk -> feature-branch) SVN doesn't handle these cases particularly well and can possibly completely fuck up your svn:mergeinfo property. What I prefer to do is rebranch from the current stable trunk (containing the fixes you want), rename my feature branch to something like feature-branch-old and then merging those changes to the new branch. Then delete feature-branch-old and continue developing in the new branch.
As far I know the hotfixes can be merged to the service pack. But that can be confusing, better get to one point (all hotfixes and new functionality) with an official release and start a new service branch from there.