version-control - "abuse"Mercurial 的重命名功能可以跟踪代码块的移动吗？

Question

有时我发现我有一个文件随着时间的推移而增长到包含比我喜欢的更多的类/函数/任何东西。是时候重构了!在这种情况下，我通常会发现我的一个文件变成了几个:它本身加上几个其他文件，每个文件都包含文件的不同段。

不幸的是，仅仅创建这些新文件就有点“打破”历史——很难说这些函数最初来自另一个文件。如果在重构期间对代码进行了任何其他更改，那就更糟了。

我的一位同事发现他可以通过执行以下操作“滥用”重命名功能:

hg rename --after original_file new_file_1
hg rename --after original_file new_file_2
hg rename --after original_file new_file_3
hg add original_file

结果是，每个新文件看起来都像重命名了文件的其余部分，而原始文件看起来像是丢失了已删除的 block 。到目前为止，这似乎很理想。但是，我担心这些多次重命名会导致一些困惑的 merge 。

这种“多次重命名”的方法有什么问题吗？

Answer 1

你应该确保你 know what hg copy really means在这样做之前。

简而言之，从 original_file 复制文件至new_file_1添加 Mercurial 将在 future merge 中使用的链接 当且仅当 找不到new_file_1在共同的祖先。这通常只会在您制作副本后的第一次 merge 中出现。

一张图表可能会更好地说明这一点:

old --- edit old --- edit in old copied to new --- edit old --- merge
   \                /                             /
    copy old new --/------- edit new ------------/

我们从拥有文件 old 的变更集开始。 .然后编辑 old在一个分支上并复制 old至 new在另一个。在第一次 merge 编辑到 old复制到 new .在第二次 merge 中， new 没有特殊处理。自从 new在共同祖先( copy old new 变更集)中找到。

这对您的情况意味着 future 的 merge 会有很大的不同，具体取决于人们何时看到 copy old new。 .如果你能让每个人都使用

old --- copy old new

作为他们的出发点，那么一切都很好。但是如果有人从 old 分支变更集和实际编辑 old在该分支中，当他们尝试与 copy old new merge 时，他们将遇到 merge 冲突变更集。

更准确地说，如果他们编辑了 old 的任何部分，就会发生 merge 冲突。未复制到 new 中的文件文件。 merge 冲突提醒您注意 old 中的更改。需要复制到 new .然而，当你真正做到

hg copy old new1
hg copy old new2
hg copy old new3

那么您将在三个新文件中的两个中获得不相关的 merge 冲突。

如果您刚刚删除了 old文件并添加了三个新文件，那么你仍然会在这里遇到 merge 冲突:你会被问到

remove changed old which local deleted
use (c)hanged version or leave (d)eleted?

您是否喜欢看到该提示或查看 merge 工具启动取决于您 — 但现在您知道 hg copy 的后果了。 (或 hg rename --after ，实际上是一回事)。