我偶尔会找到具有某种文章历史记录/版本控制的 web 应用程序，您可以在其中选择文章/内容的先前版本，并基本上执行“恢复”过程。我打算有一个这样的人，但我脑子里有一些东西，我想得到你的意见。
1）自动保存是否应该在历史列表中添加新条目？我想实现自动保存功能，所以，我想知道每个自动保存是否应该在版本历史列表中添加新条目？或者我应该为自动保存的文章单独提供“列表”（=最新的自动保存）吗？我认为阶梯更有意义。如果浏览器崩溃（或wtvr），则用户可以恢复自动保存。历史记录列表用于按下提交按钮保存的文章。同意？
2）有多少个版本？如果用户不断修改文章（假设他不断添加新段落）然后保存文章，那么最多应该有多少不同版本的文章？我应该让用户决定（这是我最初的想法）？什么通常是合理的价值？ 10？在光盘存储方面版本控制是件坏事吗？如果每篇文章都有10个版本，那么整个文章内容的空间基本上是10倍......现在想象一下，文章内容为1 MB，整个数据库的内容为10 MB，有些主机的数据库大小也有限制。这导致了问题3：
3）你有没有删除版本？如果文章版本保持足够长的时间，你会删除它们吗？如果是这样，你设定的持续时间是多少？用户定义了什么？一周是否足够的默认值？如果时间不是指标，那么是什么？如果时间是指标，那么你运行Crons进行清理还是什么？
4）如何确定“变化”？如果用户在文章的末尾添加一个点并按下保存按钮，我是否仍会创建新的历史记录条目？你怎么处理这个？您只是比较文章是否已更改，如果是，您创建新条目？
我知道很多问题，但如果你有一些意见或想法，我很高兴听到他们的意见。 ：）
答案 0 :(得分：2)
如果每篇文章都有10个版本，那就是 基本上是10倍的空间 整篇文章内容......现在想象一下 它有1 MB的文章内容 对于整个数据库而言，它将是10 MB 一些主机的大小有限制 DB。
如果您使用网络服务器上的版本控制系统来管理实际条目（例如rcs，subversion），您不必担心更改是否重要，或者需要保留多少，还应该保存在磁盘空间。这些系统已经设计为仅保存版本之间的更改。因此，对于两个版本，对10M文件的一个字符更改仍应为大约10M。