Vic*_*ues 5 svn project-organization
我们理解默认和通常推荐的svn存储库组织,如果有多个项目,则是这样的:
root/projectA/(trunk, branches, tags)
root/projectB/(trunk, branches, tags)
...
我们的项目有很多相互依赖性,这需要在它们之间大量使用svn:externals,考虑到我们不会引用内部项目,我们更愿意查看它们的源代码而不是使用二进制文件.
使用外部因素太多,在分支存储库时,同步更改可能会变成一种复杂且容易出错的体验,因此团队根本不相信这种解决方案.
因此,团队成员建议我们都认为这可能是一个更好的解决方案:将所有项目放在同一个主干中.
起初,我们认识到这种方法存在一些问题,但总的来说,我们认为这些问题是基于我们可能从未体验过的低位情况.
您是否看到我们对此解决方案可能遇到的一些严重问题？
我们公司就是这样做的，并取得了很大的成功。
我们有 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 绝对是一场噩梦。
| 归档时间： |
|
| 查看次数： |
475 次 |
| 最近记录： |