1

语境

我们开发了许多插件，这些插件被组装到 Eclipse RCP 3.X 应用程序中。我们使用基于 P2 存储库的单一目标平台，因为这是 Tycho 支持的唯一版本。

目标平台 VS SCM

我们的互联网访问受到很大限制。即使我们配置了代理，我们也无法访问公开可用的 P2 存储库。因此，我们下载 P2 存储库 zip 并将它们放入源代码控制中，以便团队可以共享它们并进行版本控制。但是，我们认为在 SCM 下具有二进制内容通常是一种不好的做法。

我们正准备从 ClearCase 迁移到 Git。在这样做的同时，我们正在考虑更好地改变我们管理目标平台的方式。我们已经考虑过不同的场景，但我们缺乏经验来衡量它们的优缺点。以下是我们反思的第一个结果：

场景 1：为目标平台使用单独的 Git 存储库

  • 优点：
    • 插件是共享的
    • 我们稍后可以回到目标平台的“物理”先前版本
    • 更改目标平台就像操作文件一样简单
  • 缺点：
    • SCM 中的二进制文件
    • 每个存储库实例使用大量磁盘来保存目标平台的整个历史记录

场景 2：将 Nexus 与插件一起用于 P2 存储库管理

  • 优点：
    • 插件是共享的
    • 轻量级存储库：只foo.target需要对文件进行版本控制
  • 缺点：
    • 我们以前从未使用过 Nexus
    • 更改目标平台内容更复杂
    • 我们需要手动保存目标平台内容的每个版本的存档副本

问题

您如何在封闭的企业网络中使用 Git 处理目标平台版本控制？您如何看待上述情况及其各自的优缺点？你能建议其他解决方案吗？

4

1 回答 1

1

使用 Nexus 和Nexus Unzip Plugin，有一个非常好的解决方案可以满足您拥有可重现的目标平台和独立于 Internet 访问构建的需求：

  • 设置 Nexus，并确保您有一个可以部署到的 m2 存储库，例如使用deploy-file。
  • 将您需要的 p2 存储库下载为 zip 存档（如果这些 zip 存档不提供下载，则自行创建这些存档）。
  • 使用非 SNAPSHOT 版本将压缩的 p2 存储库部署到 Nexus m2 存储库。Nexus 中的非 SNAPSHOT 工件是不可变的，因此当您通过它们在 Nexus 上的 URL 引用 p2 存储库时，您将始终获得相同的内容。
  • 安装Nexus 解压缩插件并将其配置为“影子”/提供您已部署到的存储库中的内容。通过这种方式，压缩的 p2 存储库获得一个“解压缩” URL，使它们看起来像 Eclipse 和/或 Tycho 的常规 p2 存储库。
  • 最后，在 Nexus 中创建一个仅引用 p2 存储库的目标定义文件，并将该文件放入您的 git 存储库。

很长一段时间以来，我们已经在公司环境中非常成功地使用此设置，因此我建议您也尝试这种方法。

这类似于您的解决方案 2，但使用不同的 Nexus 插件。对于所描述的解决方案，您不需要任何插件来明确“p2 存储库支持”。此外，您不需要对目标平台内容进行任何额外的归档。

免责声明：Nexus Unzip 插件由 Tycho 项目提供，我是该项目的提交者。

于 2014-07-14T17:45:54.770 回答