标签: svn-reintegrate

我发现这种方式更容易合并分支和更少的冲突:

将trunk复制到新分支,将其与功能分支合并.完成任务后,将新分支合并回主干.这种技术非常像mercurial和git rebasing.

我过去常常将trunk中的任何变换合并到featurech/s.但后来当我将功能分支合并回主干时,来自主干的一些内容将再次合并回主干,这引起了很多冲突.有一个重新整合合并的选择,但它似乎并不适合我.

有没有人做类似的颠覆变基？我刚刚开始这样做,并没有看到任何副作用.这会导致任何不可预见的问题吗？

我正在尝试将开发分支重新集成到我的Subversion 1.5存储库中的主干中.在此操作之前,我将所有更改从主干合并到开发分支.现在当我尝试从分支重新集成更改时,我收到以下错误消息:

Command: Reintegrate merge https://dev/svn/branches/devel into C:\trunk  
Error: Reintegrate can only be used if revisions 280 through 325 were previously   
Error: merged from https://dev/svn/trunk to the reintegrate   
Error: source, but this is not the case:  
Error:   branches/devel/images/test  
Error:     Missing ranges: /trunk/images/test:280-324  
...

然后该消息继续抱怨我的项目中的一些文件夹.但是当我尝试将更改从主干再次合并到开发分支时,TortoiseSVN告诉我没有什么可以合并(因为我之前已经合并了所有更改):

Command: Merging revisions 1-HEAD of https://dev/svn/trunk into C:\devel, respecting ancestry  
Completed: C:\devel  

我正在尝试按照这里的说明:http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html,但没有解决这样的问题.

有任何想法吗？也许我应该删除主干然后复制我的分支？但我不确定它是否安全.

也可以看看

svn与--reintegrate合并抱怨缺少范围,但mergeinfo似乎是正确的

功能分支在合并(重新集成)回到主干后必须删除吗？

我更喜欢不断地从我的功能分支来回合并更改 - 我相信这可以将冲突降到最低.但我明白,一旦你使用reintegrate merge to trunk,就应该删除一个功能分支.

是这样吗？为什么？我能做些什么来规避这个？

更新 我问的是来自该工具的技术问题,而不是"方法问题".我打算在合并后继续处理功能分支.

更新顶部答案确实指定了一个相当复杂的过程(合并,删除和重新分配).在TortoiseSVN中有没有简单的方法来实现这一目标？不应该吗？

如果始终在合并功能分支之前同步功能分支.为什么你真的必须使用这个--reintegrate选项？

Subversion的书说:

然而,当将你的分支合并回主干时,基础数学是完全不同的.您的功能分支现在是重复主干更改和私有分支更改的混合,因此没有简单的连续修订版本可供复制.通过指定--reintegrate选项,您要求Subversion仅仔细复制您的分支特有的更改.(事实上​​,它通过将最新的树干树与最新的树枝树进行比较来实现这一点:产生的差异正是你的树枝变化!)

因此,该--reintegrate选项仅合并功能分支唯一的更改.但是如果你总是在合并之前进行同步(这是一种推荐的做法,为了处理功能分支上的任何冲突),那么分支之间的唯一变化就是功能分支独有的变化,对吧？如果Subversion尝试合并已经在目标分支上的代码,它就什么都不做,对吧？

在一篇博文中,Mark Phippard写道:

如果我们包含那些同步修订,那么我们合并回已经存在于trunk中的更改.这会产生不必要和令人困惑的冲突.

是否有一个例子表明何时放弃重新融合会给我带来不必要的冲突？

这是谜语:

C:\code\trunk> svn merge --reintegrate http://svn.e.com/repos/branches/lih --accept postpone --dry-run
svn: E195016: Reintegrate can only be used if revisions 11430 through 12384 were previously merged from http://svn.e.com/repos/trunk to the reintegrate source, but this is not the case:
  branches/lih
    Missing ranges: /trunk:11902

但是,如果我进入分支的目录并尝试合并该范围,则无需合并!

C:\code\branches\branch> svn merge -r 11901:11902 http://svn.e.com/repos/trunk --accept postpone --dry-run
C:\code\branches\branch>

甚至svn merge -r 11898:11903没有显示任何合并.

现在我似乎无法将我的分支重新融入后备箱!请帮忙!

PS lih分支直到11906才创建.它从高速分支分支,从分支分支(高清已经合并回主干).

我从trunk创建了一个分支.当我的分支上的开发完成后,我想将我的分支合并(重新集成)到trunk.是否有选项或设置启用？似乎Netbeans 7.1无法将分支重新集成到主干中.

我错了吗？

我知道--reintegrateSubversion(SVN)1.6中有一个选项可以将功能分支合并回主干.

我的工作流程有点复杂:

我们有功能分支 - 我们经常合并主干.但我们不会马上把它们放回行李箱.相反,我们从主干创建一个发布分支,并合并功能分支以释放分支.此时我们遇到了很多树冲突(因为在功能分支和主干中都存在很多变化).

选项--reintegrate必须在这种情况下有所帮助,但看起来--reintegrate在合并到除trunk之外的分支时不起作用.真的吗？

不应该发生的事情,今天发生在我身上.我们正在开发svn中的一个功能分支(Server afaik 1.6,client 1.7).这个分支昨天重新整合,而我不在办公室.现在我在工作副本中留下了一些本地更改,指向已经重新集成的分支.当然,这部分是我在工作后在当地留下变化的错,但那是另一个故事;-)

我知道重新整合分支机构不是一种选择,那么 将我的更改带入主干的最佳方法是什么？一个同事建议使用补丁,这是我以前从未使用过的.我还考虑过樱桃挑选我的更改,然后将它们提交到分支机构,但我不确定这是否可行.还有其他选择吗？

任何帮助是极大的赞赏.

最好的问候尼科

我一直试图了解SVN合并/重新整合并阅读这些文章/书籍:

http://svnbook.red-bean.com/en/1.5/index.html
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

我显然还没有得到它,因为我不明白为什么在合并回到主干(反射/循环合并)中包含同步修订是一个问题 - 我确实看到了不排除修订的理由.

如果主干上的文件A行合并到分支上的文件A'然后合并回主干,那么A和A'之间肯定没有区别,所以没有冲突？为什么"[合并] 返回已经存在于主干中的变化 "这个问题？

我正在尝试复制冲突场景,试图理解重新整合对我的影响,但更令我困惑的是这种情况:

1. 在trunk上提交更改(r4)
2. 将r4合并到分支并提交(r5)
3. 在分支上提交更改(r6)
4. 通过以下任一方法将分支合并到主干:
   • 将修订版本范围r5-r6合并到主干 - 发生冲突,或
   • 将r5合并到trunk,然后将r6合并到trunk - 不会发生冲突

我正在使用SmartSVN 6.6和SVN 1.6.合并修订范围与单独合并每个修订版时,为什么会有不同的结果？最终,为什么反思合并是一个问题？

我们做了以下丑陋的事情:

那么,我们怎样才能实现另一个reintegrate呢？

到目前为止我尝试了什么？

• 好吧,显而易见的合并 - 残酷地失败了!
• 创建一个补丁并将其应用到trunk(应该可以工作,因为它只是在没有svn的情况下区分文件...)
• 创建另一个分支@ trunk r101并合并来自第一个分支的所有更改 - 粗暴地失败:)

编辑:

trunk的merge-infos不显示所需分支的任何合并修订版(因为我用r101将它们回滚)

我使用TortoiseSVN在SVN中管理源文件.我添加了文件并将它们提交给修订版,随后决定分支.我用我需要的文件分支,并在不打算使用的文件的主干上执行删除.

现在我试图将分支重新集成到主干线.使用乌龟,我已经从主干到分支合并了从后备箱到头部的删除后的修改范围.这使分支机构更新.

现在我切换到主干,并尝试将修订从分支合并到主干,合并表示新文件被"跳过"或删除我现在完成的文件.

我是否遗漏了合并成为最新的行李箱？