合并后在分支上提交日志会发生什么？

Question

场景：

1. 程序员在修订版 5 中为项目“foo”创建了一个名为“my_foo”的分支
2. 程序员在处理“my_foo”功能时对多个文件进行了多项更改。
3. 在每个主要步骤结束时，比如向一个类添加几个新函数，程序员会对相应的文件执行svn commit，从而将它们提交到分支
4. 经过几周和多次提交（每个提交都有一个提交日志描述他所做的事情）后，程序员将分支合并回主干：

#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

哈扎！他已将所有更改合并回主干！山露多喜饮。

现在让我们假设另一个程序员一周后来了，并将他们的工作副本从修订版 5 更新到修订版 15。“哇”，他们说。 “我想知道自第 5 版以来发生了什么变化”。然后程序员在他们的工作副本上执行svn status，他们会得到这样的结果：

-------------------------------------------------- ---------------------- r15 |程序员1 | 2010-03-20 21:27:04 -0400（2010 年 3 月 20 日星期六）| 1 行 将 2.0 版更改合并到主干 -------------------------------------------------- ---------------------- r5 |程序员2 | 2010-02-15 10:59:55 -0500（2010 年 2 月 15 日星期一）| 1 行 添加 assets/images/tumblr_icon.png 到主干

其他程序员在其分支中的所有提交中添加的所有注释到底发生了什么？那些在合并期间不会被拉过来吗？我是疯了还是只是忘记了什么？

Answer 1

尝试svn log -g 包含自 Subversion 1.5 以来存储的合并历史记录。

Answer 2

TortoiseSVN 在“显示日志”对话框底部有“包括合并的修订版”复选框，以包括提交到分支的 cmets。

Answer 3

Answer is outdated，现在我们有了svn log -g。

---

不，你没有疯。不幸的是，这就是它的工作原理。

您可以做的最好的事情是在合并的提交消息中包含分支 url 和修订号，以便可以手动查找该分支的修订日志。 （当然，数据仍然存在）。

但是，您不知道哪些更改已进入主干，哪些没有。

如果主干上没有更改或更改很少，则可以选择进行反向合并（从主干合并到分支），然后用分支替换主干。 这种推理也可以在单个子文件夹上进行（例如：从分支中替换 XML 解析器实现子文件夹，保留其余的）。 替换文件夹（使用 svn delete、svn copy）将保留修订历史记录。

对于在合并过程中新添加的文件，如果您使用 svn copy 命令，可以从分支复制其修订历史。不过，不确定合并命令是否包含对此的支持。

如果有一个用于 svn 的工具可以执行“rebase”（如在 git 或 mercurial 中），这可能会很有趣。这将为分支上的每个更改创建单独的提交。另一方面，也许单个提交太混乱了。

我能给出的最佳建议是使用良好的 UI，例如 Trac，这样可以轻松检查修订历史记录，以便您查看分支上发生的情况。

Answer 4

很好的答案...如果您还想知道签入的文件和可能的分支名称，请将 -v [--verbose] 选项与 -g [--use-merge-history] ​​捆绑在一起。

示例：

svn log -vg

输出将包含签入文件的完整路径（甚至是合并的分支），以及（来自“revision_url”）在合并的修订中添加的文件的消息。