合并后提交分支上的日志会发生什么?

场景:

  1. 程序员在版本5创build了名为“my_foo”的项目'foo'的分支
  2. 程序员在处理“my_foo”特性时对多个文件进行了多处更改。
  3. 在每个主要步骤的末尾,比如向类中添加几个新的函数,程序员对相应的文件进行svn commit ,因此将它们提交给分支
  4. 几个星期后,许多提交(每个提交都有一个提交日志描述了他所做的),程序员将分支合并回到trunk:
#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
#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! 他把所有的变化都归并到了后备箱里! 山上有许多欢乐和喝酒。

现在让我们假设另一位程序员在一个星期后出现,并将他们的工作副本从修订版本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行

添加资产/ images / tumblr_icon.png到主干

那个程序员把所有的提交都放在他的分支里,所有的注释都发生了什么事? 那些在合并过程中不会被拖延? 我是疯了还是忘了什么?

答案已经过时了 ,现在我们有了svn log -g


不,你不是疯了。 这是不幸的,它是如何工作的。

最好的办法是在提交消息中包含分支URL和版本号,以便人工查找该分支的修订日志。 (当然数据仍然存在)。

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

如果主干没有或几乎没有变化,则可以select进行反向合并(从主干合并到分支),然后用分支replace主干。 这种推理也可以在单独的子文件夹上完成(例如:从分支中取代XMLparsing器实现子文件夹,保留其余部分)。 replace文件夹(使用svn delete,svn copy)将保留修订历史logging。

对于合并期间新添加的文件,如果使用svn copy命令,则可以从分支复制其修订历史logging。 但不知道合并命令是否包含对此的支持。

知道是否有一个工具可以做一个“rebase”(如在git或mercurial中)可能会很有趣。 这将为分支上的每个更改创build单独的提交。 另一方面,也许个人承诺太混乱了。

我可以给出的最好的build议是使用一个好的UI,比如Trac,这样就可以很容易地检查修订历史,所以你可以看看分支上发生了什么。

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

TortoiseSVN在“显示日志”对话框的底部有“包含合并修订”checkbox,以包含提交给分支的注释。

好的答案…如果你还想知道检入文件和潜在的分支名称,请使用-g [–use-merge-history]将-v [–verbose]选项打包。

例:

 svn log -vg 

输出将具有检入文件(甚至合并分支)的完整path,以及用于合并版本中的添加文件(来自'revision_url')的消息。