Hi 大家好，我是姜友华。 最近想了解一下纯文本的版本管理，类似于最基本的Git。

版本管理，百度百科上有详细的说明，想了解的同学可以看看。版本管理的根本就是记录下用户所有版本的内容。于是设计的重点落在冗余的控制上。

一、冗余的处理

1. 完整版本管理

这是最简单的版本管理方式，将所有版本完整的保存下来。最简单的往往是最有效的，不用控制冗余，版本间没有关联，使用时各种方便。于是唯一的缺点是体积大，占些存储空间和上下行的带宽。这个在纯文本的世界好象也无所谓，传说GIT是这样实现的。

2. 向前版本管理

只完整保存最开始的版本，其后的版本只保存差异的部分。冗余当然是最小的，版本之间存在强关联，某一个版本受损，会影响其后所有版本。最大的缺点是，某一个版本受损造成当前内容出错。这个版本管理方式基本没人使用。

3. 向后版本管理

与向前片本管理相反。只保存最后的版本，其前的版本只保存差异的部分。冗余当然也是最小的。版本之间依然是强关联，某一个版本受损，会影响其前所有版本。但与向前版本管理相比：好处是，人们更在意当前版的完整性。

4. 关键版本管理

到了这里，往往会产生一个折中的方案。这个方案是在向后版本管理中（当然向前片本管理也可以），再加一些完整的版本进去，这些版本比较关键，比如说与前一个版本差异比较大的。这样也就存在一些冗余，但也增加了一些稳键性。

不管你用哪一种方法，存空间都有不够的可能。

二、空间的处理

1. 移除旧版本

空间不够怎么办，把旧的去掉。毕竟越早的存在的价值越小。

2. 移除小版本

当然也可以移除变化小的版本。毕竟改越小胡存在的价值也越小。

3. 让用户去处理

让用户自己来管理也是一个不错的选项。

不管怎么处理，对于存在强关系的版本，我们需要重新处理被删版本的前后关系以保证整体的有效性。

三、版本比较

1. 最长公共子序列

不论是对冗余的处理，还是不同版本之间的比较，会涉及到一个算法叫最长公共子序列。用它来找出不同的部分。

a. 出两者之间的最长公共子序列；
b. 按该序列将文本各自分割为两部分，各部分对应进行1的操作到最后；
c. 我们需要设置匹配的颗粒度。英文的词比较好处理，一般使用词来匹配；中文分词是个技术活，所以中文一般使用字。

2. 中文分词

如果你一定在中文里使用词来匹配，那你一定要了解中文分词。这问题很早被提出并解决，但一直无法解决好的问题，最终被归于属自然语言处理的技术范畴。

字符匹配算法

这个方法是最早用来解决中文分词的方法。在这个算法里你需要词典。

• 最大匹配算法，
  a. 拿字符与词典匹配，没找到，选择两头移除一个字再找，找到即可；
  b. 按找到的割字符，再重复步骤a.。
  c. 可使用的方式有：正向最大匹配法（从左移除）、逆向最大匹配法（从左移除）、 双向最大匹配法（每一步，两头各试一次）。

• 由小到大匹配算法
  名字是我乱取的，这是以前在实际应用中的一个方法。对应中文分词比较有效，因为中文的词一般不超过4个字不小于2个字。
  a. 以两个字为匹配单元，从一头移向另一头。
  b. 匹配成功，后添一个再匹配。
  c. 匹配失败，匹配单元留下最后一个，移除的为一个词。
  如果应在最长公共子序列，这里是我以前的该算法的实现，需要两头尝试。

深度学习

百科里的理解法与统计法，听起来不错，但暂时没找到案例，也没想到实现的方案，所以这里就没法明细去讲了。
我能想到的使用深度学习来处理的方法大概是：

• 输入一些人工分好词的词子去训练。

需要你注意的是，我没有真正实现过，有空时我再试一下。

好吧，就这些，我是姜友华，下次见。