使更新檔與更改的源保持同步

是否有任何標準選項來創建適用於文件 F 的“更新檔”P，以便在文件 F 更改為 F’ 時它將繼續正常工作。

所以我要麼有一些機制將 P 變為 P’，以便 P’(F’) 產生與 P(F) 相同的變化，或者，最好我將有彈性 P，以便它可以用於兩個 F ＆ F’。

目前我正在使用正則表達式搜尋和替換來創建這樣的更新檔，但我想知道有沒有標準的方法來做這樣的事情。

這個問題被稱為合併。您有一個原始文件 A 和兩個修改後的版本 B 和 C，並且您想要製作一個結合了這兩個修改的版本 D。這僅在更改是獨立的情況下才有效；否則，合併是一個手動過程。處理原始碼並發更改的合併是軟體工程中的一項常見任務。

在簡單的情況下，diff如果源文件已更改，則由 生成的更新檔已經可以工作。該patch實用程序允許一些“模糊”：如果您製作從 A 到 B 的差異，並且受該差異影響的區域在 A 和 C 中是相同的（但可能在文件中具有不同的偏移量），那麼更新檔將乾淨地應用於 C . 只要 B 和 C 中的更改區域不在相同的位置（必須有幾行分隔），這種方法就可以很好地工作。

當更新檔不能乾淨地應用時，合併是一個困難且特定於域的問題。例如，考慮以下兩個變化：

A         B         C
a=2       a=3       b=2
x=a       x=a       x=b

人類往往會發現 B 已更改2為3C 已重命名a為的模式b，因此合併的結果應該是b=3，x=b。但自動化工具可能會將第一行標記為衝突，因為它已以兩種不同的方式進行了修改。

編寫一個對 B 和 C 都“做一些明智的事情”的更新檔是一個困難的（AI-complete）問題。在實際情況下，對於許多典型情況，使用diff -u A Bas 更新檔往往會工作並從 C 中產生所需的 D，或者會失敗並出現錯誤，指出更新檔不能乾淨地應用。

我真的不推薦sed用於這樣的事情。問題是，即使應用了更新檔，它通常也可能帶有“模糊”——這意味著某些上下文行並不完美匹配。雖然這通常意味著底層的周圍程式碼發生了輕微的變化，但這也可能意味著更新檔應用在錯誤的位置（我已經看到這種情況發生了，它不好並且不容易調試）。

此外，即使更新檔乾淨地應用，它也很可能在語義上不再有意義。但是，要捕捉到這一點，您必須了解修補程式碼中發生的更改。

出於上述原因，至少審查任何適用於 fuzz 的內容被認為是一種好習慣（並且可能還從表面上檢查適用於偏移的任何內容）。擁有超過預設的 3 行上下文可能也是一個好主意。

在經歷了大胖警告之後，相對輕鬆地做到這一點的一種方法是使用版本控制系統，可能是一個高級的發行版，比如 egmercurial或git. 關於這兩者之間的選擇的意見各不相同，Mercurial 比 Git 更類似於舊的 CVS 和 SVN，並且可以說也有更好的學習曲線（雖然 Git 聲稱功能更豐富）。

在 Mercurial 中有針對這些情況的Mercurial Queues (MQ) 擴展。這篇 Steve Losh 的部落格文章是對使用 MQ 的一個很好的介紹，另一個很好的讀物是Mozilla 開發者網站上的MQ 指南。

有時，patchutils也能派上用場。

引用自：https://unix.stackexchange.com/questions/60506