1. It will stop work rather fast in real development
2. Developers will get "Merge Hell" even before p.1 (read about "Cyclic merges" /and you'll have it, sure/ in SVN samples and some other "glithes", not real troubles)
3. Locking will be long-time process for real code-base (read carefully svn help lock) and add nothing valuable into well-organised process (well separated code)

Your (personally yours, nor team nor suggested procedure) biggest problem from my POV is your state - I suppose, you aren't programmer or at least coder, but "manager", thus can't see map of rack in your "workflow" (SVN-related and not related). We, in Russia, have good saying for such cases (poorly translated by me, sorry): "It was smooth on paper, but they forgot about the ravines: how to walk on them"

1. It will stop work rather fast in real development
2. Developers will get "Merge Hell" even before p.1 (read about "Cyclic merges" /and you'll have it, sure/ in SVN samples and some other "glithes", not real troubles)
3. Locking will be (mostly useless) long-time process for real code-base (read carefully svn help lock) and add nothing valuable into well-organised process (well separated code)

Your (personally yours, nor team nor suggested procedure) biggest problem from my POV is your state - I suppose, you aren't programmer or at least coder, but "manager", thus can't see map of rack in your "workflow" (SVN-related and not related). We, in Russia, have good saying for such cases (poorly translated by me, sorry): "It was smooth on paper, but they forgot about the ravines: how to walk on them"