Currently we have 3 branches and trunk.  If a developer makes a change in one branch, they alone are responsible from merging that change to the 3 other branches and eventually back to trunk.  There's a published chart on the merge order that gets updated periodically.So, we have lots of little merges happening across branches.  In the past, we have had one person cut branches and do merging back, mainly from branch to trunk.  If there is a conflict, the 2 or 3 developers who caused the file conflict would resolve it.  The branch and merging strategy was handled by an individual and mainly involved bring branches back to trunk.Is having individual developers merge typical?  Or should it be handled by one person and coordinated at specific intervals to manage the branches?
Should developers merge code across branches?
version control;merging
What concerns me here is that you make it sound like anyone checking in code has to blindly check it in to multiple branches.  That is wrong.  Branches should exist for a reason.  The event of checking in code should happen once and flow from there.  Who gets it flowing isn't as important as that branches are kept meaningful and useful in each step.It sounds to me like you had a better approach in the past.  The question then is: why did that change?