通过电子邮件与软件包同步Mercurial存储库的工作流程 [英] Workflow to synchronise Mercurial repositories via email with bundles

问题描述

我在两台不同的计算机上有两个目录 - 机器 A （Windows）和机器 B （OSX） - 我想通过Mercurial保持两个目录同步。 [*]

限制是两台机器未通过LAN / WAN连接; 在数据之间移动数据的唯一方法是通过电子邮件。所以我认为发送电子邮件的Mercurial捆绑是三角形可以做的。

我目前的工作流大致是这样（使用本地标签 lcb 为最新的更改包）：

1. 说我在机器上工作 A 即可。在一天结束时，我做：

     hg commit -A -m更改123
    hg bundle  - -base lcb bundle_123.hg 
    hg标签--local -f lcb --rev tip 
     

   最后然后我发送电子邮件到机器 B 。




2. 然后坐在机器 B

     hg unbundle bundle_123.hg 
    hg merge 
    hg commit -A -mremote changes 123 
    hg标签--local -f lcb --rev tip 
     




3. 现在我在机器上工作 B ，一天结束时，我做了下面列出的1.，但是在机器 B 上。而且这个循环还在继续...

然而，我担心这个系统不够健壮： >

• 中间更改： 创建捆绑后会发生什么（步骤1）和在远程应用之前（步骤2）远程机器 B 发生更改？我有一个案例，它只是用新的捆绑包覆盖了更改，而没有冲突警告或合并建议。




• 双重应用捆绑：如果事件发生了捆绑应用两次，会发生什么？需要使用本地标签记录应用的捆绑包？

或者还有另一个更好的工作流程来传输Mercurial deltas通过电子邮件？

---

[*]从回答超级用户问题我认为，Mercurial可能是最可行的方法。

解决方案

blockquote>

• 中间更改：创建捆绑包（步骤1）之后并在远程应用之前会发生什么（步骤2）更改发生在远程机器B上？我有一个案例，它只是用新的软件包覆盖了更改，没有冲突警告或合并建议。

如果在机器B上进行了更改，那么这个更改将在并行中与您从机器A捆绑的更改进行。如果在更改前后进行更改，则并不重要您创建捆绑（时间方面），这只是重要的是，机器B上的更改不具有从机器A作为其祖先的头。

换句话说当两台机器同步时，世界看起来就像这样：

  A：... [a] 
 
 B：... [a] 
  

然后在机器A上创建一些新的提交：

  A：... [a] --- [b] --- [c] 
 
 B：... [a] 
  

使用 [ a] 作为基础，所以你得到一个包含 [b] 和 [c] 。现在让我们说一个人（也许你自己）在机器B上做出承诺：

  A：... [a] -  [b] --- [c] 
（捆绑）
 
 B：... [a] --- [x] 
  

到目前为止，两个存储库之间没有交换任何内容，所以这只是一个平行工作的人的正常情况。这是分布式版本控制系统中的规范 - 并行工作的人是创建合并提交的需要。

需要合并在任何一个存储库中都不明显在这一点上，他们都有线性历史。但是，当您在机器B上分包时，您会看到分歧：

  A：... [a] --- [ b] --- [c] 
（捆绑）
 
 B：... [a] --- [x] 
 \ 
 [b] --- [c] 
（unbundled）
  

有意义的是， c $ c> hg unbundle 完全像 hg pull ，除了可以离线完成。也就是说，存储在包中的数据实际上只是在两个存储库之间已经有一个在线连接的情况下， hg pull 将被转移的数据。

现在，您将通过合并两个头 [x] 和 [c] 在机器B上创建 [y]

  A： ... [a] --- [b] --- [c] 
 
 B：... [a] --- [x] --- [y] 
 \ / 
 [b] --- [c] 
  

在机器B上你最后bundle以 [a] 为基础创建。但是，您也知道机器A已提交 [c] ，因此您可以指定为额外的基数：

  $ hg bundle --base a --base c stuff-from-machine-b.hg 
  

这将把 [x] 和 [y] 捆绑包：

 包：（a）--- [x] --- [y] 
 / 
（c）
  

这里我使用（a）和（c）表示捆绑所需的基础。如果您的存储库中同时包含 [a] 和 [c] ，则只能取消捆绑此捆绑包。如果你省略第二个基数（只使用 [a] ），你也将捆绑 [b] code> [c] ：

  bundle：（a）--- [x ] --- [y] 
 \ / 
 [b] --- [c] 
  

在这里，您可以包括捆绑包中的 [a] 以外的所有内容。捆绑太多是好的，我们将在下面看到。

• 如果事件发生了两次捆绑，会发生什么？需要使用本地标签记录应用的捆绑包？

应用捆绑包两次喜欢运行 hg pull 两次：没有发生第二次。解除捆绑时，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. [*]

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.

My current workflow is roughly this (using a local tag lcb for the latest change bundle):

1. 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
   

   finally then I email that bundle to machine B.

2. Then sitting at machine B I do

   hg unbundle bundle_123.hg
   hg merge
   hg commit -A -m "remote changes 123"
   hg tag --local -f lcb --rev tip
   

3. 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:

• 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.

• 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?

Or is there another better workflow to transfer Mercurial deltas via email?

---

[*] From the answer to a superuser question I figured that Mercurial might be the most feasible way to do this.

解决方案

• 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.

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]

You then create some new commits on machine A:

A: ... [a] --- [b] --- [c]

B: ... [a]

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.

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 )

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.

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]

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

That will put [x] and [y] into the bundle:

bundle: (a) --- [x] --- [y]
                       /
                    (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]

Here you included everything except [a] in the bundle. Bundling too much is okay, as we will see next.

• 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?

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屋！