帮助与mercurial repo问题

Question

我有一个条件我不明白的回购。 2个星期前，我标记了一个发布，以标记我可能需要回头的一个特定点。后来，我决定进行分支，并且还从另一个回购（我最初克隆的回购）中引入了变化。

原来的转速是令人感兴趣的是52：

changeset: 52:5044a88ba2a9 
date:  Mon Jan 10 18:09:30 2011 -0500 

几个提交后，我支到“多分区”（我应该立即进行，但我没有预料到需要它）。

经过一些工作后，我从姐妹回购中获得了更改（所有更改都不会与我在分支中的工作相冲突，因此它是安全的）。

这是我现在看到：

$ hg branches 
MultiPartition    75:9fd803c56505 
default      72:3939850a77e2 (inactive) 

在那里我多分区我工作，默认值是从姐姐回购尖端。

如果看我的头：

$ hg heads 
changeset: 75:9fd803c56505 
branch:  MultiPartition 
tag:   tip 
date:  Tue Jan 18 18:32:38 2011 -0500 

changeset: 72:3939850a77e2 
parent:  69:997a5b43216d 
date:  Tue Jan 18 13:26:48 2011 -0500 

changeset: 54:4ad1d36a79aa 
date:  Thu Jan 13 19:14:57 2011 -0500 

还有的修订版54挂在那里，我没有（故意）的意思是留下。

这里是奇怪的地方：changeset 52不在我当前的MultiPartition提示中（虽然它实际上在我的磁盘上的源代码中，正如我所料）。我在底部附加了一个变更集的图形日志。

如果我使用hgcontains扩展，我看到：

$ hg headscontaining 52 
changeset: 75:9fd803c56505 
branch:  MultiPartition 
tag:   tip 
date:  Tue Jan 18 18:32:38 2011 -0500 

告诉我，转52（其中有新的文件，我想在当前分支）的内容应该是尖这个分支。然而，hg update -C MultiPartition从我希望他们在目录中删除新的文件。

如果我使用hgtk log和过滤器由感兴趣的目录，我看到了52变更它增加了文件，但没有新的变更有任何文件中删除从这个目录。

唯一让我想知道的是：Changeset 71是原始回购合并。在该回购中，这些新文件不存在。日志对于changset是：

| o changeset: 71:ba4c67a24185 
|/| branch:  MultiPartition 
| | parent:  70:2dcbf69c325d 
| | parent:  69:997a5b43216d 
| | date:  Mon Jan 17 17:55:10 2011 -0500 

这是我的核心问题：

1. 如果父70：已经我所期待的，但父母69：没有，这是怎么认为解决？
2. 我该如何检查其他遗漏？有没有办法看到这种行为？
3. 我想没有多个头，但我似乎无法“合并”它们。从技术上讲，他们已经合并（我认为）。我应该如何清理它？

如果很抱歉，这是复杂的，但我不知道该怎么问这样的问题，除了给一吨的信息的。

完全graphlog：

o changeset: 75:9fd803c56505 
| branch:  MultiPartition 
| tag:   tip 
| date:  Tue Jan 18 18:32:38 2011 -0500 
| 
o changeset: 74:be7df4e2579c 
|\ branch:  MultiPartition 
| | parent:  73:3e7ac80ab37a 
| | parent:  72:3939850a77e2 
| | date:  Tue Jan 18 18:31:24 2011 -0500 
| | 
| o changeset: 73:3e7ac80ab37a 
| | branch:  MultiPartition 
| | parent:  71:ba4c67a24185 
| | date:  Tue Jan 18 18:28:51 2011 -0500 
| | 
o | changeset: 72:3939850a77e2 
| | parent:  69:997a5b43216d 
| | date:  Tue Jan 18 13:26:48 2011 -0500 
| | 
| o changeset: 71:ba4c67a24185 
|/| branch:  MultiPartition 
| | parent:  70:2dcbf69c325d 
| | parent:  69:997a5b43216d 
| | date:  Mon Jan 17 17:55:10 2011 -0500 
| | 
| o changeset: 70:2dcbf69c325d 
| | branch:  MultiPartition 
| | parent:  66:79272b7e7c01 
| | date:  Mon Jan 17 17:42:04 2011 -0500 
| | 
o | changeset: 69:997a5b43216d 
| | date:  Mon Jan 17 12:00:09 2011 -0500 
| | 
o | changeset: 68:b39f8a7af0c5 
| | date:  Sun Jan 16 20:23:43 2011 -0500 
| | 
o | changeset: 67:63d3b40427e0 
| | parent:  58:29029a74e351 
| | date:  Sun Jan 16 18:07:49 2011 -0500 
| | 
| o changeset: 66:79272b7e7c01 
| | branch:  MultiPartition 
| | date:  Mon Jan 17 09:43:32 2011 -0500 
| | 
| o changeset: 65:b33eb978d647 
| | branch:  MultiPartition 
| | date:  Mon Jan 17 09:39:54 2011 -0500 
| | 
| o changeset: 64:1fdafb6d0e84 
| | branch:  MultiPartition 
| | date:  Sun Jan 16 17:48:09 2011 -0500 
| | 
| o changeset: 63:74942ab5113d 
| | branch:  MultiPartition 
| | date:  Sun Jan 16 17:46:15 2011 -0500 
| | 
| o changeset: 62:2cd5a6d9d120 
| | branch:  MultiPartition 
| | date:  Sun Jan 16 01:55:23 2011 -0500 
| | 
| o changeset: 61:acc73e7a35fc 
|/| branch:  MultiPartition 
| | parent:  60:c10e217081f0 
| | parent:  58:29029a74e351 
| | date:  Sun Jan 16 01:53:01 2011 -0500 
| | 
| o changeset: 60:c10e217081f0 
| | branch:  MultiPartition 
| | date:  Sun Jan 16 01:45:16 2011 -0500 
| | 
| o changeset: 59:2709b82b3ac0 
| | branch:  MultiPartition 
| | parent:  54:4ad1d36a79aa 
| | date:  Sun Jan 16 01:42:34 2011 -0500 
| | 
o | changeset: 58:29029a74e351 
| | date:  Sun Jan 16 01:36:44 2011 -0500 
| | 
o | changeset: 57:48840b75e37b 
| | date:  Fri Jan 14 11:04:06 2011 -0500 
| | 
o | changeset: 56:dab5f0d40be9 
| | date:  Thu Jan 13 15:51:11 2011 -0500 
| | 
o | changeset: 55:214ac45834fd 
| | parent:  51:7d0a1da31199 
| | date:  Wed Jan 12 16:49:00 2011 -0500 
| | 
| @ changeset: 54:4ad1d36a79aa 
| | date:  Thu Jan 13 19:14:57 2011 -0500 
| | 
| o changeset: 53:8f06d69177d6 
| | date:  Thu Jan 13 14:02:42 2011 -0500 
| | 
| o changeset: 52:5044a88ba2a9 
| date:  Mon Jan 10 18:09:30 2011 -0500 
| 
o 

Answer 1

你居然还对默认分公司两个头，并在多分区分支一个头，如hg heads已经显示出你。无论分支如何，使用hg heads -t可查看实际头像。它看起来像使用graphlog扩展名，所以使用hg glog -r "branch(default)"可视化您的默认分支。

至于你的问题：

1. 如果父70：已经我所期待的，但父母69：没有，这是怎么认为解决？

您可以hg export -r 52 >52.patch然后hg import 52.patch在尖端。这将重新应用这些更改。您的一个合并必须删除内容。

1. 如何检查其他遗漏？有没有办法看到这种行为？

不是真的。就Mercurial而言，52是您小费的祖先。如果更改在稍后的更改集中被删除，Mercurial并不知道。您可以hg diff两个不同的变更集并追踪它被删除的位置（可能在合并中）。

1. 我想没有多头，但我似乎无法“合并”他们。从技术上讲，他们已经合并（我认为）。我应该如何清理它？

默认通常，你希望所有的开发结束。您可以合并两个默认正面，然后hg ci --closebranch上MultiPartition并合并到默认。

Answer 2

1：如果父母70：有什么我的预期，但父母69：没有，这是怎么认为解决？

我猜这些文件在61或71合并中被删除。你可以用“diff to second parent”选项在hgtk中检查。

3：我想没有多个头，但我似乎无法“合并”它们。从技术上讲，他们已经合并（我认为）。我应该如何清理它？

在默认分支上有两个匿名头（54和72，其中72是默认的提示），只要MultiPartition分支没有合并回默认值，它们就会保持打开状态。尽管稍后在MultiPartition分支中进行了合并，但它们仍然是默认分支的头，因为mercurial不会将后续分支视为分支的新头。这种治疗的原因是，当你hg update branch时，你通常希望最新的版本是一个分支。

当您将MultiPartition合并回默认值时，您可以摆脱两个默认标题。当您完成MultiPartition时，您也可以使用hg ci --close-branch关闭此分支（从技术上讲，您不能移除MultiPartition头，但是当它关​​闭时hg heads不会将其视为主动头）。