gpt4 book ai didi

svn - Mercurial - 如何管理多个模块

转载 作者:行者123 更新时间:2023-12-02 05:19:21 24 4
gpt4 key购买 nike

我在一个使用 Subversion 的团队中工作,我们正在考虑切换到 Mercurial。

我们有多个单独的代码项目,以及一些项目之间共享的代码。为简单起见,假设有 2 个项目,SpaceGameSeaGame,它们都使用来自 GraphicsEngine 的代码。 GraphicsEngine 的开发在某种程度上独立于游戏。假设我们需要将 SpaceGame 更新到几个月前的修订版 467; SpaceGame 需要返回到版本 467,GrpahicsEngine 需要返回到 SpaceGame 为 467 时的版本,GraphicsEngine 不能停留在最新版本。我们可以使用 Subversion 实现这一目标的唯一方法是将我们所有的项目都放入一个大存储库中(外部不会为我们提供我们需要的行为)。但是,这给我们的团队带来了很多问题; repo 协议(protocol)很大,几乎没有人愿意对其进行全面检查,他们只检查他们需要的项目。

如何使用 Mercurial 处理这种情况?

最佳答案

这听起来像是 Mercurial subrepositories 的用例.

这意味着您可以将 GraphicsEngine 作为子存储库放入 SpaceGame 中。
(或者如果您遵循 the recommended structure,创建一个包含 GraphicsEngineSpaceGame 和子存储库的精简“包装器”存储库)

子存储库的工作方式,SpaceGame 并不总是包含最新版本的 GraphicsEngine...它指向某个固定的修订版,如果 GraphicsEngine 同时更新,SpaceGame 不会自动获取这些更改...您必须进行显式更新才能获取它们。
这意味着 SpaceGame 永远不会因为其他人对 GraphicsEngine 的更改而意外中断。

这也意味着(这就是您所询问的),当您将 SpaceGame 更新为“几个月前的修订版 467”时,GraphicsEngine 子存储库 is automatically updated to the revision that it was at when SpaceGame was at 467 .


编辑:

不,GraphicsEngine 仍然是一个独立的存储库,不为任何人“拥有”。
如果您将它用作子存储库,它只是从父存储库“链接”(并且它可以从多个父存储库链接)。它仍然是一个单独的存储库。

有了子存储库,这样的事情是可能的:

GraphicsEngine      // main GraphicsEngine repo, current revision: 300

SpaceGame // main SpaceGame repo
└ GraphicsEngine // GraphicsEngine subrepo, current revision: 265

SeaGame // main SeaGame repo
└ GraphicsEngine // GraphicsEngine subrepo, current revision: 241

SpaceGameSeaGame 都有一个 GraphicsEngine 子库。
每个子代码库“指向”GraphicsEngine 的某个修订版(在我的示例中为 265 和 241)。
GraphicsEngine 的开发仍在继续(GraphicsEngine 的版本为 300),但最近的更改在 SpaceGameSeaGame< 中不可见 因为它们都指向旧的 GraphicsEngine 修订版。

关于svn - Mercurial - 如何管理多个模块,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14135644/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com