Currently our model, with respect to SVN and automated build, looks like
Which, as far as I know, wasn't the way SVN was meant to be used. But the process works okay from a technical standpoint. The goal is to be able to run these chains in parallel, with different people working on new features, others fixing new bugs and regressions, and somehow responding to client feedback.
The difficulty comes in explaining it, even to people who have been around for a while, and usually after someone messes it up and changes one of these steps to something that makes more sense to them (ie using the latest release build for internal testing and sending archived releases to client QA).
I didn't set the policy but I understand what it is, so I'm one of the people who has to explain/maintain it. Having done so many times over the last year, it seems like it doesn't meet the principle of least astonishment.
How could we make this process more obvious/boring?