文件歷史記錄：在source中還是讓scm處理呢？

Question

我正在學習mercurial作爲我的solo scm軟件。使用其他管理軟件，您可以通過標籤將更改註釋放入文件標題中。使用hg您可以對變更集進行評論，但這並沒有涉及到源代碼。我更習慣於像VSS這樣的中央控制。

爲什麼要將文件歷史記錄放入源文件的標題中？我應該讓mercurial用我的變更集註釋管理歷史記錄嗎？

Answer 1

讓源代碼管理系統處理它。

如果您在頭文件中添加更改詳細信息，它很快會變得笨拙並壓倒實際的代碼。

此外，如果scm具有更改列表的概念（其中許多文件被分組爲單個更改），那麼您將能夠編寫評論，以便它適用於整個更改，而不僅僅適用於整個更改文件（如果這是有道理的），給你一個清晰的圖片說明爲什麼需要編輯。

Answer 2

是;讓源代碼控制系統處理您的變更集註釋。其基本原理是，當您稍後查看更改日誌時，它會更有意義，試圖解決兩個版本文件之間發生的事情 - 源代碼管理系統可以提供更改註釋以嘗試啓發情況。

Answer 3

當SCM軟件更適合解決此問題時，沒有理由手動維護文件歷史記錄。我經常看到源文件中部分完成的文件歷史記錄，這實際上很痛苦，因爲人們錯誤地認爲它是準確的。

Answer 4

我不是一個很大的支持者，通過更改評論來拋棄代碼。如果需要它們，可以在SCM中查找它們（至少對於我使用過的SCM變體）。如果你確實希望他們在文件中，可以考慮把它們放在最後而不是開始。這樣，在你到達實際的代碼之前，你不必向下滾動（通過對我至少不感興趣）。

Answer 5

我有這方面的經驗。我在評論中有文件記錄，這是可怕的。除了垃圾之外，有時你需要向下滾動幾乎1千行的代碼，然後才能最終達到你想要的水平。更不用說，通過在您的源代碼樹中添加更多的kb，您正在減慢構建過程的其他方面。

Answer 6

更容易忘記在源代碼中保留歷史記錄，因爲總是（imo）應該註釋提交給源代碼管理系統的問題消失者。另外，如果在提交之前更改大量文件，那麼在每個文件中更改歷史記錄都會很麻煩。這真的是scm的一個要點。

Answer 7

另一個讓SCM系統處理簽入評論的投票，但我確實有一件事要補充。

某些系統允許您在源代碼中使用RCS標籤，SCM可以將更改歷史記錄直接插入到自動提交的源文件中。聽起來像一個很好的平衡，因爲歷史是在SCM系統中，然後自動放入源代碼本身。

問題是這個過程改變了的源文件。我認爲這是一個壞主意，因爲直到插入評論後才能在磁盤上更改文件。如果您是一名優秀的工程師，則應在提交之前構建並測試更改。如果在提交之後你的源代碼發生了變化，那麼你基本上已經有了一個可以被破壞的構建 - 但是大多數工程師在提交之後不會構建 - 他們爲什麼要這樣做？

但這只是你說的評論！沒錯，但我確實有一個案例，在我的源文件中有代碼奇怪地足以讓看起來像RCS標頭標籤，並且該代碼的部分在checkin中被替換，從而消耗我的代碼。很容易修復，但很糟糕，一個構建破壞了20多個用戶

Answer 8

區別不在於它是集中式還是分佈式VCS，它更多的是關於什麼被改變。

當我轉移到.Net時，任何單個更改更新的文件數量似乎飆升。如果我必須在每個文件中記錄更改，我永遠不會完成任何真正的工作。通過評論這組更改，我不得不更新多少個文件。

如果我需要識別特定更改的所有更改，我可以在項目的兩個版本之間進行區分。

我從SourceSafe切換時看到的最大區別（和優點）是從文件切換到基於項目的提交。只要我習慣了這一點，我就不再爲我的所有文件添加更改日誌類型註釋。

（作爲一個副作用，我發現我的過程描述評論已經變得更好）