文章版本/历史
我时不时地发现网络应用程序具有某种文章历史记录/版本控制，您可以在其中选择文章/内容的先前版本并基本上执行“恢复”过程。 我正打算拥有这样的一个，但我有一些想法，我想听听你的意见。
1) 自动保存是否应该向历史列表添加新条目？ 我想实现自动保存功能，所以，我想知道每个自动保存是否应该在版本历史列表中添加一个新条目？ 或者我应该有一个单独的“列表”（=仅限最新自动保存）用于自动保存的文章？ 我觉得梯子更有意义。 如果浏览器崩溃（或wtvr），那么用户可以恢复自动保存。 历史列表是他通过按提交按钮保存的那些文章。 同意？
2）有多少个版本？ 如果用户不断修改文章（假设他不断添加新段落）然后保存文章，那么该文章最多应该有多少个不同版本？ 我应该让用户决定（这是我最初的想法）？ 通常合理的值是多少？ 10？ 对于光盘存储而言，版本控制是一件坏事吗？ 如果每篇文章有 10 个版本，那么整个文章内容的空间基本上增加了 10 倍...现在想象一下，有 1 MB 的文章内容，整个数据库将是 10 MB，并且某些主机对数据库的大小有限制。 这就引出了问题 3：
3）您是否删除过版本？ 如果文章版本在足够长的时间内保持完整，您会删除它们吗？ 如果是这样，您设置的持续时间是多少？ 用户定义的？ 默认值一周是否足够？ 如果时间不是指标，那么什么才是？ 如果时间是指标，那么你运行 Cron 来进行清理还是什么？
4）如何判断“改变”？ 如果用户在文章末尾添加一个点并按下保存按钮，我是否仍会创建一个新的历史记录条目？ 你如何处理这个问题？ 您是否只是比较文章是否已更改，如果是，则创建一个新条目？
我知道的问题有很多，但如果您有一些意见或想法，我很高兴听到它们。 :)
Every now and then I find web applications that have some sort of article history/versioning where you can select a previous version of the article/content and basically do a "restore" process. I'm planning on having one like that, but I have a few things in my mind and I would like to get your opinions.
1) Should an autosave add a new entry to the history list? I would like to implement an autosave feature, so, I wonder whether each autosave should add a new entry into the version history list? Or should I have a separate "list" (=latest autosave only) for autosaved articles? I think the ladder makes more sense. If the browser crashes (or wtvr) then the user could restore an autosave. The history list is for those articles that he saved by pressing the submit button. Agree?
2) How many versions? If the user keeps modifying the article (lets say he keeps adding new paragraphs) and then saves the article, how many different versions of the article should there be at max? Should I let the user decide (which was my initial thought)? What is usually a reasonable value? 10? Is versioning a bad thing when it comes to disc storage? If each article has 10 versions, it's basically 10x more space for the entire article content... now Imagine having 1 MB of article content, it would be 10 MB for the entire DB and some hosts have limits as the size of a DB. This leads to the question 3:
3) Do you ever remove versions? If article versions have stayed intact for enough long, will you remove those? If so, what's the duration you set? A user defined? Is one week a sufficient default value? If the time is not the indicator, then what is? And if the time is the indicator, then do you run Crons to do the cleanings or what?
4) How to determine a "change"? If the user adds one dot into the end of the article and presses the save button, will I still create a new history entry? How do you handle this? Do you just compare if the article has changed and if so you create a new entry?
That's plenty of questions I know, but if you got some opinions or thoughts I'm glad to hear them. :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您在网络服务器上使用版本控制系统来管理实际条目（例如 rcs、subversion），您将不必担心更改是否主要，或者保留多少，并且还应该节省磁盘空间。 这些系统已经被设计为仅保存版本之间的更改。 因此，对 10M 文件进行一个字符更改对于两个版本来说仍应约为 10M。
If you use a version control system on the webserver to manage the actual entries (e.g. rcs, subversion) you won't have to worry about whether the changes are major or not, or how many to keep, and should also save on disk space. These systems are already designed to save only the changes between versions. So a one character change to a 10M file should still be roughly 10M for both versions.