推拉与拉动

Question

背景

我自己使用Mercurial作为单个用户来跟踪我对自己的代码所做的更改，我想我已经熟悉了基础知识。但是，我现在即将开始与我的实验室中的其他人一起开展软件项目，并希望确保我了解如何使用Mercurial与其他人正确共享代码。

我们的情况如下：我们在Linux集群中的共享卷（即不同的路径）中拥有自己的存储库，我们都拥有对自己和对方的读写权限库。

我们可以将这两个存储库称为： Bob 和 Alice 的存储库，以便进行讨论。

我的理解是Bob和Alice分享他们的代码有多种方式，其中两种方法如下：

选项1：通过拉动共享

• 鲍勃从爱丽丝那里拉，只要他想看到她的变化
• 同样，只要她想看到他的变化，Alice 就会从Bob那里拉。

选项2：通过推送分享

• 当他想与她分享他的更改时，Bob主动将的更改推送到Alice的存储库中。
• 同样，只要爱丽丝想要与她分享他的更改，他就会主动将她的更改推送到Bob的存储库中。

问题：

我在线阅读Mercurial文档和教程的解释是，上面的第一个选项通常比第二个选项更受欢迎。我有一个问题是为什么？

上面的第二个选项会导致任何问题吗？如果Bob 提交进入他自己的存储库会发生什么情况，而Alice也同时将她的更改同时推送到Bob的存储库中？

由于

Answer 1

无论是作品还是最终都没关系，因为推/拉不会为收件人执行update或merge - 它只是将变更集移动到底层仓库中，不要进入工作目录。

第一个选择，拉动，更常见的原因是：

• 通常你没有对彼此的回购（也可能不应该）的写入权限，而且你只需要对彼此的回购进行读取访问
• 当您将更改集推送给某人时，没有通知他们他们收到了新的更改集。他们在hg summary（或hg heads或hg log）运行之前不会发现它，然后他们必须hg merge。因此，只要收件人必须采取明确的操作（检查和合并）来获取您的更改，他们也可以只是拉动和合并。这对他们来说不再有用，对你来说也没什么用。

正如其他人指出的那样，存储库写入将阻止在传入的推送或拉取操作期间进行提交。

Answer 2

从我读过的有关Hg文件模型的内容来看，它优雅地处理并发写入，因此文件损坏不是问题。

问题更多是关于工作流程。没有“同时”，因为稍后的写操作将被阻止，直到较早的写操作完成。如果Bob的提交时间较早，那么Alice的推送（默认情况下）会失败，因为它会创建一个新头。她将不得不强迫推动在鲍勃的回购中创造一个新的头，然后他将不得不合并他们。或者她可以拉鲍勃的变化然后合并然后推动。如果Alice的推送时间较早，那么Bob的提交将会通过，创建一个他必须合并的分支。无论哪种方式，合并都必须发生。我不喜欢这种方法的是，鲍勃现在会对他的回购中的这些新变更感到惊讶，他不得不做hg更新，无论如何都要将它们带入他的工作副本。

我们在4人团队中使用的模型是拥有一个每个人都拉/推的中央回购。这也是我们的CI服务器用于运行自动构建的地方。这已经持续了11个月非常顺利。

Answer 3

Mercurial可轻松处理这两种情况。对我来说，选择一个是首选，因为它更容易维护。如果爱丽丝不希望鲍勃的变化被推入她的回购怎么办？然后她必须经历退出他的推动的麻烦。好像爱丽丝想要拉鲍勃的变化，她已经明确同意拉动并产生合并，并期待它。在与她的主要回购合并之前，她可能会进入一个单独的回购，以确保她真的想要整合他的变化。

也许这只是我，但推动变革给别人感觉很脏。我宁愿让他们知道有更新可用，如果他们感兴趣，他们可以从你那里获取更改。

话虽这么说，我们在办公室处理它的方式是将大多数代码推送到每个人都可以访问的中央仓库。在通过代码审查获得批准后，这些更改将被推送到我们的真实仓库中，并可供其他人使用。只有在相当罕见的情况下，开发人员才会直接将代码推送到彼此，并且通常在他们密切合作相同功能时发生。