情景：
svn commit，因此将它们提交给分支
#Assume the following is being done from inside a working copy of the trunk:
svn merge -r 5:15 file:///path/to/repo/branches/my_foo
Hazzah！他将所有的变化合并到了后备箱！ Mountain Dew有很多欢乐和喝酒。
现在让我们说另一位程序员在一周后出现并将他们的工作副本从第5版更新到第15版。“哇”，他们说。 “我想知道自修订版5以来发生了什么变化”。程序员然后在他们的工作副本上做svn status，他们得到这样的东西：
------------------------------------------------------------------------ r15 | programmer1 | 2010-03-20 21:27:04 -0400 (Sat, 20 Mar 2010) | 1 line Merging Version 2.0 Changes into trunk ------------------------------------------------------------------------ r5 | programmer2 | 2010-02-15 10:59:55 -0500 (Mon, 15 Feb 2010) | 1 line Added assets/images/tumblr_icon.png to trunk
其他程序员在他的分支中提交了所有提交的所有注释到底发生了什么？合并期间那些没有被拉过来的人吗？我疯了还是忘了什么？
答案 0 :(得分：43)
尝试svn log -g以包含自Subversion 1.5以来存储的合并历史记录。
答案 1 :(得分：14)
TortoiseSVN在“显示日志”对话框的底部有“包含合并修订”复选框，以包含提交给分支的注释。
答案 2 :(得分：9)
Answer is outdated，现在我们已svn log -g。
您可以做的最好的事情是在合并提交消息中包含分支URL和修订号，以便人们可以手动查找该分支的修订日志。 （当然，数据仍在那里）。
但是，您不知道哪些更改已进入主干，哪些没有。
如果主干上没有或很少有变化，可能是进行反向合并（从主干合并到分支）然后用分支替换主干的选项。 这种推理也可以在单个子文件夹上完成（例如：从分支中替换XML解析器实现子文件夹，保留其余部分）。 替换文件夹（使用svn delete，svn copy）将保留修订历史记录。
对于在合并期间新添加的文件，如果使用svn copy命令，则可以从分支复制其修订历史记录。但是，不确定merge命令是否包含对此的支持。
知道svn是否有一个“rebase”工具（如git或mercurial）可能会很有趣。这将为分支上的每个更改创建单独的提交。另一方面，也许个别提交太杂乱了。
我可以给出的最好的建议是使用一个好的用户界面，比如Trac，这样可以很容易地检查修订历史记录，这样你就可以看看分支机构发生了什么。
答案 3 :(得分：2)
答案很好......如果您还想知道已签入的文件以及可能的分支名称，请将-v [--verbose]选项与-g [--use-merge-history]捆绑在一起。
示例：
svn log -vg
输出将包含已签入文件的完整路径（甚至是合并的分支），以及用于合并的修订中添加文件的（来自＆＃39; revision_url＆＃39;）消息。