我们理解默认和通常推荐的svn存储库组织，在有多个项目的情况下，是这样的：
root/projectA/(trunk, branches, tags)
root/projectB/(trunk, branches, tags)
...
我们的项目有很多相互依赖，这将需要在它们之间广泛使用 svn:externals，考虑到我们不做 dll 引用内部项目，我们更愿意查看他们的源代码，而不是使用二进制文件。
过多地使用外部，当分支存储库、同步更改时，可能会变得复杂且容易出错，因此团队根本不信任这个解决方案。
因此，一位团队成员提出了一些我们都认为这可能是更好的解决方案的建议：将所有项目放在同一个主干中。
起初，我们认识到这种方法存在一些问题，但总的来说，我们同意这些问题是基于我们很可能从未经历过的假设情况。
您是否发现此解决方案可能存在一些严重问题？
【问题讨论】：
我们公司就是这样做的，并且取得了很大的成功。
我们有 3 个顶级目录：
然后我们将每个项目作为它们的子目录。
尽管如此，我们仍然在项目级别进行分支，并且仍然使用 svn:externals。但是如果我们有一个较小的源代码树，我们会在主干级别分支而不使用 svn:extenrals。
很高兴能够将所有项目的主干放在同一个地方。你可以备份它，你可以检查它，你可以把所有最新的东西放在一起。您不会丢失所有分支的单个位置，也不会丢失所有标签的单个位置，因为它们都位于 /branches/projectX 和 /tags/projectX 的子目录中
svn:externals 的问题：
如果你的项目不是特别庞大，那么你可以每次只分支整个主干，避免 svn:externals 的所有问题。
svn:externals 的问题是当你创建一个分支时，它不会自动为你的每个 svn:externals 创建一个分支。这是一个问题，因为随着时间的推移，随着主干的更新，所有旧分支都将无法编译。另一个问题是，如果您在 svn:external 的任何分支中进行修复，所有其他分支都会中断。
svn externals 的另一个问题是，当您在根级别执行 svn:log 时，您看不到 svn externals 的任何更改。
希望有一天 svn externals 能够解决上述问题，但在那一天之前，分支和 svn:externals 绝对是一场噩梦。
【讨论】：
你所做的就是我在我公司设置的，在svnbook话题Strategies for Repository Deployment中也被称为“非常常见的布局”。
没有错。
【讨论】：
到“将所有项目放入同一个主干”：
根据我的经验，这不是一个好主意 - 因为每个项目都有自己的历史和变化，而且项目通常由/将由不同的开发人员维护。这可能会导致冲突 - 即使您声明，当前项目干扰很大。
那么，您为什么不对所有项目使用通用标签（以里程碑作为名称）来确保相同的代码库和构建脚本，它可以自动检查项目（主干）？这需要更多的工作，但像往常一样在 OOP（封装）中我更愿意将项目拆分到单独的 SVN 目录中。
但是：将一堆小库和应用程序收集到同一个主干下的公共目录中是没有问题的（请参阅下面我的示例中的“应用程序”和“工具”） - 所以也许“小项目”可以留在共享中/大树干。
这里以我的SVN目录结构为例：
/projects/
/projects/CustomerA/
/projects/CustomerA/ProjectX/
/projects/CustomerA/ProjectX/trunk/
/projects/CustomerA/ProjectX/tags/
/projects/CustomerA/ProjectX/branches/
/thirdparty/
/thirdparty/ExtLibY/
/thirdparty/ExtLibZ/
/tools/
/tools/trunk/
/tools/tags/
/tools/branches/
/apps/
/apps/trunk/
/apps/tags/
/apps/branches/
所以所有外部内容都存储在 /thirdparty/ 中，所有内部（项目、工具、应用程序）都有子目录：
/trunk/
/tags/
/branches/
...就像 Subversion 书和上一篇文章中建议的那样。
即使乍一看有点费劲 - 这确实是值得的，尤其是当您的代码库增长时。
乔， 克里斯
【讨论】：
您是否发现我们存在一些严重的问题 可能有这个解决方案？
您的解决方案只有在您可以将所有内容放在一个单一的情况下才有效 存储库。
这意味着在可预见的未来，整个存储库必须适合单个磁盘（或存储池）。类似的考虑适用于其他服务器资源，例如网络和磁盘 I/O 带宽。
稍后拆分存储库将需要对您的整个设置进行大修，并且在您需要重建或分支旧版本时可能会令人头疼。
只有在您不需要限制每个用户的读/写权限时，您的解决方案才有效
如果您需要授予 projectA 的读/写权限，您实际上必须授予 /trunk/projectA、/branch1/projectA 和 /branch2/projectA 等权限。
然后，分支成为一个需要大量权限调整的重量级过程。告别feature branches。
【讨论】：