基本上，我们有一个分支（称为B，它包含一些分支特定的代码），它需要与HEAD合并。我们遇到的问题是分支很早就被创建了。此后，HEAD多次更新并增加了许多新功能，并修复了许多错误。 B分支仍然有大部分bug已经在HEAD中修复，并且缺少一些功能。所以，需要做的是采用分支B的某些功能（可能有大约50个包含新功能的文件 - 我不知道这些文件到底是什么），同时保持HEAD的其余部分不变。在CVS（Eclipse）中将过期分支与头部合并
目前，Eclipse中的合并工具报告了1700多个更改，自动合并将HEAD中的代码与分支中的代码一起覆盖（因此引入了已修复的错误）。有没有更好的方法来解决这个问题，而不是经历所有1700次更改并手动合并它们？
如果我理解你的问题，你想知道特定分支上发生了什么变化，并将这些变化应用到主干。我认为最简单的方法是创建一个补丁文件。
首先检查分支的基础和提示到不同的目录中。你说你有一个基础标签，它使你在99％使用CVS的人中占据领先地位。如果情况并非如此，那么你可以做一个基于日期的结账。找到正确的日期将是一件痛苦的事情;最简单的方法是查看日志中的分支上未知的文件，并追踪分支出现在修订历史记录中的位置。
第二步是创建一个修补程序文件，它描述了在分支上所做的所有更改。指令here似乎完整（我做了一个谷歌搜索“创建一个小块”，并看着最好的结果）。
接下来你要做什么取决于修补程序的大小以及从分支被切断后树干有多少变化。如果你觉得幸运，最简单的方法是检查后备箱并按照链接文件中的描述使用补丁。您可能会遇到至少几次失败，并且无论如何您都需要检查每个更改以验证它是否有意义。
另一种方法是打开三个窗口：窗口＃1是patchfile，它会告诉您已更改的文件和更改的文件。 Window＃2是分支（的顶端）上的文件，所以你可以看到它目前正在做什么。窗口＃3是您的主干上的文件。在这种方法中，您将代码从＃2复制到＃3，这是有道理的，＃1仅用于指导复制的内容。
对于什么是值得的，虽然CVS在分支和合并时特别痛苦，但没有VCS擅长合并高度分歧的分支（不管Joel如何说）。
您是否标记了分支的基础？ – parsifal 2013-02-27 15:03:08
TIL人仍然使用CVS。就个人而言，我建议将整个事情转换为Subversion，然后尝试这样做，但是可能有推动继续使用CVS的特定原因，不是吗？ – 2013-02-27 15:08:10
@ parsifal：是的，我相信有一个开始标签。 – tomsky 2013-02-27 15:30:14