Svn 为团队合作设置Subversion

我以前有使用git的经验，但我是颠覆的新手。我的任务是为我的团队建立一个存储库，但不确定最佳结构应该是什么。（建议我回到git在这里是行不通的，因为我几乎被subversion困住了，但我很感激你诚实的建议！）

假设我的团队中有三个开发人员（Sam、Tom、Bob），他们每个人都需要自己的分支进行开发（他们向自己的分支提交，以便跟踪自己的更改和修订。我认为这是一个解决办法，因为subversion不像Git那样具有本地提交功能。subversion中的提交相当于Git中的推送。）.之后，他们将更改推到测试阶段，然后再进行生产。以下是我想到的结构：

MyProject
   /trunk
         /MyProject
   /branches
         /Test
         /Sam
         /Tom
         /Bob
   /tags

以下是工作流程： 在一天结束时（或在一天中），所有开发人员从测试分支提取更改，然后将其更改推送到测试分支，并在需要时解决冲突。对于生产更新，主干中的MyProject将与测试分支合并

让我们假设开发人员定期将他们的更改推送到测试分支，这样合并的尝试就不会导致灾难性的冲突

问题：
1.这是subversion团队项目的良好结构吗？
2.是否可以将开发人员分支的根指向测试分支？因此，当单击VisualSVN/Update时，开发人员分支将自动更新为测试分支的负责人。

只是（混乱的）思考

• 在

  /trunk

  中，MyProject是多余的节点（仅仅因为存储库专门用于MyProject）
• 在每个开发人员+稳定（主干）|不稳定（测试）分支中，您将得到大量的合并（因此-随时都可能成为“合并地狱”的受害者：您可以尝试避免上下文冲突，但在开发分支之间的双向合并期间，树冲突等待着您）
• “末日噩梦”（合并到测试+从测试中合并）需要严格的纪律、注意力和准确性（以及时间）
• 对于短期任务（单独提交），“共享分支”可能更好
• “每个任务的分支”而不是“每个开发人员的分支”提供了更易于理解的存储库树和可管理的开发+发布（对于与任务相关的短期分支，PM | TL可以随时监控状态-将其与“永远”开发人员的分支进行比较）。但它不会（必须）禁止对任何WIP使用个人“架子”
• 开发人员可能希望尝试按需使用直接跨分支合并，而不是使用中间测试分支进行同步（但无论如何请参见第2页）