对于某些修订,SVN合并不会合并任何内容

Mis*_*lle 18 svn tortoisesvn merge

我们正在使用Subversion和TortoiseSVN.我们使用trunk进行开发,使用branches来表示稳定版本.在分支上进行的更改(错误修复)随后会合并回主干.我们不是颠覆专家,但总的来说这对我们很有用.

最近我将一些从一个分支到一个分支的变化合并到一起,我得到了一个合并没有做任何事情的修订.

Command    Merging revisions 7233-7234 of .../branches/RB-7.2.0 into C:\Core, respecting ancestry
           C:\Core  
Finished!   
Run Code Online (Sandbox Code Playgroud)

分支修订显然有与之相关的更改,涉及的文件不是新的,并且更改不会出现在我的工作副本中,所以我不知道为什么它不起作用.似乎有几个连续的分支修订版以这种方式运行(涉及几个不同的文件),然后是那些行为正常之后的那些.

我知道可以通过将合并标记为仅记录来阻止修订被合并(修订标记为合并,即使它不是.)所以我唯一能想到的是这些修订已被某种方式阻止.在主干中,应该合并的文件似乎在mergeinfo属性中没有任何内容,也没有任何父文件夹.但我不确定我是否希望看到这些信息.此外,合并对话框中的"显示日志"对话框似乎显示所有修订,包括我已成功合并的那些,无论是否选择"包含合并修订".

所以我的问题如下:

  • 有没有办法证实这种修改理论被封锁了?
  • 如果修订被阻止,有没有办法解除阻止?
  • 如果他们没有被封锁,我还应该看看什么?

更新:在确认问题与被阻止的修订版无关后,我再次尝试从命令行而不是通过tortoise进行合并.它做了合并(耶!)但现在我正在看它,我注意到mergeinfo没有更新任何已更改的文件,只有6个已经有mergeinfo的无关文件.我不确定是否要关注这一点.我仍然不知道为什么乌龟不起作用,但至少我可以完成我的工作.

gbj*_*anb 12

当Tortoise进行合并时,如果您将修订框留空,它将仅使用mergeinfo属性来确定要合并的修订版本.因此,您"解锁"修订版,只需明确合并该版本.Tortoise没有列出日志中已经合并的修订版

Tortoise可能会再次在mergeinfo中记录合并,所以看看目录的svn属性后来看看是否这样做(并编辑额外的输入 - 虽然我认为服务器会这样做,有时候更容易手动执行) .

另一种方法是查看mergeinfo prorperty并查看是否已列出此修订版,如果是,则删除它并提交.然后重复合并,它应该按预期工作.

目的地通常有mergeinfo,但我猜你在你的分支中也有一些可能会阻止合并.如果是这种情况,请告诉我们,我有兴趣看看实际发生了什么.


Jos*_*non 6

记录合并是可能的.要仔细检查,从C:\ Core(看起来像你的行李箱结账):

svn propget -R svn:mergeinfo > mergeinfo.txt 
Run Code Online (Sandbox Code Playgroud)

搜索生成的文件,查看是否列出了相关修订版#.记住 - 这是你要检查的TRUNK,因为它是合并的目标.

它可能被列为范围,因此直接#搜索可能不起作用(.eg文件可能列出7230-7240,而不是7234)如果没有,则会发生其他事情 - 如果是,可能合并记录在文件或尚未检查的文件夹.

我不知道如何在没有手动编辑的情况下反转mergeinfo记录(不推荐),但你可以通过传递--ignore-ancestry强制它重新合并修订版.如果这导致合并做某事,那么svn认为合并已经发生,你应该看到上面的证据.

如果尚未记录合并且上述步骤无法解决,请查看svn邮件列表以获取相关信息.