重構SVN分支代碼

我正在拼命工作的一個項目需要重構。問題在於通常有多個分支（維護，新功能等），我不確定我們可以輕鬆移動，重命名和刪除文件和目錄併合並更改。我擔心的是我會在重構分支中移動文件，而其他人正在更新另一分支中的文件。我一直希望有一個小窗口，幹線擁有一切，不需要分支機構，但業務總是需要更改（立即或作爲次要版本的一部分）。重構SVN分支代碼

我們的源代碼管理使用Subversion進行管理。在保持變更與其他人同步的同時，是否可以在一個分支中大幅改變項目？我非常喜歡合併更改以使分支保持最新狀態，也許只是一次只進行一些小的重構更改就行了。否則，這隻能通過留出一些時間來處理重構（即沒有其他分支）來完成嗎？我一直在試圖說服企業主，我們需要一些時間來重構，並且雖然他們同意，但現在看起來似乎不可能。

關於重構的一個重要的事情是它應該始終完成（不只是一次一次）。這似乎可以用實際代碼來實現（分解函數，刪除重複的代碼等），但我對適當重命名和分組文件沒有那麼自信。

來源

2012-07-25 ravun

這是可以在SVN，但我可以告訴你，你會面對很多不同的問題。如果你真的想要重構到每個分支想三次？將重構代碼合併到發佈分支（這是用於發佈生產版本的小修補程序的維護分支）似乎並不合理。

雖然SVN可以讓你從任何分支合併到任何分支，但在分支和原始分支之間合併總是更合理。因此，如果你有這樣的事情：

Rel-1.0   /----------------> 
Rel-1.1  / /-------------------> 
Trunk  --------------------------------*------> 
FeatureA   \--------> \  \ ^(rev. X) 
FeatureB      \--> \ | 
Refactor        \--->

而不是在重構做的重構工作，並將其合併到每一個其他的分支，它是更合理的重新整合在重構分支主幹的變化（修訂假設X ），然後將版本X從Trunk合併到需要此更改的其他分支。對於發佈分支（Rel-1.0，Rel-1.1），它很可能是櫻桃樹。對於功能分支A/B，它將趕上Trunk（通過合併Trunk中的所有東西）。

請注意，如果您的分支更偏離樹幹，合併會變得更加困難。因此，如果你真的需要合併重構代碼來釋放分支（這很可能非常偏離幹線），請三思。

請注意，在SVN中重命名的跟蹤並沒有很好地實現。例如，您將trunk中的文件F重命名爲FNew，SVN通過從F複製來添加FNew，並刪除F.如果將它合併到分支，afaik，SVN所做的是通過從trunk/F和刪除分支/ F。因此，如果你曾經修改過branch/F，對於較新版本的SVN（可能> = 1.5），它會產生一個樹衝突，而在較早版本的SVN中，你甚至會失去修改。雖然新版本處理好一點，但他們都沒有處理合並重命名「正確」（這將分支/ F移動到分支/ FNew）。這會導致您在合併時做出額外的努力，並且在兩個分支偏離很多的情況下導致合併更加困難。

來源

2012-07-25 02:10:53

-1

我想你可以修改一個分支，創建補丁文件並使用相同的補丁文件來更新所有其他分支？

來源

2012-07-25 01:15:54

這是一個好主意。我從來沒有使用補丁文件，除非我已經下載補丁文件來修補其他人的代碼。 – ravun 2012-07-25 01:41:27

使用補丁不會幫助，並且您也失去了SVN的合併跟蹤。簡單地使用合併是好的 – 2012-07-25 01:53:04

哎呀，這是很好的信息要知道。 – ravun 2012-07-25 02:06:45

如果你徹底改變了一個分支，你肯定會遇到合併你的代碼的問題，尤其是當其他人正在修改相同的文件時。

我會在這裏推薦一些聰明的日程安排。您將不得不處理目前尚未開發的部分代碼。或者，使重構成爲正常業務操作的一部分。

來源

2012-07-25 01:25:17

重構SVN分支代碼

回答

相關問題