何時使用視覺差異與統一差異補丁文件？

注意：此問題最初是在GitHub時代之前提出的。何時使用視覺差異與統一差異補丁文件？

我接管了一些自2002年以來還沒有開發出來的代碼，並且通過隨時間推移發送的補丁來查看。所有這些補丁格式都是unified diff格式，這顯然是提交代碼改進的事實標準。這裏是其中一個補丁看起來像：

@@ -365,7 +385,10 @@ 
    return() unless defined $op_sym; 

    $a_or_b = $op->[OPCODE] ne "+" ? 0 : 1 unless defined $a_or_b; 
- return ($op_sym, $seqs->[$a_or_b][$op->[$a_or_b]]); 
+ my $line = $seqs->[$a_or_b][$op->[$a_or_b]]; 
+ my @ret = ($op_sym, $line); 
+ return @ret; 
}

究竟如何，我應該找出這種變化背景下呢？該補丁不告訴我它影響的子程序。我必須打開原始文件，轉到第365行，然後用修補程序文件中的'+'行在思路上替換那些與修補程序文件中的' - '行對應的現有行。 WTF？

要保留我的理智，我結束了創建原始file的副本file.orig，在file運行patch，然後使用上file.orig和file可視化差異工具，真正看到了什麼補丁在做什麼。

問題是：什麼時候發送整個文件是有意義的，發送補丁文件有什麼意義？

接受修補程序的大多數開發人員是否可以立即發現修補程序在其代碼中提到的內容？如果它刪除文件中經常出現的一行，該怎麼辦？他們會知道補丁在哪個子例程中發生的影響？

也許補丁在帶寬非常寶貴的那一天變得有意義，但是現在的帶寬使得這種擔憂已經過時。我同意補丁文件適用於簡單的更改，如錯字修正。

但是，我還沒有看到開發人員要求通過整個文件提供重要的代碼貢獻（甚至在GitHub或谷歌代碼出現之前）。大家都說「補丁歡迎」，並期待統一差異。他們不是最終在一個可視化比較工具中並排比較文件嗎？那麼character-level intra-line differences？補丁文件不顯示這些。

來源

2009-05-05 Dan Dascalescu

你將遠離我認爲的少數派，但你仍應該重寫這個來提出更多的技術問題 - 「爲什麼使用統一差異？」對於初學者來說可能是一個更好的標題 – annakata 2009-05-05 08:42:18

我對整個源代碼控制世界相當陌生，所以我不能真正權衡利弊（因此評論而不是答案），但我絕對偏愛視覺。 TortoiseSVN的diff工具和WinMerge的組合迄今爲止已經爲我提供了很好的服務。我是一個Windows的傢伙。我喜歡閃亮的東西。 – 2009-05-05 08:42:58

單純從技術層面來說，我認爲補丁比整個文件要緊湊得多，如果你使用了很多補丁，它可以節省存儲空間和帶寬。

當然，人的一面也是如此。您正在挑選7年內未觸及的代碼，但如果您是開發團隊的一部分，那麼您就會對代碼有足夠的瞭解，以便差異性能夠爲您提供完整的信息需要。當討論代碼中的建議更改時，程序員將確切知道上下文是什麼，以及它發生了什麼變化等。

基本上修補程序對於短期更好，但如果您想了解發生了什麼很久以前，你需要整個文件。

來源

2009-05-05 08:53:37 sykora

修補程序確切有用因爲它們隻影響一小部分代碼。考慮開發人員在開源項目上工作的情況。有人下載代碼一週，然後在下週向開發人員提交更改。機會是開發人員已經在處理該源文件，所以其他內容已經發生了變化。使用補丁文件，開發人員可以將補丁應用於現有的源代碼，並且patch程序將找到它應用的位置並應用它。

如果貢獻者發送了整個文件而未識別出發生了什麼變化，開發人員無法知道提交者已更改了哪個代碼。在這種情況下，開發人員如何將補丁應用到最新的代碼？

如果開發人員想要查看貢獻者提交的更改，那麼對於一個小的更改，他肯定可以說「哦，他只是改變了那一點代碼」然後繼續。對於更復雜的更改，開發人員可能會將修補程序應用到項目的臨時副本，並使用可視化diff程序以易於瀏覽的方式顯示更改。

來源

2009-05-05 08:46:51

通過發送補丁程序，可以查看上下文中的更改，即使由於其他更改而不匹配。如果您發送整個文件，接收文件的人不可能知道您已經更改了哪些位，以及哪些位是您將（無意中）從其他人恢復的更改。視覺差異工具和源代碼控制系統可以用來顯示補丁的確切效果。總之，他們更實用，更容易合作。

由於相同的原因，現代源碼控制系統發送變更集（基本上是補丁）而不是整個文件，並且還節省了帶寬。

來源

2009-05-05 08:47:47

**如果您發送整個文件，接收文件的人不可能知道您已更改哪些位，以及哪些位是您將（無意）從其他人恢復的更改。**至少在我正在使用的可視化比較工具（CompareIt），即使大量代碼被移動，我也可以立即看到文件的部分被覆蓋 - 這些顯示通過虛線連接。我還沒有看到一個例子，其中一個補丁文件可能比視覺差異更清晰。檢查一些截圖可能嗎？ http://grigsoft.com/wc3pics.htm – 2009-05-05 09:05:37

我認爲使用視覺差異工具是明智的，如果補丁的影響不是立即顯現的話。所以你需要一種有效的方法。

我結束了創建原始文件作爲file.orig的副本，上運行的文件補丁，然後使用上file.orig和文件視覺比較工具真正看到什麼補丁做。

如果你有你的好副本致力於源頭控制，就可以申請自己的補丁文件（S）直接，然後用你最喜歡的源代碼控制版本比較工具來查看他的變化。

來源

2009-05-05 08:58:56 joeytwiddle

何時使用視覺差異與統一差異補丁文件？

回答

相關問題