我正在我们的一个存储库中搜索一组特别粗糙的旧版本，试图弄清楚几个假定的合并发生了什么。
当我查看目标分支中的一个修订时，它会向我显示与源分支上的修订完全相同的内容(相信我，我也检查了差异)：
$ 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认为尽管缺少mergeinfo，但修订版已经合并。
$ svn mergeinfo --show-revs merged ^/source ^/target | grep 100
r100
这可能吗？怎样
我阅读了CollabNet的文章和Svn Book关于丢失mergeinfo的部分。
- 合并不相关的源：事实并非如此，正如我所说，我可以在源分支中看到确切的内容/diff
- 从外国存储库合并：同上
- 使用--ignore祖先：这是可能的(我不知道作者调用了什么命令)，但这个修订版不会出现在符合合并条件的列表中吗
- 从目标的自然历史中应用反向合并：从历史中可以明显看出，这不是反向合并
哦，据我所知，实际上有svn:mergeinfo属性。我不记得svn log是只打印属性更改(必须)，请尝试运行svn log --verbose还是针对^/target运行svn propget svn:mergeinfo --verbose。
读取SVNBook |合并而不合并信息。
顺便说一句，别忘了mergeinfo是在1.5子版本中引入的。因此，如果合并发生在较旧的Subversion版本中，则可能这就是缺少svn:mergeinfo属性的原因。
是的，提交作者出于无知可以手动编辑文件，使提交看起来像合并。