Question

我们理解默认情况下，通常建议的svn存储库组织，如果有多个项目，则是这样的：

root/projectA/(trunk, branches, tags)
root/projectB/(trunk, branches, tags)
...

我们的项目有很多相互依赖性，并且需要在它们之间大量使用 svn：externals ，考虑到我们没有参考内部项目的dll，我们更愿意查看他们的源代码，而不是使用二进制文件。

使用外部因素太多，在分支存储库时，同步更改可能会变成一个复杂且容易出错的体验，因此团队根本不相信这个解决方案。

因此，团队成员建议我们都认为这可能是一个更好的解决方案：将所有项目放在同一个主干中。

起初，我们认识到这种方法存在一些问题，但总的来说，我们认为这些问题是基于我们很可能从未经历过的低位情况。

您是否看到我们对此解决方案可能遇到的一些严重问题？

Answer 1

我们在公司做到这一点并取得了很大的成功。

我们有3个顶级目录：

标记
分支
躯干

然后我们将每个项目作为这些项目的子目录。

我们仍然在项目级别进行分支，但仍使用svn：externals。但是如果我们有一个较小的源代码树，我们将在trunk级别进行分支而不使用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是一个绝对的噩梦。

Answer 2

您所做的就是我在公司设置的内容，并且在svnbook主题Strategies for Repository Deployment中也被称为“非常常见的布局”。

没有错。

Answer 3

将“所有项目放入同一主干”：

根据我的经验，这不是一个好主意 - 因为每个项目都有自己的历史和变化，并且通常项目由不同的开发人员维护。这可能会导致冲突 - 即使您声明，目前项目会严重干扰。

那么为什么不为所有项目使用通用标记（里程碑作为名称）来确保相同的代码库和构建脚本，这可以自动检出项目（中继）？这是更多的工作，但像OOP（封装）一样，我宁愿将项目拆分为单独的SVN目录。

但是：将一堆小的lib和应用程序收集到同一主干下的公共目录中是没有问题的（参见下面的例子中的“apps”和“tools”） - 所以也许“小项目”可以保留在共享中/ big trunk。

这里举例说明我的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书和之前的帖子中所建议的那样。

即使这看起来有点乍一看 - 这确实是值得的，特别是当您的代码库增长时。

侨，克里斯

Answer 4

你看到我们遇到了一些严重的问题可能有这个解决方案？

您的解决方案只有在您将所有内容整合到一起时才有效库中。

这意味着在可预见的未来，整个存储库必须适合单个磁盘（或存储池）。类似的考虑适用于其他服务器资源，如网络和磁盘I / O带宽。

以后拆分存储库需要对整个设置进行大修，并且在需要重建或分支旧版本时可能会引起麻烦。

只有在您不需要限制每个用户的读/写权限时，您的解决方案才有效

如果您需要为projectA提供读/写权限，您实际上必须为/ trunk / projectA，/ branch1 / projectA和/ branch2 / projectA等授予权限。

分支然后变成一个重量级的过程，需要大量的权限调整。告别feature branches。

将所有项目放在同一个主干中是个好主意吗？

4 个答案: