博客提供两个接口：
写博客，可以在博客里放任何内容
不限量评论
评论可以删除
博客常常可以修改。但是这个功能有副作用：修改之后，历史版本就消失了——所以最终没有用到这个特性。接下来是实现：
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 于地球）
原文地址：http://blog.51cto.com/13535617/2125300
