A common problem in my very small team workflow is handling merges from trunk/stable repositories up to feature branches which are ahead of the trunk or stable versions, but which need to track the changes in the trunk and stable versions. We are using mercurial, but any DVCS would perhaps have a similar workflow, including Git, or others.
Originally we had a workflow where a senior developer (me) did most of the merging, as that was the model I had experienced at a previous workplace, but similar to the previous place where we worked like that, this put a lot of burden on one developer to take the results of a large number of commits, and clean up the resulting mess.
If you were merging one change, with one commit message, maybe you could do this cleanly, but what often happens to me, is that I get a little behind, and a week of changes needs to be merged.
What I'm wondering is, when you DO get into a situation where a large merge is necessary, using Mercurial or DVCS, what is the process that you use, and does it involve collaboration between multiple developers on the team, and does your team use pair programming to solve this complex programming problem of How Do I Sort Out and Land the Changes from TRUNK that need to get to FEATUREXYZ branch.
The workflow or standard-practice I am envisioning looks like this:
when a merge up to a feature branch looks easy and only involves my own changes I do it on my own
when a merge up to a feature branch also pulls in someone else's changes that are not trivial, I involve that person in the merge.
Common sense? I think so. But I suspect that others have been down this road and can offer a more clearly elaborated, and "tried and true" approach for this general situation.