0

给定一个中央 mercurial 存储库和可以访问此存储库的多个团队，每个团队有时​​都必须将其更改同步到集中式存储库。

假设团队 A 和团队 B 处于状态并打算拉/合并/推送到集中存储库。

A pulls.
B pulls.
A merges
B merges.
B pushes. => A has to pull and merge again before pushing!

有没有（可能是技术上的）方法来避免这种冲突？也许某种锁？或者这是一个必须忍受的东西？:-)

顺便说一句，这种“冲突”在团队内部也发生在较小的范围内。但是由于团队成员在同一个房间里，一个人可以通过在房间里“大喊”他的意图来解决这个问题，以避免冲突。

4

2 回答 2

3

拉取时可能使用的最简单方法hg pull --rebase——这将在主存储库的更改之上重新设置本地更改并避免合并太多（尽管这实际上对 Mercurial 来说不是问题，但对于尝试的开发人员来说可能是个问题了解历史）。

在您的示例中，如果您更改B merges为B rebases，则 A 仍将不得不再次拉取并合并，但尝试遵循的未命名分支将会减少。

在任何情况下，无论是在拉动后变基还是合并，我都建议立即进行推送，以便所有人都可以使用更改。

但是，我想再次强调，这种“有问题的”场景只是因为给开发人员带来不便而存在问题。这实际上是 DVCS 之类的 Mercurial 旨在处理的工作流程。“标准”工作流程一直是在推送之前“拉取并合并/重新设置基准”——因此，如果您尝试在不合并的情况下推送，Mercurial 会警告您创建新的头。

于 2013-07-28T10:50:15.047 回答
1

通常你可以忍受它，恕我直言，以这种方式工作是常识。

您可以有一个解决方法，但它误用了分支的含义。

  • A 和 b 创建分支，保持tip/default/master 不变。
  • 两者都可以提交和推送他们的更改，但这将在中央存储库上创建分支。
    • 如果命名相同，这可能会导致严重的冲突，命名约定可能会有所帮助。
  • 某些人，主要是构建工程师或系统架构师，必须合并来自不同分支的更改。

如果两者都在同一个组件上处理不同的功能，这可能是一个好方法。

我建议您阅读本章http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html。

于 2013-07-28T10:47:06.813 回答