0

使用 Mercurial。在私人克隆中工作，进行更改，推动掌握。等等，没关系。

（顺便说一句，我熟悉许多版本控制系统，从经典的 SCCS、RCS、CVS、SVN 到 DVCS，如 BitKeeper、Git、Mercurial，对 Monotone、Darcs、Bzr 非常熟悉。不太熟悉Perforce，......我只是为那些可能能够解释系统之间的等价物和相似性的人提到这一点。）

不幸的是，该项目的其他成员认为我签到太频繁了。我使用“尽早且经常检查”的方法，有时检查的频率超过每半小时一次。他们不想在日志中看到这么多签入消息。

不是问题：现在，我已经养成了在分支上进行大部分更改的习惯（尽管 hg 缺少追溯分支），当我将任务分支合并回主干时总结所有更改。hg log -b default 允许他们过滤掉我的任务分支，并且在合并消息有意义时可以正常工作。这不是我的问题。

不是问题：同样，我知道如何使用历史编辑等来删除我的细粒度变更集，以便唯一被推送的变更集是粗粒度的。（虽然，顺便说一句，我经常发现最简单的做法是移动 .hg 目录。）历史编辑很烦人，但我可以做到。

我的问题：我的问题是： 我想跟踪我的细粒度变更集和日志消息，即使我没有将它们推送到项目主存储库。问：我该怎么做？

即我如何保持两个存储库相互跟踪，但不将我所有的更改推送到主库？最好不要推送标签更改。（顺便说一句，我更喜欢说“标记修订集”。变更集听起来太像补丁了。）

我现在这样做的方式是拥有 a) 项目主仓库 b) 我的个人主仓库，以及所有细粒度的更改 c) 一个或多个工作区

在哪里

a）克隆项目主仓库以获取工作区（使用 hg clone，是的，我知道）

b）在工作区克隆中使用细粒度签入工作（我知道这一点）

c) 从工作区克隆推送到我的个人主人

d) 并且，当需要推送到主服务器时，编辑历史记录并推送它。

两个烦恼：

1）从工作区克隆合并或推送到我的个人主库时发生冲突 - 更准确地说，是从主存储库与编辑过的历史合并以删除细粒度签入到我的个人主库时的冲突，并保留了细粒度签入。

2）我想把推送给项目主的东西记录在我的个人主里。

--

一个非常简单的例子。

一个任务分支，带有细粒度的签入。

o  changeset:   1022:
|  branch:      default
|  parent:      1017
|  parent:      1021
|  summary:     Merged task branch onto main, default, branch, with changes to FOO and BAR
|
o    changeset:   1021
|\   branch:      task-branch
| |  parent:      1020
| |  summary:     Merged default branch to task-branch, with changes to FOO and BAR
| |
| o  changeset:   1020
| |  branch:      task-branch
| |  parent:      1018:
| |  summary:     yet another fine grain checkin on a branch changing BAR for a second time
| |
o |  changeset:   1019
| |  branch:      task-branch
| |  parent:      1018:
| |  summary:     yet another fine grain checkin on a branch changing FOO
| |
o |  changeset:   1018
| |  branch:      task-branch
| |  parent:      1017
| |  summary:     yet another fine grain checkin on a branch changing BAR a first time
| |
|/
o  changeset:   1017
|  branch:      default
|  summary:     some other changeset on the default branch, i.e. trunk
|

已编辑的历史记录，被推送到项目主控

o  changeset:   1018: ...changed checksumm because checksum seems to include history
|  branch:      default
|  parent:      1017
|  summary:     Merged task-branch onto main, default, branch, with changes to FOO and BAR. 
|               Removed task-branch-history from what got pushed to project repo, 
|               although may still be in personal repo
|
o  changeset:   1017
|  branch:      default
|  summary:     some other changeset on the default branch, i.e. trunk
|

问题是，当我尝试合并更新的项目主控时，可能看起来像

o  changeset:   1019
|  branch:      default
|  parent:      1018
|  summary:     again, some other changeset on the default branch, i.e. trunk
|
o  changeset:   1018: ...changed checksumm because checksum seems to include history
|  branch:      default
|  parent:      1017
|  summary:     Merged task-branch onto main, default, branch, with changes to FOO and BAR. 
|               Removed task-branch-history from what got pushed to project repo, ]
|               although may still be in personal repo
|
o  changeset:   1017
|  branch:      default
|  summary:     some other changeset on the default branch, i.e. trunk
|

即使项目主文件的变更集 1018 和个人主文件中的 1022 在文件内容方面完全相同，我也会遇到冲突。

我尝试不更改被推送的合并更改中的注释。没有帮助，至少不可靠。

我想知道变更集中是否包含完整的历史记录。

我还想知道是否有一些合并工具可以识别相同的文件，即使不同的历史和日志消息也是如此。

4

1 回答 1

3

一般来说，任何涉及编辑历史的工作流程都不会很好地工作。这不是预期的工作模式，也没有努力让它正常工作。

对您来说更好的选择可能是：

  1. 版本化的Mercurial Queues ( hg qinit --create-repo) 允许您在单个补丁上进行多次提交迭代。你可以在你的私人补丁仓库中获得完整的历史记录，而他们只会得到qfinish完整的 ed。
  2. 与其合并回您的任务分支并编辑历史记录，不如将更改重新应用为单个提交并推送。在您的示例中hg diff -r 1017 -r 1021 | hg import，它将创建一个新的提交 (1022)，它是所有更改的总和 1018::1021，包括在内。 它应该干净地合并并且可以推送，而无需将您的任何变更集推task-branch送给他们。你甚至可以hg commit --close-branch在任务分支上
  3. 告诉你的同事 STFU。;) 高变更集粒度是一种很好的做法，它们应该适应。

此外，请考虑为您的任务分支使用书签而不是命名分支。同样，新的阶段功能可以在您的任务分支中标记变更集（无论是书签分支还是旧式命名分支），secret这样它们就不会被意外推送。

于 2012-05-27T01:40:52.720 回答