一个巨大的合并已经通过TortoiseSVN完成，Subversion版本是1.6SVN日志命令行不显示单合并版本（SVN日志-r）
念叨方式颠覆（高达1.5版本）修订管理：
Subversion 1.5 and later keeps a record of merges using properties. This allows us to get a more detailed history of merged changes. For example, if you develop a new feature on a branch and then merge that branch back to trunk, the feature development will show up on the trunk log as a single commit for the merge, even though there may have been 1000 commits during branch development.
现在几个问题：
如果我在TortoiseSVN的历史去的分支合并了，我看不出合并修订，除非我检查“纳入合并版本”的旗帜，在这他们显示为灰色，，足够公平！
合并消息包含一些错误：
Correcting Shell script that identifies DB objects which have been dropped from SVN.
Trying to figure out why the shell variable is not getting used properly in
"svn log -qvr..." command
和
........
(and even) More syntax fixes .. testing call to shell
........
(and even) More syntax fixes .. testing call to shell
........
(and even) More syntax fixes .. testing call to shell
o
在Windows，而不是不与下面的错误显示的消息：
svn: E720008: Write error: Not enough storage is available to process this command.
这是不是一个大问题，所以让我们重点不是这个..
让我们关注，而不是对命令行，当我运行了svn log命令我收到提交信息中同样的问题：
我可以用-g参数查看所有历史记录（包括合并的修订版），再次足够公平！
的主要问题是，我不能再获得特定合并版本SVN的LOG -r命令
例如，你可以看到TortoiseSVN的显示为灰色（与修订69524的包括合并后的版本检查）
但SVN日志-r 69524返回空白消息，这件事发生的所有数以千计的合并版本：
这是正常的吗？
欣赏SVN现在正在管理合并的方式，但是否有可能我无法再使用svn log -r获得特定的合并修订信息？
这是因为合并过程中出现了问题，或者这是新版本颠覆的正常行为？
老实说这对我来说真的很奇怪！请大家帮我理解，这是杀了我！
感谢
解决！
从分支根运行命令修复了这个问题，老实说我期望合并的修订版本在发布分支中被列入原因，即使在另一个代码行树中（模拟git之间的不同行为壁球/ rebase/merge + commit）
您的SVN客户端和服务器过时了6至7年。使用最新的SVN客户端和服务器工具。目前的版本是SVN 1.9。 – bahrep
完全同意，这就是我们即将做的事，即使它不取决于我，但与此同时，这是一种正常行为还是出了问题？ – ivoruJavaBoy
“合并消息”是合并操作的提交日志消息，对吗？你在那里看到什么错误？当你确切地收到'E720008：写错误：'？ – bahrep