SVN從主幹合併更新分支讓我經過大量的文件的作者修改

Question

cd my/branch 
svn up 
svn merge my/trunk 
svn commit -m 'merged from trunk' 

然後我用

svn blame somefile 

我看到的不是我做了一些改變，但表示，它的作者是我的。

我的問題是，這是svn分支開發的正常工作流程，如果我是一個承諾，即使這些更改來自svn update或svn merge，作者應該是我嗎？

Answer 1

是的，你爲什麼作者合併？這不像你承諾的代碼中的變化。哦，等一下...沒關係。我的錯。

作者始終是Subversion中的提交者。當您進行合併時，您是負責驗證更改是否有效的人員。即使沒有合併衝突並不意味着合併實際工作。可以有邏輯合併衝突，標準合併不會檢測到，但同樣致命。這就是爲什麼合併的人員仍然必須測試和驗證他們的工作。

我通常看到這個問題時，人們使用原始主幹做工作的方法。你想把你的工作合併到包含發佈代碼的主幹中。開發人員在分支上開發他們的代碼，版本工程師負責將此代碼移到中繼。

我不是這種方法的粉絲：

• 正如你所說，你現在對代碼進行修改怪。
• 當您執行svn log時，日誌會默認向下行進，但不會告訴您有關歷史記錄的任何信息。你看到的只是釋放工程師做了一個又一個的改變。
• 通常情況下，你有一個想法，即從每個版本的trunk中分支出來，但是最終在上一版本完成之前分支到下一個版本，這意味着通常最終會在下一版本中缺少修復的bug修復之前的版本。
• 記住合併回幹線需要做很多工作。
• 而且，甚至沒有必要。你標籤版本，你可以看到發佈的內容和通過標籤比較版本。

我寧願打工中繼線作爲主碼分支。當你到達一個要在多個版本上工作的點時，分支脫離了發行版的主幹，並且您將發行版標記爲脫離該分支。如果您需要修補程序或修補程序，則可以使用一個分支。

此過程不會消除功能分支。你不要不得不只在樹幹上發展。它消除的是需要原始主幹這是很難維護，並增加幾乎沒有任何價值的發展過程。

Answer 2

你是merge-revision的作者，因此對於SVN（這個版本的責任），你是改變字符串的作者 - 責備不執行任何回顧性分析，也不區分merge-commits和普通承諾

是這個分支的正常工作流程SVN

是發展。這是絕對正常和標準的使用（任何）VCS