1

我正在我们的一个存储库中搜索一组特别粗糙的旧版本，试图弄清楚几个所谓的合并发生了什么。

当我查看目标分支中的一个修订时，它显示的内容与源分支上的修订完全相同（相信我，我也检查了差异）：

$ svn --log --verbose --use-merge-history --revision 100 ^/target
------------------------------------------------------------------------
r100 | <author> | <date> | 1 line
Changed paths:
   A /path/to/new/file
------------------------------------------------------------------------

但是，少了点什么。任何地方都没有记录 mergeinfo 属性更改，对吧？所以它不可能是合并，据我所知。也许作者手动编辑了文件？

我仔细检查了 Subversion 认为符合条件的修订：

$ svn mergeinfo --show-revs eligible ^/source ^/target | grep 100

没有什么！尽管缺少合并信息，Subversion 仍认为修订已被合并。

$ svn mergeinfo --show-revs merged ^/source ^/target | grep 100
r100

那可能吗？如何？

我阅读了关于缺少合并信息的CollabNet 文章和Svn Book 部分。

  • 合并不相关的来源：情况并非如此，正如我所说，我可以在源分支中看到确切的内容/差异。
  • 从外国存储库合并：同上。
  • 使用 --ignore-ancestry：这是可能的（我不知道作者调用了什么命令），但是这个修订版不会出现在符合合并条件的列表中吗？
  • 从目标的自然历史中应用反向合并：从历史中可以明显看出这不是反向合并。
4

1 回答 1

2

哎呀，据 svn:mergeinfo我现在所知，实际上有财产。我不记得是否svn log打印仅属性更改（它必须），尝试运行svn log --verbose或svn propget svn:mergeinfo --verbose针对^/target.

阅读SVNBook | 在没有 Mergeinfo的情况下合并。

顺便说一句，不要忘记在 Subversion 1.5 中引入了 mergeinfo。因此，如果合并发生在较旧的 Subversion 版本中，则有可能这就是svn:mergeinfo缺少属性的原因。

是的，提交作者出于无知可以手动编辑文件以使提交看起来像合并。

于 2016-06-06T18:56:45.827 回答