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

如果你所要求的只是你是否能够承诺,答案是肯定的。

如果幸运的是,在r24和r29中更改的文件与在r30中更改的文件完全不同,那么它将毫无问题地工作。

如果在r24或r29中更改的某些文件在r30中也被触摸过,那么您可能会遇到SVN冲突,只要执行合并的人理解两个分支(主干和分支)中的代码更改,该人就仍然可以工作,而不仅仅需要解决明显的SVN冲突(同样是一个in-one文件在两个分支中都被更改了),但也需要解决代码逻辑冲突,我的意思是没有SVN冲突,但它将不再编译,或者更改之间的逻辑冲突在代码中引入新的错误。

不过,我在这里的建议是,合并后,在解决SVN冲突后立即提交,不要担心任何逻辑冲突。您可以在单独的新提交中解决逻辑冲突。从我的经验来看,当你合并回后备箱时,这将为你省去一些罕见的麻烦。正如SVN对合并所做的那样,它修改了 mergeinfo 属性,例如,分支中的mergeinfo

trunk: r30

SVN将使用这些信息来计算当您决定合并回主干时,它应该如何执行合并,如果您的分支从主干到现在都具有所有内容,那么它只需将主干替换为您的分支,假设您解决了所有冲突,如果您执行cherry-pick,那么它将使用如果可能的话,nfo会以不同的方式尝试自动解决冲突,因此,如果在不同的提交中提交逻辑修复,则不太可能遇到svn冲突。

功能分支运行的时间越长,如果同时主干不断变化,您将面临的问题就越多。但这就是分支的工作原理,你应该有一个计划,关于你从主干合并的频率和你想保留分支的时间。试着把你的任务分割成更小的部分,这样你的分支的寿命就更短了,例如两周,与你保持一个分支三个月的时间相比,这会有很大的不同,然后把所有的变化合并回主干。