【滑稽】用 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 于地球）