合并后在分支上提交日志会发生啥?
Posted
技术标签:
【中文标题】合并后在分支上提交日志会发生啥?【英文标题】:What Happens to Commit Logs on a Branch After Merging?合并后在分支上提交日志会发生什么? 【发布时间】:2011-02-01 00:11:10 【问题描述】:场景:
-
程序员在修订版 5 中为项目“foo”创建了一个名为“my_foo”的分支
程序员在处理“my_foo”功能时对多个文件进行了多项更改。
在每个主要步骤结束时,比如向一个类添加几个新函数,程序员会对相应的文件执行
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
哈扎!他已将所有更改合并回主干!山露多喜饮。
现在让我们假设另一个程序员一周后来了,并将他们的工作副本从修订版 5 更新到修订版 15。“哇”,他们说。 “我想知道自第 5 版以来发生了什么变化”。然后程序员在他们的工作副本上执行svn status
,他们会得到这样的结果:
其他程序员在其分支中的所有提交中添加的所有注释到底发生了什么?那些在合并期间不会被拉过来吗?我是疯了还是只是忘记了什么?
【问题讨论】:
【参考方案1】:尝试svn log -g
包含自 Subversion 1.5 以来存储的合并历史记录。
【讨论】:
+1 绝对。不过需要注意的是,如果merge替换了文件,那么中间的revisions就不会出现在日志中。 (要识别替换文件,您将在合并修订版的svn log --verbose
中将其视为“R”)。试图理解为什么缺少中间的修订,这让我发疯了。【参考方案2】:
TortoiseSVN 在“显示日志”对话框底部有“包括合并的修订版”复选框,以包括提交到分支的 cmets。
【讨论】:
使用 svn merge 在主干中提交提交有什么特别需要做的吗?【参考方案3】:Answer is outdated,现在我们有了svn log -g
。
不,你没有疯。不幸的是,这就是它的工作原理。
您可以做的最好的事情是在合并的提交消息中包含分支 url 和修订号,以便可以手动查找该分支的修订日志。 (当然,数据仍然存在)。
但是,您不知道哪些更改已进入主干,哪些没有。
如果主干上没有更改或更改很少,则可以选择进行反向合并(从主干合并到分支),然后用分支替换主干。 这种推理也可以在单个子文件夹上进行(例如:从分支中替换 XML 解析器实现子文件夹,保留其余的)。 替换文件夹(使用 svn delete、svn copy)将保留修订历史记录。
对于在合并过程中新添加的文件,如果您使用 svn copy 命令,可以从分支复制其修订历史。不过,不确定合并命令是否包含对此的支持。
如果有一个用于 svn 的工具可以执行“rebase”(如在 git 或 mercurial 中),这可能会很有趣。这将为分支上的每个更改创建单独的提交。另一方面,也许单个提交太混乱了。
我能给出的最佳建议是使用良好的 UI,例如 Trac,这样可以轻松检查修订历史记录,以便您查看分支上发生的情况。
【讨论】:
很好的信息,谢谢。追问:分支合并到主干后,不再需要了,不应该删除吗?还是应该永远保存?如果我删除一个分支,是否所有的提交/修订数据都随之而来? 我会说尽快删除分支(即当所有内容都已合并或过时)以避免混乱/混乱。如果需要,您可以稍后恢复分支(通过创建新分支作为旧修订的副本)。 Subversion 中的任何内容都不会被删除。 所以如果有人想查看已删除分支的提交,他们必须检查分支然后做一个 svn 日志?或者他们可以直接用 svn log 做点什么吗? 如果您知道分支仍然存在时的修订号,您可以执行“svn log”(您应该能够使用主干的日志找到它,寻找合并提交) 这个解决方案不是“你能做到的最好的”,应该提到svn log -g
【参考方案4】:
很好的答案...如果您还想知道签入的文件和可能的分支名称,请将 -v [--verbose] 选项与 -g [--use-merge-history] 捆绑在一起。
示例:
svn log -vg
输出将包含签入文件的完整路径(甚至是合并的分支),以及(来自“revision_url”)在合并的修订中添加的文件的消息。
【讨论】:
以上是关于合并后在分支上提交日志会发生啥?的主要内容,如果未能解决你的问题,请参考以下文章