svn与分支中的重命名目录合并

Question

我们最近在我的工作场所要求我们有一个基线Android项目（主干）。其他项目需要（svn）从这个基线Android项目中分支出来并开始自己的开发。

现在让我们说我的svn的当前状态是：

--r19--------r30----->my.package.baseline(trunk)
    |
    |--r24--r29------>my.newpackage.projectA(branch)

• r19：创建了projectA分支
• r24：重命名了我的分支包
• r29：做了大量更新
• r30：错误修复和升级到基线项目

如果我想将r30应用于我的所有其他分支，那么即使目录/包因svn merge而已更改，r24也可以正常工作吗？

Answer 1

如果你问的是你能提交，答案是肯定的。

如果你很幸运，r24中的文件已被更改，而r29只是r30中更改了文件的不同文件，那么它可以毫无问题地工作。

如果某些文件在r24中被更改或者r29也被r30触及，那么你可能会遇到一个svn冲突，只要执行合并的人理解代码在两个分支（trunk和你的分支）中的变化，它仍然可以工作），这个人不仅需要解决明显的svn冲突（一个文件中的同一区域在两个分支中都被更改），而且还需要解决代码逻辑冲突，我的意思是没有svn冲突，但它赢得了＃t编译，或在代码中引入新错误的更改之间的逻辑冲突。

我的建议虽然在合并后，在解决svn冲突后立即提交，不要担心任何逻辑冲突。您可以在单独的新提交中解决逻辑冲突。根据我的经验，当您合并回主干时，这将节省您的一些罕见的麻烦。正如svn对合并所做的那样，它会修改mergeinfo属性，对于你的例子，你的分支中的mergeinfo就像是

trunk: r30

当你决定合并回主干时，svn将使用这些信息来弄清楚它应该如何执行合并，如果你的分支拥有从主干到日期的所有内容，它只是用你的分支替换主干，假设你解决了所有冲突，但是，如果你选择樱桃，它会以不同的方式使用合并信息来尝试自动解决冲突，所以如果你在另一个提交中提交逻辑修复，它就不太可能遇到svn冲突。

功能分支运行的时间越长，如果主干在此期间不断变化，您将遇到的问题就越多。但事实就是如此，分支的工作方式，你应该有一个关于你从主干合并的频率以及你想要保留你的分支多久的计划。尝试将您的任务分成较小的部分，这样您的分支的寿命就会缩短，例如两周，与保持分支三个月然后将所有这些更改合并回主干相比，这会产生很大的不同。