我相信 Wordpress 将多个帖子条目存储为“修订”,但我认为这对空间的使用效率非常低?
有没有更好的办法?我认为gitit是一个使用 GIT 进行版本控制的 Wiki,但它是如何完成的呢?例如。我的应用程序是 PHP 的,我必须让它与 GIT 对话以提交和检索数据?
那么,什么是在 Web 应用程序中实现版本控制的好方法(例如,在博客中它可能是帖子内容)
我相信 Wordpress 将多个帖子条目存储为“修订”,但我认为这对空间的使用效率非常低?
有没有更好的办法?我认为gitit是一个使用 GIT 进行版本控制的 Wiki,但它是如何完成的呢?例如。我的应用程序是 PHP 的,我必须让它与 GIT 对话以提交和检索数据?
那么,什么是在 Web 应用程序中实现版本控制的好方法(例如,在博客中它可能是帖子内容)
我最近实现了这样一个系统——它使用了被取代记录的概念,以及以前和当前的链接。我对如何最好地实现这一点进行了大量研究——最终我得到的模型类似于 Wordpress(和其他系统)——将更改存储为新记录并使用它。
考虑到所有可用的选项,空间确实是诸如帖子之类的创作内容的最后一个问题——媒体文件占用了更多的空间,而且无论如何这些都不能存储为增量。
无论如何,Git 的工作方式实际上是相同的,因为它存储了每个修订版的全部内容,只是它最终会打包成 deltas(或者当你要求它时)。
回到 1990 年,我们使用的是 SCCS 或 RCS,有时只有 30mb 的可用磁盘空间,我们确实需要有效的版本控制来避免存储空间不足。
考虑到现代系统上的平均可用存储量,使用增量来节省空间并不值得所有相关的恶化。你可能会说这很浪费空间,但我认为从长远来看,以原始形式存储未压缩的东西会更有效率
此外,标记的表现不如带有增量的纯文本,尤其是在使用所见即所得编辑器进行编辑时。
与最新版本的例如文章保持一张表。
保存新版本时,将当前版本移到存档表中并在其上放置版本号,同时将最新版本保留在第一个表中。
存档表可以具有属性 ROW_FORMAT=COMPRESSED(MySQL InnoDb 示例)以占用更少的空间,并且它不会成为性能问题,因为它很少被访问。是的,不仅存储变更集有点开销,但是如果您进行一些数学运算,您可以在几乎没有空间的情况下保留大量修订,因为您的文章无论如何都是高度可压缩的文本。
例如,整个页面的源代码是 11Kb 压缩的。这在 1Mb 上为您提供了近 100 个版本。相比之下,普通文章要小得多,平均可以在 1Mb 上为您提供 500-1000 篇文章/版本。你可能负担得起。