问处理多个subversion项目之间的关系

EN

您可以使用svn:externals来处理这个问题。这是svn中某个点的url，它允许您提取不同存储库(或同一个存储库)的部分内容。使用它的一种方法是在project 2下添加一个svn:externals链接到您需要的基础设施分支、您需要的app1分支等等。因此，当您签出project 2时，您将得到所有正确的部分。

svn:externals链接与其他所有链接一起都是版本化的，因此当1被标记、分支和更新时，正确的外部分支总是会被拉进来。

是啊，糟透了。我们做同样的事情，但我真的想不出更好的布局。

因此，我们所拥有的是一组脚本，它可以自动化所有与subversion相关的内容。每个客户的项目将包含一个名为project.list的文件，其中包含构建该客户所需的所有subversion项目/路径。例如：

Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk

然后，每个脚本看起来都是这样的：

for PROJ in $(cat project.list); do
    # execute commands here
done

其中的命令可能是签出、更新或标记。它比这要复杂一些，但它确实意味着一切都是一致的，签出、更新和标记成为一个单一的命令。

当然，我们尽量少做分支，这是我能提出的最重要的建议。如果我们需要分支某些东西，我们将尝试离开主干或尽可能多的依赖项的先前标记的版本。

建议将目录布局更改为

• 基础设施
  • 分支
  • 标签
  • 中继线

​

• 客户项目-1
  • 分支
  • 标签
  • 中继线

​

• 客户项目-2
  • 分支
  • 标签
  • 中继线

​

至

• 分支
  • 特征-1
    • 基础设施
    • 面向客户的项目-1
    • 面向客户的项目-2

​

​

• 标签
• 主干
  • 基础设施
  • 面向客户的项目-1
  • 面向客户的项目-2

​

这个布局也有一些问题。分支变得庞大，但至少在代码中标记特定位置更容易。

要处理代码，只需签出主干并使用它。那么，您就不需要检查所有不同项目的脚本了。他们只是用“./ Infrastructure”来指基础设施。这个布局的另一个问题是，如果您想完全独立地处理项目，则需要签出几个副本。否则，一个项目的基础设施更改可能会导致另一个项目在更新之前不会编译。

这可能也会使发布更加繁琐，并将不同项目的代码分离开来。