将派生代码快照与更新的上游代码合并的最佳实践工具和技术？
情况如下：需要将上游代码库（从V1到V2）的更改合并到从V1派生/分支的第三代码库S1中，以产生新的代码库S2。
我们可以访问V1和V2之间的日志和修订版本，以及V1、V2和S1的来源。然而，S1 没有提供版本控制存储库和历史记录：鉴于从 V1 到达 S 的中间更改无法单独得知，因此不可能将其视为分支和演进的主干之间的合并。
因此，情况是我们正在执行增量 3 路合并，以便生成 S2，并将 S1 中派生的更改更新为在 V2 的基础上工作。 （我们不断发展的 V2 自然受到版本控制）
我发现 WinMerge 可用于识别目录结构之间简单不同/丢失/添加的文件，而 p4merge 作为文件级别的良好三向合并工具。
您建议使用哪些工具和技术？值得注意的是，代码库的规模很大，V1和V2之间的中间修订数量很大，V1和S之间的更改规模也很大。
The situation is as follows: it is necessary to merge in changes from an upstream code base (from V1, to V2), into a third code base S1 that is derived/branched from V1, to produce a new code base S2.
We have access to version control for logs and revisions between V1 and V2, and the source of V1, V2 and the source of S1. However, S1 is not provided with a version control repository and a history: it is not possible to treat this as a merge between a branch and an evolved trunk given that the intermediate changes to arrive at S from V1 are not known individually.
The situation is that we therefore are performing an incremental 3-way merge in order to result in S2, with the changes derived in S1 updated to work on the basis of V2. (Our evolving V2 is naturally kept under version control)
I have found WinMerge to be of use in identifying files that are simply different / missing / added between directory structures, and p4merge as a good 3-way merge tool at the file level.
What tools and techniques do you suggest? It is worth noting that the sizes of the code bases are large, the number of intermediate revisions between V1 and V2 is large, and the size of the changes between V1 and S are also large.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
就我个人而言，虽然可能不像前面提到的克隆检测器那么奇特，但我会首先使用
diff -u S1 V1 >/tmp/diffs.patch，它应该告诉您 S1 中发生了什么更改。我怀疑可以使用patch -p0 将大部分差异合并到 V2 中。任何无法完成的更改都将尽可能多地进行修补，而被拒绝的更改则留给手动合并。这应该在几分钟内处理所有“简单”的部分。您可能想要试运行它，然后从 .patch 文件中删除一些更棘手的文件，您将通过 3 路合并手动完成所有合并。
如果更改过于广泛（大规模重构或在文件之间移动大量代码），那么您可能需要使用 Ira 提到的工具。
Personally, while probably not as fancy as the aforementioned Clone Detector, I'd start by using
diff -u S1 V1 >/tmp/diffs.patch, which should tell you what was changed in S1. I'd suspect a high percentage of the diffs can be merged onto V2 withpatch -p0 </tmp/diffs.patch. Any it can't will be patched as much as it can, and the rejected changes left for hand-merging.This should handle all the "easy" pieces in a few minutes. You may want to trial-run it, then remove some trickier files from the .patch file that you'll do all the merging by hand with a 3-way merge.
If the changes are too extensive (massive refactoring or moving large amounts of code from file to file), then you may need to use tools like Ira mentioned.
您想知道的是 V2 和 S1 之间的增量以及它们在哪里。
Winmerge 会告诉您文件是否完全相同、是否丢失或不同。如果不同，它不会告诉您它们有什么共同点，如果有的话，这是合并的基础。
我会在 V2 和 S 中使用（我们的）克隆检测器 来找出它们的内容在语言结构的粒度上很常见。从 V2 克隆到 S 到同一文件的代码块在某种意义上是“已经合并”；如果 V2 克隆到 S 中的另一个文件中，则可能存在代码移动。在存在可参数化差异的地方，克隆检测器（至少是我们的）将能够告诉您参数（“编辑”）是什么，并且您可以决定如何合并它们。如果代码非常不同，克隆检测器不会说什么，但您可以通过从 Winmerge 认为不同的文件中减去克隆检测器认为大部分是克隆的文件来获得该列表。这些非常不同的文件可能很难合并。
对于大部分彼此克隆的文件，您可以使用我们的智能差异器来告诉您如何V1 文件可以修改为生成 S；这将提供
细粒度的变化信息。
What you want to know are the deltas between V2 and S1, and where they are.
Winmerge tells you that files are the exactly the same, or if they are missing or different. If different, it won't tell you what they have in common, if anything which is the basis for a merge.
I'd use a (our) Clone Detector across V2 and S to find out what they had in common at the granularity of language structures. Code blocks that are clones from V2 into S into the same file are in some sense "already merged"; where there are clones of V2 into a different file in S there has likely been code movement. Where there are parameterizable differences, the clone detector (at least ours) will be able to tell you what the parameters ("edits") are and you can decide how to merge them. Where the code is very different, the clone detector won't say anything, but you can get that list by subtracting files the clone detector says are mostly clones, from those that Winmerge says are different. These very different files will likely be difficult to merge.
For files that are mostly clones of one another, you can use our Smart Differencer to tell you how the V1 file could have been modified to produce S; that will provide
fine grain change information.
如果 V 不在一个好的 VCS 中，则可能需要将 V 导入到一个全新的 VCS 中才能开始。然后在 V1 处创建一个分支，并导入您可以从备份、旧构建树、工作副本等中找到的 S1 的每个旧副本。在 VCS 中构建尽可能多的从 V1 到 S1 的历史记录。如果有人在此过程中进行了一些彻底的重新格式化，则可以通过将相同的工具应用于 V2 分支的修订来将其标准化。
然后使用合并工具并解决冲突。如果有很多（并且可能会有），您可能希望沿着 V1..S1 和 V1..S2 历史记录逐步合并，以便可以提交中间工作。
If V is not in a good VCS, it might pay to import V into a whole new VCS to start. Then create a branch at V1 and import every old copy of S1 you can find from backups, old build trees, working copies, etc. Build as much of a history from V1 to S1 as possible in the VCS. If someone has done some drastic reformatting along the way it may be possible to normalize that by applying the same tool to the revisions of the V2 branch.
Then use the merge tool and work your way through the conflicts. If there are a lot (and there probably will be) you may want to incrementally merge at stages along the V1..S1 and V1..S2 histories so you can commit intermediate work.
我真的推荐超越比较。它有一个干净的 GUI、出色的比较算法、3 个文件比较、目录结构比较等等。
I really recommend Beyond Compare. It has a clean GUI, great comparison algorithms, 3-files compare, directory structure comparison and more.
您应该使用 Git 进行合并。签出 S1，然后 git merge v2。
如果 S1 和 V1 之间有很多更改，您可以确定重命名等会引发最少的冲突。或者，您可以在 s1 之上从范围 v1 到 v2 或从 v2 之上从范围 v1 到 s1 变基（重播更改） - 这取决于您想要实现的目标。这并不是真正的三路合并。
如何将 v1..v2 和 v1..s1 历史记录导入 git 取决于您。如果不存在迁移工具，则可以在每个修订版编写导出脚本来完成。然后只需将您的结果提交到您正在使用的 SCM 中的 S1 之上作为 S2 即可。
希望这会有所帮助，
如果您需要我的帮助，您可以在 #git irc 频道上找到我，或者还有其他一些非常擅长合并事物的人。
You should use Git to do the merge. Checkout S1, then git merge v2.
If S1 has lots of changes between it and V1, you can be sure that renames, etc will throw the least amount of conflicts. Alternatively, you can rebase (replay changes) from range v1 to v2 on top of s1 or from range v1 to s1 on top of v2 - it depends on what you want to attain. This is not really a 3 way merge.
how you get v1..v2 and v1..s1 history into git is up to you.. If no migration tool exists, scripting the export at each revision should do it. Then just commit your results on top of S1 as S2 in the SCM you are using.
Hope this helps,
You can find me on the #git irc channel if you want my help or a bunch of others are there as well that are VERY good at merge things.