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

　?。▽崿F方法和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等手段翻譯），否則并無法直觀地看到修改后的真實代碼?！f到這里，你肯定會說，這不就是git嗎？————固然是極其相似的，但這時并非是由git檢查來確定修改，而是由編寫者來決定哪些地方作了修改，或者要求編寫者總結何處作了修改，或者直接使用新的代碼。這應當會使得代碼更易理解，并且一定程度上可以標記出代碼的局部回滾（假如只有一個文件需要使用之前的版本）

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

（2018-6-5 于地球）