通过电子邮件将 Mercurial 存储库与捆绑包同步的工作流程 [英] Workflow to synchronise Mercurial repositories via email with bundles
问题描述
我在两台不同的计算机上有两个目录 - 机器 A (Windows) 和机器 B (OSX) - 我想通过 Mercurial 使这两个目录保持同步.[*]
I have two directories on two different computers - machine A (Windows) and machine B (OSX) - and I want to keep the two directories via Mercurial in sync. [*]
限制是两台机器不通过LAN/WAN连接；在它们之间移动数据的唯一方法是通过电子邮件.所以我认为通过电子邮件发送 Mercurial 捆绑包 作为 deltas 可以解决问题.
The restriction is that the two machines are not connected via LAN/WAN; the only way to move data between them is via email. So I thought emailing Mercurial bundles as deltas could do the trick.
我目前的工作流程大致是这样的(使用本地标签 lcb 获取最新的更改包):
My current workflow is roughly this (using a local tag lcb for the latest change bundle):
假设我在机器 A 上工作.在一天结束时，我会这样做:
Say I work on machine A. At the end of the day I do:
hg commit -A -m "changes 123"
hg bundle --base lcb bundle_123.hg
hg tag --local -f lcb --rev tip
最后，我将该捆绑包通过电子邮件发送到机器B.
finally then I email that bundle to machine B.
然后坐在机器上B我愿意
hg unbundle bundle_123.hg
hg merge
hg commit -A -m "remote changes 123"
hg tag --local -f lcb --rev tip
现在我在机器 B 上工作，最终我会做 1. 下列出的事情，但在机器 B 上工作.循环继续……
Now I'm working on machine B and at the end of the day I do what's listed under 1., but on machine B. And the cycle continues...
但是，我担心这个系统不够健壮:
However, I'm worry this system is not robust enough:
中间更改:之后创建捆绑包(步骤 1)和之前远程应用它(步骤2)远程机器B上发生了变化?我有一个案例，它只是用新包覆盖了更改，没有冲突警告或合并建议.
In-between changes: What happens when after creating a bundle (Step 1) and before applying it remotely (Step 2) a changes occurrs on the remote machine B? I had a case where it just overwrote the changes with the new bundle without conflict warning or merge suggestion.
bundle 的双重应用:如果一个 bundle 不小心被应用了两次，会发生什么?是否需要以某种方式使用本地标签记录应用的捆绑包?
Double-applying of bundle: What happens when by accident a bundle is applied twice? Would be needed to record the applied bundles somehow with local tags?
或者还有其他更好的工作流程来通过电子邮件传输 Mercurial deltas?
Or is there another better workflow to transfer Mercurial deltas via email?
[*] 从对超级用户问题的回答中，我认为 Mercurial 可能是最可行的方法.
[*] From the answer to a superuser question I figured that Mercurial might be the most feasible way to do this.
推荐答案
- 中间更改:在创建捆绑包之后(步骤 1)和远程应用它之前(步骤 2)在远程计算机 B 上发生更改时会发生什么?我有一个案例，它只是用新包覆盖了更改，没有冲突警告或合并建议.
- In-between changes: What happens when after creating a bundle (Step 1) and before applying it remotely (Step 2) a changes occurs on the remote machine B? I had a case where it just overwrote the changes with the new bundle without conflict warning or merge suggestion.
如果在机器 B 上进行了更改，那么此更改将与您从机器 A 捆绑的更改并行进行.更改是在之前还是之前进行的并不重要创建捆绑包后(按时间)，重要的是机器 B 上的更改不以机器 A 的头部作为其祖先.
If a change is made on machine B, then this change will have been made in parallel with the changes you bundled from machine A. It doesn't really matter if the changes are made before or after you create the bundle (time-wise), it only matters that the changes on machine B don't have the head from machine A as their ancestor.
换句话说，当两台机器同步时，世界是这样的:
In other words, the world looks like this when the two machines are in sync:
A: ... [a]
B: ... [a]
然后您在机器 A 上创建一些新的提交:
You then create some new commits on machine A:
A: ... [a] --- [b] --- [c]
B: ... [a]
您使用 [a] 作为基础进行捆绑，因此您将获得包含 [b] 和 [c] 的捆绑包.现在让我们假设某人(可能是您自己)在机器 B 上提交:
You bundle using [a] as base, so you get a bundle with [b] and [c]. Let us now say that someone (perhaps yourself) makes a commit on machine B:
A: ... [a] --- [b] --- [c]
( bundled )
B: ... [a] --- [x]
到目前为止，两个存储库之间没有任何交换，所以这只是人们并行工作的正常情况.这是分布式版本控制系统中的常态——人们并行工作会产生合并提交的需求.
So far nothing has been exchanged between the two repositories, so this is just a normal case of people working in parallel. This is the norm in a distributed version control system — people working in parallel is that creates the need for merge commits.
此时在任一存储库中都不明显需要合并，它们都有线性历史记录.但是，当您在机器 B 上解绑时，您会看到分歧:
The need for a merge is not evident in either repository at this point, they both have linear histories. However, when you unbundle on machine B, you see the divergence:
A: ... [a] --- [b] --- [c]
( bundled )
B: ... [a] --- [x]
[b] --- [c]
( unbundled )
了解 hg unbundle 与 hg pull 完全一样是有帮助的，只是它可以离线完成.也就是说，如果您在两个存储库之间建立了在线连接，那么存储在包中的数据实际上只是 hg pull 会传输的数据.
It is helpful to realize that hg unbundle is exactly like hg pull, except that it can be done offline. That is, the data stored in a bundle is really just the data that hg pull would have transferred if you had had an online connection between the two repositories.
您现在将合并两个头 [x] 和 [c] 以在机器 B 上创建 [y]:
You would now proceed by merging the two heads [x] and [c] to create [y] on machine B:
A: ... [a] --- [b] --- [c]
B: ... [a] --- [x] --- [y]
/
[b] --- [c]
在机器 B 上，您的最后一个包是使用 [a] 作为基础创建的.但是，您也知道机器 A 具有提交 [c]，因此您可以根据需要将其指定为附加基础:
on machine B your last bundle was created with [a] as a base. However, you also know that machine A has commit [c], so you can specify that as an additional base if you like:
$ hg bundle --base a --base c stuff-from-machine-b.hg
这会将 [x] 和 [y] 放入包中:
That will put [x] and [y] into the bundle:
bundle: (a) --- [x] --- [y]
/
(c)
这里我使用 (a) 和 (c) 来表示捆绑包的所需基础.如果您的存储库中同时具有 [a] 和 [c]，则只能解绑此捆绑包.如果你省略了第二个基地(只使用 [a])，你还将捆绑 [b] 和 [c]:
Here I use (a) and (c) to denote the required bases of the bundle. You can only unbundle this bundle if you have both [a] and [c] in your repository. If you leave out the second base (only use [a]), you will also bundle [b] and [c]:
bundle: (a) --- [x] --- [y]
/
[b] --- [c]
在这里，您将除 [a] 之外的所有内容都包含在包中.捆绑太多是好的，我们接下来会看到.
Here you included everything except [a] in the bundle. Bundling too much is okay, as we will see next.
- bundle 的双重应用:如果一个 bundle 不小心被应用了两次，会发生什么?是否需要使用本地标签以某种方式记录应用的捆绑包?
- Double-applying of bundle: What happens when by accident a bundle is applied twice? Would be needed to record the applied bundles somehow with local tags?
两次应用一个包就像运行两次 hg pull 一样:第二次没有任何反应.解绑时，Mercurial 会查看包并导入缺失的变更集.所以如果你解绑两次，第二次就没有什么可做的了.
Applying a bundle twice is exactly like running hg pull twice: nothing happens the second time. When unbundling, Mercurial looks in the bundle and imports the missing changesets. So if you unbundle twice, there is nothing to do the second time.
这篇关于通过电子邮件将 Mercurial 存储库与捆绑包同步的工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
