合併後提交分支上的日誌會發生什麼情況？

Question

場景：

1. 程序員在版本5
2. 程序員使他的作品在「my_foo」功能，將多個文件多次更改創建項目「富」叫「my_foo」的一個分支。
3. 在每一個重大步驟結束，說增加了幾項新的功能類，程序員確實在適當的文件，因此將它們提交到分支
4. 經過幾個星期的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！他將他所有的變化重新整合到了後備箱中！山上有許多歡樂和喝酒。

現在讓我們假設另一位程序員在一週後出現，並將其工作副本從修訂版本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 

到底發生了其他程序員放在他所有的在他的分支提交的所有音符是什麼？那些在合併期間不會被拖延？我是瘋了還是忘了什麼？

Answer 1

Answer is outdated，現在我們有svn log -g。

---

不，你不是瘋了。不幸的是，這是如何運作的。

您可以做的最好的事情是在提交消息中包含分支url和修訂號，以便人工查找該分支的修訂日誌。 （當然數據仍然存在）。

但是，您不知道哪些更改已將其添加到主幹中，哪些沒有更改。

如果主幹上沒有或幾乎沒有變化，則可以選擇進行反向合併（從主幹合併到分支），然後用分支替換主幹。 這種推理也可以在單獨的子文件夾中完成（例如：從分支中替換XML解析器實現子文件夾，保留其餘部分）。 替換文件夾（使用svn delete，svn copy）將保留修訂歷史記錄。

對於在合併期間新添加的文件，如果您使用svn copy命令，則可以從分支複製其修訂歷史記錄。不過，不知道合併命令是否包含對此的支持。

知道是否有一個工具可以執行「rebase」（如在git或mercurial中），這可能很有趣。這將爲分支上的每個更改創建單獨的提交。另一方面，也許個人承諾太混亂了。

我可以給出的最佳建議是使用一個良好的用戶界面（如Trac），以便檢查修訂歷史記錄，以便查看分支上發生的情況。

Answer 2

嘗試svn log -g包含自Subversion 1.5以來存儲的合併歷史記錄。

Answer 3

TortoiseSVN在「顯示日誌」對話框底部的「包含合併修訂」複選框包含提交給分支的註釋。

Answer 4

好答案...如果您還想知道簽入文件和可能的分支名稱，請將-v [--verbose]選項與-g [--use-merge-history]綁定。

例如：

svn log -vg 

的輸出將具有在文件中的檢查（甚至在合併分支），的完整路徑，以及一個（從「revision_url」）消息在修改添加的文件用合併。