使用 Subversion，如何管理多项目存储库中的组件版本？答案

【问题标题】：with Subversion, how to manage version of component in a multiproject repository?使用 Subversion，如何管理多项目存储库中的组件版本？
【发布时间】：2011-10-28 09:18:00
【问题描述】：

想象一下这样的存储库组织：

/Project1/branches
          /tags/Rel-1.0
          /trunk
/Module1/branches
           /tags/Rel-1.0
           /tags/Rel-1.1
           /tags/Rel-2.0
           /trunk
/Module2/branches
           /tags/Rel-1.0
           /tags/Rel-1.1
           /tags/Rel-1.2  
           /tags/Rel-1.3
           /tags/Rel-2.0
           /tags/Rel-2.1         
           /trunk

project1 正在使用 Module1 和 Module2。 project1的1.0版本是使用Module1和Module2的1.0版本完成的。

project1 的新版本（例如命名为 1.1，不是重大演变）是通过使用 Module1 的 Release 2.0 和 Module2 的 2.1 完成的。

如何使用颠覆来做到这一点。

【问题讨论】：

标签： svn version-control project-organization

【解决方案1】：

我会尝试解决 SVN 之外的依赖管理（想想 Javaverse 中的 Apache Maven 或 Ivy）。

如果必须是SVN，特殊标签名称如何？因此，您可以引入一个约定，让您的构建系统在特殊文件夹中查找它所依赖的版本，例如 /Module1/branches/deps/Project1/Rel-1.0 用于您的 Project1 的 Rel-1.0 构建所需的代码。

/Project1/branches
          /tags/Rel-1.0
          /trunk
/Module1/branches
           /tags/Rel-1.0
           ...
           /tags/Rel-2.0
           /deps/Project1/Rel-1.0
           /deps/Project1/Rel-1.1
           /trunk
/Module2/branches
           /tags/Rel-1.0
           ...
           /tags/Rel-2.1         
           /deps/Project1/Rel-1.0
           /deps/Project1/Rel-1.1
           /trunk

您可以通过引用标签文件夹来为家属创建文件夹：

# dependencies to Module1
svn cp http://myServer/svn/Module1/branches/tags/Rel-1.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.0
svn cp http://myServer/svn/Module1/branches/tags/Rel-2.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1
# dependencies to Module2
svn cp http://myServer/svn/Module2/branches/tags/Rel-1.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.0
svn cp http://myServer/svn/Module2/branches/tags/Rel-2.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1

稍后切换版本看起来像

# delete old reference
svn rm http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1
# make other one for new version
svn cp http://myServer/svn/Module1/branches/tags/Rel-2.1 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1

这种方法的缺点可能是 SVN 工作目录需要更多空间。

【讨论】：

我的项目使用 C++。一些组件也是第三方库。我的第一个目标是为存储库找到最好的项目和图书馆组织。我的第二个目标是看看在 SVN 下我是否可以轻松了解和自动管理应用程序是如何组成的（嵌入了哪些模块以及使用哪个版本）
我猜这种方法的问题是，SVN 不是为这些东西而构建的。您将必须创建一些自己的构建过程（无论是使用 make、cmake 还是其他东西），从 Repo 或工作副本中读取元数据并相应地构建正确的东西。至少可以通过 XML 很好地完成读取（例如命令行上的svn ls --xml http://server/repo/path/to/list）。另一种方法可能是您将文件放在项目或模块的路径中，描述它的当前依赖项。这又可以被构建工具读取并采取行动。
我完全忘记了显而易见的解决方案：如果您使用像 make 这样的构建工具，您已经有了一个受版本控制的文件，您可以将依赖项描述放入：makefile。 .. :o)

【解决方案2】：

我建议通过将每个“实体”（项目、模块 1、模块 2、...、ModuleN）拆分为单独的存储库来重组存储库，并在项目存储库中对所有模块使用 svn:externals，而不是直接嵌入代码。

在开发阶段，externals 指的是外部 repo 的 HEAD，在 Project 的每个版本中（标记为特殊标签，是吗？）在标记 Project 之前，您必须编辑并冻结包含模块的某些固定修订版本的外部。

专业版

您会将开发历史记录（根据 SVN）分成独立的子部分
对于每个标记的版本，模块的链接版本都很容易识别
repos 将拥有更简单的代码树
/忘记了什么/

反对

由于存在分叉点，项目历史将不透明，并且使用古老的修订版（分叉之前）会让人（可能会）有些头疼

【讨论】：