SVN想从主干合并到分支无限期

Question

我的SVN回购协议是这样的：

/trunk 
/branches/project1/trunk 
/branches/project1/branches 

我的目录/分支机构/ PROJECT1 /行李箱/行李箱的一个分支。我对这个分支做了很多修改（新代码，新增文件，删除文件等）。我有时从分支合并到主干，从主干合并到分支。但是我的错误是在任何情况下总是使用“合并一系列修订”。我最近才明白，“合并一系列修订”应该用于从树干到分支的合并，“重新分支分支”用于从分支合并到树干。

所以今天，我尝试用正确的方法合并来自分支的差异到主干，并修复了很多冲突。但从那时起，当我从分支合并到主干以及从主干合并到分支时，SVN想要“更新”分支中一天添加的一些文件。除了增加转速以外，更新不做任何事情。如果我尝试合并2到3次，每次都会更新相同的文件（例如，仅增加转数）。

有没有办法解决这个问题？或者我应该删除我的分支，并创建一个新的，在同一条路径？

的SVN版本是：

TortoiseSVN 1.6.16, Build 21511 - 32 Bit , 2011/06/01 19:00:35 
Subversion 1.6.17 

Answer 1

你这里的问题是您的工作流程。分支机构不是按照您使用它们的方式设计的。您可以将更改合并到分支源代码的分支中（在您的示例中为/trunk），但是一旦将分支更改合并回源代码中，您应该停止使用该分支并将其删除。 （注意：从技术上讲，keep a branch alive after reintegrating it有一个'官方'的方式，但由于它相当于删除和重新创建分支并且更难做到，所以通常不是最好的路线）

这里的问题是元数据。当你合并分支之间的变化时，Subversion会记录指示哪些修订合并的元数据。从分支返回到主干将元数据附加到主干，表明分支中的某些修订已合并。下次合并来自trunk->分支，合并的修订版本之一是表示分支 - >主干合并的主干修订。此时元数据相当混乱且几乎是循环的，而且实际上最终可能会通过合并自上次合并后在分支中修改的较旧代码的代码来破坏分支。即使合并成功完成，您也会增加未来合并冲突的可能性。一般来说，它非常容易出错，而不是Subversion设计的用例。为了更好地解释为什么会导致问题，请参阅上面的链接。

总体而言，分行专为临时短期开发工作而设计。你所做的听起来更像是一个长期的分支比分支，这绝对不是Subversion的典型用例之一。这里有几个选项。

1）当您从分支合并到中继时，请不要记录关于合并的任何元数据。要么手动合并更改（而不是让Subversion执行此操作），要么合并更改，然后在提交之前还原元数据更改。这不是一个很好的解决方案，并引入了复制/粘贴错误的机会，但它可能导致更少的问题。你仍然在标准的Subversion工作流程之外工作，所以我希望你仍然会遇到问题。

2）避免将分支部分合并回干线。如果合并所有分支的更改，请执行--reintegrate合并，然后删除分支（您始终可以创建一个新分支，即使是具有相同名称的分支）。如果只需要合并一部分更改，请在主干（而不是分支）中进行初始开发，然后将从主干到分支的更改合并。这样，所有的合并仍然沿着相同的方向进行，最终结果是变化存在于主干和分支中。 3）考虑使用git。你所描述的工作流更容易用git完成，并且不需要跳过尽可能多的循环来让它运行。你也可以在Subversion之上运行git，这样你就可以在你的本地机器上使用一个git仓库，它可以从Subversion仓库中提取并推送更改。

4）通过重构代码来消除对fork的需求，从而不需要单独的分支。将常用功能分解为共享模块，并将差异隐藏在通用接口后面。如果你愿意，你可以使用编译时标志来选择要构建的版本。这将消除完全合并的需要。

＃4显然是最好的解决方案。我明白，在所有情况下都可能无法做到这种事情，特别是当代码库很大并且分支机构进行重大架构更改时。如果不可行，我建议选择＃3。我个人使用这种方法。我的团队使用Subversion版本库，但团队中的一些开发人员（包括我自己）在我们的本地机器上运行git，以便完成Subversion无法做的（或者不容易）更高级的事情。我们不会像您一样维护任何长期分支机构，但我们经常使用多个短期分支机构并合并它们之间的更改。

有关Subversion关于分支和合并的典型用例的更详细描述，请参阅the Subversion book。