我已经非常习惯于如何在Eclipse中进行CVS合并，否则我对Subclipse和Subversive都可以​​与SVN存储库一起使用的方式感到满意，但是我不确定如何正确进行合并。

当我进行合并时，似乎想要将合并的文件粘贴到项目的单独目录中，而不是像在CVS中那样覆盖要在合并中替换的旧文件。

这个问题对于Subclipse或者Subversive都不是唯一的。

谢谢帮助！

解决方案

我通常签出两个分支，然后使用"相互比较"选项对两个源树进行类似同步的比较。将更改集成到一个分支中后，我们可以重新提交到存储库。

我建议不要尝试使用Eclipse的插件作为对Subversion的主要访问方式。

如果我们在Windows上进行开发，那么TortoiseSVN是我所见过的Subversion访问的最佳程序。浏览到要合并的目录，右键单击该目录，然后使用Tortoise SVN合并选项。假设是非交互式合并，一旦遇到冲突，我们将必须遍历每个冲突的文件并编辑冲突，然后再将其标记为已解决。对于此过程，我建议使用一个名为KDiff3的程序，该程序显示本地存储库副本(合并之前存储在.svn中的内容)，本地副本(包括所有更改)以及来自存储库的副本，并允许我们执行以下操作：轻松查看(甚至在需要时进行手动修改)合并的结果。它还会自动处理一堆小的冲突。

KDiff3是可移植的，TortoiseSVN是Windows Shell扩展，因此，如果我们使用的是其他环境，我将尝试仅使用SVN进行合并。但这将是一个更大的痛苦:)

使用Eclipse集成，它可以很好地工作。

CVS的主要变化是，我们仅合并分支中的增量，即从一个修订版本更改为另一个修订版本。
也就是说，我们必须以某种方式跟踪正确的开始修订(除非我们具有svn 1.5合并历史记录)

如果我们做对了，则取决于我们如何使用比较编辑器来正确进行更改。

请记住，使用svn将修改后的树恢复为干净状态非常容易。只需在合并目标分支上拥有一个干净的工作区，然后运行merge命令从合并源分支中导入修改，然后同步工作区，我们将获得通常的日蚀比较窗口，其中显示所有合并的修改文件和冲突。

如果由于某种原因我们无法解决冲突，则可以在项目上svn还原并返回到干净状态，否则就地进行合并，完成后就可以提交。请注意，我们不必提交，完成冲突处理后，我们还可以返回到dev视图，验证代码是否可以编译，运行单元测试等，然后再次同步并提交(一旦冲突在本地解决了他们不会回来了)

上次查看时，使用subclipse merge命令时，它将覆盖合并的文件(使用冲突标记显示冲突区域)，并将合并的原始左侧和右侧放置在同一位置。它不应将任何内容放在不同的目录中。

根据经验，最好将所有合并修改都提交到一个提交中，并且只在提交中包含合并修改，以便以后可以在需要时回滚合并。

将整个分支合并到主干

• 当我们说"全部显示"时，它将带我们回到分支日期之后，并向我们显示中继的所有历史记录，因此我们必须在分支的位置搜索注释
• 注意：如果我们对同一任务使用Tortise SVN(导航至分支并选择"显示日志")，它将仅显示分支历史记录，因此我们可以准确知道分支的开始位置
• 所以现在我知道82517是分支历史记录的第一个版本ID。因此，超过82517的分支的所有版本都具有要合并到主干中的更改
• 现在转到Eclipse工作区中的" trunk"项目，然后选择"右键单击-团队-合并"
• 在修订下，选择"全部"
• 按确定
• 这将带我们进入"团队同步"透视图(如果不是，则应自己去那里)以解决冲突(请参见下文)

重新将更多分支更改合并到主干

• 所以现在我知道分支中大于82517的任何版本都需要合并到主干中
• 现在转到Eclipse工作区中的" trunk"项目，然后选择"右键单击-团队-合并"
• 在"修订"下，选择"修订"单选按钮，然后单击"浏览"
• 这将打开最新的25个分支修订版本的列表
• 选择数字大于82517的所有修订
• 按OK(我们应该在单选按钮旁边的输入字段中看到修订列表)
• 按确定
• 这将带我们进入"团队同步"透视图(如果不是，则应自己去那里)以解决冲突(请参见下文)

解决冲突

• 我们应该处于"团队同步"透视图。这看起来像用于提交目的的任何常规同步，在其中我们可以看到新文件和有冲突的文件。
• 解决该文件中的所有冲突后，告诉文件"标记为合并"
• 一旦所有文件都没有冲突，我们就可以同步Eclipse项目并将文件提交到SVN

openCollabNet的子剪辑合并工具非常简洁。有许多可用的合并类型，而我刚进行的合并是无缝的。我推荐它。

在Eclipse中同步视图缺乏的一件事是签入功能。在团队同步视图中，我可以查看所有更改并解决冲突，因此直接在此处签入而不是返回Java视图并进行签入将非常直观。