推与拉
背景：
我自己以单一用户的身份使用 Mercurial 来跟踪我对自己的代码所做的更改，并且我认为我已经熟悉了基础知识。不过，我现在即将开始与实验室中的其他人一起开发一个软件项目，并希望确保我了解如何与使用 Mercurial 的其他人正确共享代码。
我们的情况如下：我们都在 Linux 集群的共享卷（即不同路径）中拥有自己的存储库，并且我们都对自己的存储库和彼此的存储库具有读写访问权限。
为了讨论的目的，我们可以将这两个存储库称为：Bob 和 Alice 的存储库。
我的理解是，有多种方法可以让 Bob 和 Alice 共享他们的代码，其中两种方法如下：
选项 1：通过拉动
- Bob 拉动 每当 Alice 想要看到她的更改时进行
- 共享类似地，每当爱丽丝想要看到鲍勃的变化时，她就会拉开鲍勃。
选项 2：通过推送进行共享
- 每当 Bob 想与 Alice 共享他的更改时，他就会主动推送他的更改到 Alice 的存储库中。
- 同样，每当 Bob 想与 Alice 分享他的更改时，Alice 就会主动推送她的更改到 Bob 的存储库中。
问题：
根据在线阅读 Mercurial 文档和教程，我的解释是，上面的第一个选项通常比第二个选项更受青睐。我的一个问题是为什么？
上面的第二个选项会导致任何问题吗？如果 Bob 提交到他自己的存储库中，而 Alice 也同时将她的更改推送到 Bob 的存储库中，会发生什么情况？
谢谢
Background:
I have used Mercurial myself as a single user to keep track of the changes I make to my own code, and I think I am already familiar with the fundamentals. However, I am now about to start working on a software project with somebody else in my lab and want to make sure I understand how to properly share code with somebody else using Mercurial.
Our situation is the following: We both have our own repository in a shared volume (i.e. different paths) in a Linux cluster, and we both have read and write access to our own and each other's repositories.
We can call these two repositories: Bob's and Alice's repositories for the purpose of the discussion.
My understanding is that there are multiple ways of having Bob and Alice share their code, two of them being the following:
Option 1: Sharing via pulling
- Bob pulls from Alice whenever he wants to see her changes
- Similarly, Alice pulls from Bob whenever she wants to see his changes.
Option 2: Sharing via pushing
- Bob pro-actively pushes his changes into Alice's repository whenever he wants to share his changes with her.
- Similarly, Alice pro-actively pushes her changes into Bob's repository whenever he wants to share his changes with her.
Questions:
My interpretation from reading the Mercurial documentation and tutorials online is that the first option above is usually preferred over the second one. One question I have is why?
Can the second option above lead to any problems? What would happen if Bob commits into his own repository while Alice also pushes her changes simultaneously into Bob's repository?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
两者都有效，但最终并不重要，因为推/拉不会为接收者执行
更新或合并——它只是将变更集移动到底层存储库，而不是进入工作目录。第一个选项，拉取，更常见，因为：
hg Summary（或hg Heads或hg log）后才会发现它，然后他们必须hg 合并。因此，只要收件人必须采取明确的操作（检查和合并）来获取您的更改，他们也可能只是拉取和合并。这对他们来说不再是工作，对你来说则更少。正如其他人指出的那样，存储库写查看将阻止在传入的推或拉操作期间提交。
Either works and in the end it really doesn't matter because pushing/pulling doesn't do the
updateor themergefor the recipient -- it just moves changeset into the underlying repo, not into the working directory.The first option, pulling, is more commonly done because:
hg summary(orhg headsorhg log) and then they'll have tohg merge. So as long as the recipient has to take an explicit action (check and merge) to get your changes they may as well just pull and merge instead. It's no more work for them and less for you.As others have pointed out a repository write-look will prevent commiting during incoming push or pull operations.
根据我对 Hg 文件模型的了解，它可以优雅地处理并发写入，因此文件损坏不是问题。
这个问题更多的是关于工作流程。不存在“同时”，因为后面的写操作将被阻塞，直到前面的写操作完成为止。如果 Bob 的提交较早，那么 Alice 的推送将（默认情况下）失败，因为它将创建一个新头。她必须强制推动在鲍勃的存储库中创建一个新头，然后他必须合并它们。或者她可以拉出鲍勃的更改并合并然后推送。如果 Alice 的推送较早，那么 Bob 的提交将会通过，创建一个他必须合并的分支。无论哪种方式，合并都必须发生。我不喜欢这种方法的是，Bob 现在会对他的存储库中的这些新变更集感到惊讶，并且无论如何他都必须进行 hg update 以将它们带入他的工作副本中。
我们在 4 人团队中使用的模型是拥有一个中央存储库，每个人都可以从中拉取/推送。这也是我们的 CI 服务器运行自动化构建的地方。到现在已经 11 个月了，一切进展顺利。
From what I've read about Hg's file model, it handles concurrent writes elegantly so file corruption is not an issue.
The issue is more about workflow. There is no "simultaneous" because the later write operation will be blocked until the earlier write operation finishes. If Bob's commit is earlier, then Alice's push will (by default) fail because it would create a new head. She would have to force push to create a new head in Bob's repo and then he would have to merge them. Or she can pull Bob's change and merge then push. If Alice's push is earlier, then Bob's commit will go through, creating a branch that he will have to merge. Either way, a merge is gonna have to happen. What I don't like about this approach is that Bob is now going to be surprised by these new changesets in his repo and he'll have to do hg update to bring them into his working copy anyways.
The model we use on our team of 4 is to have a central repo that everyone pulls/pushes from. This is also where our CI server pulls to run automated builds. This has worked pretty smoothly for 11 months now.
Mercurial 可以轻松处理这两种情况。对我来说，选项一是首选，因为它更容易维护。如果 Alice 不希望 Bob 的更改推送到她的存储库中怎么办？然后她就必须经历拒绝他的推动的麻烦。如果 Alice 想要拉取 Bob 的更改，她显然已经同意拉取和由此产生的合并，并且正在期待它。她很可能会在与主存储库合并之前拉入一个单独的存储库，以确保她确实想要集成他的更改。
也许只有我一个人这么认为，但把改变推给别人感觉很肮脏。我宁愿让他们知道有可用的更新，如果他们感兴趣，他们可以从您那里获取更改。
话虽这么说，我们在办公室处理它的方式是将大部分代码推送到每个人都可以访问的中央存储库。通过代码审查获得批准后，这些更改将被推送到我们真正的存储库中，并可供其他人使用。只有在相当罕见的情况下，开发人员才会直接将代码推送给彼此，并且通常发生在他们密切合作开发同一功能时。
Mercurial easily handles both scenarios. To me option one is preferred because it's easier to maintain. What if Alice doesn't want Bob's changes pushed into her repo? Then she has to go through the trouble of backing out his push. Where as if Alice wants to pull Bob's changes, she has clearly given consent to the pull and resulting merge, and is expecting it. Chances are she will pull into a separate repo before merging with her primary repo to ensure she actually wants to integrate his changes.
Maybe it's just me, but pushing changes onto someone else feels dirty. I would much rather let them know an update is available, and if they are interested they can pull the changes from you.
That being said, the way we handle it here in the office is to push most code to a central repo that everyone has access to. After it gets approved via code review, those changes get pushed into our real repo and become available for everyone else to pull. It's only in fairly rare circumstances that developers would push code to one another directly, and usually occurs when they are working closely on the same feature.