(实现方法和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 于地球)
转载于:https://blog.51cto.com/13535617/2125300