【滑稽】用 blog 實現版本控制

　　（實現方法和scheme中的鏈表思想幾乎徹底相同——不過版本控制自己就是一堆指針，參考 連接：git教程 - 廖雪峯的官方網站）

　　博客提供兩個接口：

• 寫博客，能夠在博客裏聽任何內容

• 不限量評論

• 評論能夠刪除

　　博客經常能夠修改。可是這個功能有反作用：修改以後，歷史版本就消失了——因此最終沒有用到這個特性。接下來是實現：

def  建立一個project：

    新建一個具體實現的blog

    新建一個寫上項目相關信息的blog                 #需求的改動按理較少

    用實現blog的網址評論項目相關信息的blog，並註明這是用於實現的東西

def 更新實現：

    新建一個實現的blog（複製原有代碼，修改）

    把項目相關信息blog下的實現地址刪了，加上新的實現地址

def 回退：

    把項目相關信息blog下的實現地址刪了，加上要退到的版本的地址

def 提交分支：

    作一個實現blog

    在項目相關信息blog下追加評論新的地址

def 查看歷史版本：

    打開博客列表

def 合併修改：

    exit("很差意思，不能夠合併修改！")

完工！！

　　很是簡潔漂亮的實現。可是這個實現也帶來了一些問題：

• 若是有很是多的改動，那麼代碼被反覆複製，形成了很是多的冗餘

• 整個工程只有單個文件

• 若是兩我的開發兩個函數，兩人寫出的新代碼，須要仔細思量才能夠整合

　　對於單文件問題，其實blog很容易就能夠支持多個文件。只須要額外建立多個blog，分別寫各個文件，而後在實現的blog裏寫下「本工程包括文件：xxx，xx，xxxx……」便可（固然，要註明對應blog的地址）。若是新的版本改動了其中一個文件，那麼新的實現blog只需在已有基礎上修改其中一個文件的指向便可。

　　對於冗餘的問題，能夠經過引用來解決。好比刪除前3行代碼，新的文件中只須要寫「在xxx的基礎上刪除前三行」。假若有多個這樣的描述，那麼把它們連在一塊兒就是整合修改（衝突是能夠檢查的）——固然這須要一種規範化的語言，來使得可視化變爲可能（藉助php等手段翻譯），不然並沒有法直觀地看到修改後的真實代碼。————說到這裏，你確定會說，這不就是git嗎？————當然是極其類似的，但這時並不是是由git檢查來肯定修改，而是由編寫者來決定哪些地方做了修改，或者要求編寫者總結何處做了修改，或者直接使用新的代碼。這應當會使得代碼更易理解，而且必定程度上能夠標記出代碼的局部回滾（假如只有一個文件須要使用以前的版本）

　　完工了嗎？也許，畢竟即便翻譯須要論壇的支持，我也沒能具體給出某個修改語法。局部回滾也顯得很勉強，彷佛還缺乏一個目錄結構（不過和unix目錄亦文件的哲學很是類似），並且反覆引用會使得求值緩慢（這個能夠在實現的時候使用緩存，blog不可修改，之後的改動不會有反作用——函數式編程）；python的最小單位每每是行，但某些語言的最小單位是類，這時候的修改須要一種新的（多是遞歸的的）標記方式，或者混用多種標記方式；項目信息的描述也可能改變，也須要使用地址……總之，總之……這些都太像開玩笑了。

（2018-6-5 於地球）