I think in an ideal dream the Project Manager would be able to create a work breakdown structure that would reflect granular components that could be checked out by the appropriate party(ies). This would make it easy to report status of progress if executed properly. Make the project architecture conform to branching off from the trunk for the developer(s) assigned to it checking and merging back a seamless operation. Along with the defect DB being tied into the mix so QA would be included at the very beginning of the project. I would totally implement the constraints of making a bug # and a message mandatory.
I'm a novice at the dev svn environment but from what experience I do/did have I know the primary hurdles are:
-Conflicts when merging
-GWT(anything that evloves) versioning and upgrades scenarios
I know my routine would be;
Checkout // Yes, GWT is part of the core put it in the repo and have your team on a start your day routine.
Branch // Work on WBS's that have been split up for efficiency
Update // Always note what and why with reference to anything applicable
I guess apply standards to all the svn methods...Add=Must, should, format etc....
Everyone should be on the same page, when I change occurs run the drill that you've put in place, a good design would account for everything you mentioned.