|
|
英文原文：Astonishments, ten, in the history of version control
引言：
“如果你想要了解真正的歷史，你需要回到在打孔卡上進行人工比對的年代。” —— Jim Rootham
在這個為鱈魚編寫傳記都能夠流行的年代，寫一本記錄程序員如何存儲代碼——他們最重要的勞動成果的書一點也不瘋狂。
既然你和我都沒有時間來閱讀或編寫這樣的一本書，我們打算用這篇博客來進行探討。
這是一個重要的問題。
（現在）版本控制產品非常普通而且很流行。
然而，它經歷了幾十年的不斷創新。在這個領域里最聰明的人的努力下，代碼管理變得非常簡單而且有效。
每一步都是那么讓人感到驚奇。
1. 源代碼就是一個文本文件！（20世紀 60 年代）
現在看來，存儲源代碼和編寫簡單文檔應該是一樣的。但如果你簡單讀一下 ASCII 的歷史就會知道，即使達成這樣的共識也來之不易。
2. 人們可以手動跟蹤代碼版本！（20世紀 60 年代）
在沒有軟件的年代，所有事情都要從源代碼開始。
“我工作的第一家公司有一個源碼管理部門。當你把代碼寫好以后，將軟盤交給源碼管理部門一位漂亮女士。他們會及時更新函數庫，用你的磁盤基于公司官方的代碼構建產品交付給客戶。” —— Miles Duke
3. 你可以為單個文件保留多個版本！（1972，1978）
采用奇特的交錯編織文件格式，SCCS 在版本控制領域稱雄了 10 年之久。
記錄單個文件的從一個版本到下一個之間的變化花費了幾年的時間。“差異文件比較算法”是這個課題最近發表的一篇論文（1976）。
1982年，RCS 反向使用 diff 文件（描述算法原文）打敗了 SCCS 成為繼任者，并讓評論家大跌眼鏡：
“一起出現的還有帶有反向比較功能的 RCS，我認為它非常棒。” —— 無名氏
4. 每個人都可以簽出自己的拷貝！(1982)
在那個時候，人們工作時需要登錄一臺中央大型機并通過它一起工作。采用符號鏈接，RCS 可以讓每個人都工作在相同版本的代碼上，而且每個人都有自己的工作拷貝。
“有一個叫做 RCS 的文件，實際上它十一個鏈接到 RCS 倉庫的符號鏈接，你可以與其他小組成員一起使用。” —— 耶魯大學 RCS 使用介紹
5. 喔！你可以一次給多個文件進行版本控制！（1986）
令人吃驚的是，直到 CVS 出現之前，版本控制系統都只支持單個文件。當然，你可以使用通配符讓 RCS 提交多個文件或者標記特定分支。但這些并不是版本控制系統的一部分。
CVS 默認會遞歸修改所有文件。突然之間，軟件從單個目錄或文件變成了文本文件的遞歸樹。
雖然由于不具備“原子性”導致實現的產品不盡如人意（后來 Subversion 在 2000 年解決了這個問題），但是瑕不掩瑜。
6. 兩個人可以同時編輯同一個文件，并將他們的工作合并在一起！（1986）
20 世紀 90 年代末，我在 Creature Labs 工作。我們從 Visual SourceSafe（商業軟件，微軟公司發布）轉到 CVS（開源軟件，由一些嘻皮士發布）。
坦率的講，大家都懷疑 CVS 能否做到它宣稱的那樣：讓多個人同時編輯同一個文件，并將他們的修改沒有錯誤地合并到一起而不造成其他問題。
在我們開發 Creatures 3 的時候，SourceSafe 的互斥鎖成為了一個大問題。我們當時要添加垃圾搜集功能，這個功能會影響到幾乎所有的代碼。這個時候，我們的首席程序員不得不在周末簽出每一個文件然后進行修改。
1986年的這篇論文記錄下了這個奇跡。當 Dick Grune 和他的團隊在荷蘭開發一個編譯器的時候，他們遇到了同樣的問題，CVS 從此應運而生。
7. 可以在遠程服務器上共享代碼倉庫！（1994）
大多數時候，人們只在一臺機器上使用版本控制。在 1986 年，人們可以通過 RCS 的一些版本以及 CVS 提供的遠程文件共享機制以擁有遠程代碼倉庫。
“假如 RCS 的某個版本可以通過遠程服務器訪問，那么開發人員就可以在代碼倉庫之外的機器上進行開發了。” —— Dick Grune
然而，直到 1994 年 TCP/IP 協議的引入，這個想法才得以起步。
“直到 Cygnus 軟件的 Jim Blandy 和 Karl Fogel（這兩位后來成為 Subversion 項目的主要開發者）為 CVS 發布了一些補丁，使得 CVS 客戶端軟件可以通過遠程 TCP/IP 連接進行訪問，CVS 才真正變得無處不在。 ”—— Eric Raymond
8. 免費的開源版本控制主機服務！(1999）
這并不是源碼管理技術的進步，但這的確是一個標志，InterNET 社區的發展與技術的進步同等重要：
“OSS 以及成為歷史，這已經成為一種趨勢。John T. Hall 預見到，如果項目都是在線開發，那么之前開發的版本就在那里。開發平臺服務是一種創新，但是沒有人去做，我們就想‘為什么不呢？’”—— Brian Biles
就像末日狂歡那樣（因為股票的原因），VA Linux 把 SourceForge 帶到了這個世界上。這對新項目是天大的好消息（例如我的 TortoiseCVS）。
在當時，在 InterNET 上獲得一臺服務器很困難而且非常昂貴，進行源碼管理和 bug 追蹤也是如此。這項新服務盡管缺乏商業模式，卻讓無數項目更早地面世。
譯注：OSS，一個綜合的業務運營和管理平臺，同時也是真正融合了傳統 IP 數據業務與移動增值業務的綜合管理平臺。
9. 沒有主代碼庫，你可以向所有人發布！（2005）
在 21 世紀頭 10 年，有一股將版本控制實現完全分布式的潮流。
也就是說，在你本地的機器上存放的是一份完整的代碼歷史，可以輕易地與任何其他拷貝進行分支和合并。順帶說一下，也正是這個特性使得分支和合并變得更加容易。
我并沒有記錄某個人第一次發明這種工具，而是按照它產品化以及流行的時間進行統計。鑒于此，將它定在 2005 年似乎有些不公平。Mercurial 和 Git 發布于 2005 年 4 月。
這篇“分布式版本控制風險”（2005年底）介紹了這個革命性的創新。
10. 當你簽出一個 fork，你可以讓大家都看到！（2008）
GitHub 的成功有很多原因（盡管我之前提到過一些，要講清楚這個問題還是需要單獨寫一篇文章討論）。
關鍵在于，你可能甚至可以將一些自己做的不大的改動提交到別人的公共代碼上。在 GitHub 之前，一般我們會保存在自己的電腦上。
如今，只需要簡單做一個 fork，或者甚至可以直接在瀏覽器上編輯，這樣任何人都可以馬上發現你代碼中的 bug。
尾聲
快速回顧一下這幾十年的進展。是的，計算機的發展做出了貢獻。但更主要的是，這些都是人們為更好地協作而貢獻出的聰明才智。
這讓我想到，下一個會是什么？在版本控制領域還會有什么令人驚嘆的事情發生？
推而廣之，同樣的事情會在其它領域發生嗎？
作為核心信息基礎設施，這種巨大的改進能夠最終改善政府、醫療、新聞或者數據領域創新的障礙嗎？
我有這種感覺，我們就要找到答案了。
想了解更多嗎？請閱讀《版本控制時間軸》（發表于 Plastic SCM 的博客，不要忘記看一下評論）以及《理解版本控制系統》（作者 Eric Raymond）
it知識庫：版本控制工具歷史的10個里程碑，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
