我從源代碼控制的角度來看，有一些舊的代碼（一箇舊的但仍然保留的VB6應用程序）是管道工管道的最終示例或鞋匠的鞋）。它的版本是通過爲每個版本創建一個新目錄的方法來控制的。在源代碼控制中放入一個經過版本控制但不通過源代碼的控制項目
採取以下方法有什麼主要缺點嗎？
請注意，我有一個通用的更改日誌文本文件，我會爲每個檢查/提交的版本獲取評論。我沒有（或者真的關心這一點）每個文件的評論。
我現在還不知道哪些文件在版本之間發生了變化，而且我很懶，因爲我可以避免在文件版本之間進行比較以找出問題，所以這就是爲什麼我採取上述方法。更不用說，首先刪除所有文件允許檢測文件刪除。
我特別沒有提到我正在使用哪個版本控制工具，因爲我希望（也假設，但可能非常不正確）答案是相當獨立的。當我使用諸如「簽入」之類的術語時，我將它們用於一般意義上，而不是特定於工具。
這是一個合理的方法。一些源代碼管理系統（例如TFS）會默默地忽略嘗試檢入未更改的文件。這是一件好事。如果你沒有這個功能，我建議對所有文件進行差異檢查，只檢查修改後的文件。否則，您會向文件歷史添加大量噪音。
另外不要忘記，您將不得不手動協調在版本之間添加，刪除和重命名的文件（同樣，這取決於您的SCM軟件）... – 2010-03-29 00:40:46
@codeka - 好點，我忘記了這一點...鑑於此，我不確定我可以避免明確找出我的增加和刪除版本（但我選擇這樣做）的過程。同意？ – Emilio 2010-03-29 01:06:18
但至少你只需要逐個文件地完成它，而不必實際查看差異文件。另外，如果你使用類似TortoiseSVN的東西，它可以很容易找到已添加的文件（儘管你不知道已刪除的文件）。 – 2010-03-29 01:13:36
對以前版本所做的更改是否有價值？
如果這或多或少地被代碼化，它不是維護產品發佈歷史的一部分，維護歷史可能沒有多大價值。將目錄拉到某處（以防萬一）並將最新版本放在源代碼管理中。可能不需要做大量的工作來創造一個沒有價值或沒有價值的歷史。作爲一個例子，當轉向新版本控制系統時，許多組織可能只是使用現有系統的頭部（或者可能是一組分支）啓動新系統，並且必須返回到舊系統歷史超出切換日期。
@邁克爾 - 歷史的價值肯定是低的，但維持它滿足了我最低程度的訂單需求。如果這是一個工作項目而不是個人項目，而且歷史價值很低，那麼我不會這麼做。 – Emilio 2010-03-29 00:43:00
@Emil：他說得對，並非每個版本都是必不可少的。發佈的版本是，但其餘的是可選的。 – 2010-03-29 02:24:02
@Emilio：當然只有你可以確定歷史的價值 - 我只是建議將它考慮在內，因爲我認爲在很多情況下，有人可能會有一個快速反應，你必須把歷史因爲它以某種形式可用。此外，不要忘記，如果你有一個你有歷史的原始目錄的檔案，只是一個很痛苦的訪問。但是，如果你只需要在藍色月亮下訪問它，那可能是好的。 – 2010-03-29 02:35:42
如果您使用過Git，它會自動檢測重命名，因爲它無論如何都會根據變更集對變更集進行檢測。 如果您使用了Mercurial，它有一個'請嘗試爲我找到重命名'功能。 我想Bazaar（sp？）有類似的東西。 任何你不考慮DVCS而不是SVN的理由？無需中央位置，並且可以輕鬆移動。非常輕巧，而且相對容易使用。 我使用Mercurial，主要是因爲我有Windows工作，並且我相信Mercurial在Windows上仍然比Git好。 – Mikezx6r 2010-04-01 02:38:47