Question

我们的团队使用Eclipse开发软件产品，最近我们切换到Subversion来进行源代码控制/版本管理。起初我们的团队仍然直接进入主干，因为我们不熟悉Subversion的源代码控制方式，而且还需要抽出一些东西。

在某些时候，我从主干创建了第一个真正的分支，为我们产品中的特定项目进行开发。假设分支被称为DEV_PROJ。

稍后，当我们的团队更好地了解如何使用Eclipse中的Subversion时，我将团队放在我们的第一个真正的开发分支上，而不是针对特定的子项目，而是跟踪不同的版本。假设分支被称为DEV_VERS。现在我们正在开发该分支，不再直接提交到主干。 DEV_VERS从最新版本的trunk中分支出来，从那时起就没有提交到trunk。

在两个分支之间大约两三个月过去了，在我创建版本分支之前，对主干进行了很多更改。现在是时候将DEV_PROJ中的更改合并到DEV_VERS分支以将项目合并到我们的新版本分支中。

我首先做的是将最新版本的trunk合并到我的DEV_PROJ分支（正向合并？），认为这样可以最小化两个分支之间的差异，同时保持特定于项目的更改。

我现在正在尝试以及我遇到的问题是将DEV_PROJ合并到DEV_VERS分支。右键单击，Team / Merge我的DEV_VERS项目开始合并，有三个选项卡可供选择：URL，2个URL，Reintegrate。据我所知，这不是重新整合合并，而是从分支到主干，而不是在不直接相关的分支之间。我也不需要将两个分支合并到我的分支，所以我跳过2个URL选项卡。

所以我选择第一个，URL。作为源我从DEV_PROJ分支获取我的项目，修订：从复制开始，深度：工作副本。在第二次尝试中，我也选择了忽略祖先。两次尝试都按下预览按钮以获得合并目标文件的概述。

我看到有很多文件可供合并，但我的DEV_PROJ分支中没有更改。因此，（颠覆）合并过程看到了比我预期更多的合并候选人。我添加到DEV_PROJ分支的文件显示为“已添加”，但是我知道我在该分支中没有更改的大量文件在合并概述中显示为“已修改”或“树冲突”。

我的问题：

这是分支合并的正确方法吗？如果没有，可以直接使用合并菜单（URL，2URLs，Reintegrate）？
我的第一步（向DEV_PROJ转发合并主干）是不是应该有合并候选人的原因？
如果没有正确合并这些分支的直接方法，那么我只看到一个选项。这是将DEV_PROJ合并到trunk（reintegrate），然后将trunk合并到DEV_VERS分支（forward merge）。这是正确的方法吗？如果是这样，这是唯一的方法吗？

Eclipse：Helios Service Release 2，build：20110218-0911
SVN服务器：1.6.15
Eclipse SVN插件：SVNKit 1.3.2（2.2.2.I20100512-1900）// SVN连接器（2.2.2.I20100512-1900）// SVN团队提供商（0.7.9.I20100512-1900）

Answer 1

如果我理解你的问题，那就是你的项目状态：

        _________________ B        DEV_PROJ
       / 
    A /
---------------------------------- trunk
             C \
                \_____________ D   DEV_VERS

您希望A -> B分支中的所有更改都来自DEV_VERS。

如果是这样，我将做的是以下（以下是命令行等效，但应该很容易找到Eclipse SVN GUI等价物）：

查找A的修订版：
- svn log --stop-on-copy URL_OF_DEV_PROJ
- 最早的提交修订号是点A
查找B的修订版：
- 假设您要合并DEV_PROJ分支中的所有更改，B的值只是HEAD
结帐DEV_VERS：
- svn co URL_OF_DEV_VERS
在步骤3中已检出代码的目录中，将更改从A合并到B，如下所示：
- svn merge -r<RevisionOfA>:HEAD URL_OF_DEV_PROJ .

简而言之，您正在做的是在A和B之间采用差异并将其合并到DEV_VERS

如何正确合并分支，从不同版本的trunk分支？

1 个答案: