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. 匹配失败,匹配单元留下最后一个,移除的为一个词。
如果应在最长公共子序列,这里是我以前的该算法的实现,需要两头尝试。
深度学习
百科里的理解法与统计法,听起来不错,但暂时没找到案例,也没想到实现的方案,所以这里就没法明细去讲了。
我能想到的使用深度学习来处理的方法大概是:
- 输入一些人工分好词的词子去训练。
需要你注意的是,我没有真正实现过,有空时我再试一下。
好吧,就这些,我是姜友华,下次见。
网友评论