記事のバージョン管理/履歴

Question

時々、過去のバージョンの記事/コンテンツを選択し、基本的に＆quot;復元＆quot;を実行できる、記事の履歴/バージョン管理のような web アプリケーションを見つけます。プロセス。私はそのようなものを持っているつもりですが、私はいくつかのことを心に留めており、あなたの意見を聞きたいです。

1）自動保存で新しいエントリを履歴リストに追加する必要がありますか？自動保存機能を実装したいので、自動保存のたびにバージョン履歴リストに新しいエントリを追加する必要があるのでしょうか？または、別の「リスト」を用意する必要があります。 （=最新の自動保存のみ）自動保存された記事ですか？はしごのほうが理にかなっていると思います。ブラウザがクラッシュする（またはwtvr）場合、ユーザーは自動保存を復元できます。履歴リストは、送信ボタンを押して保存した記事用です。同意しますか？

2）バージョンはいくつですか？ユーザーが記事の変更を続け（新しい段落を追加し続けているとしましょう）、記事を保存する場合、記事のバージョンは最大でいくつ必要ですか？ユーザーに決定させる必要がありますか（これは最初の考えでした）？通常、妥当な値は何ですか？ 10？ディスクストレージに関しては、バージョン管理は悪いことですか？各記事に10個のバージョンがある場合、記事のコンテンツ全体で基本的に10倍のスペースがあります...今では1 MBの記事コンテンツがあると想像すると、DB全体で10 MBになり、一部のホストではDBのサイズに制限があります。これは質問3につながります：

3）バージョンを削除したことがありますか？記事のバージョンが十分な時間そのまま残っている場合、それらを削除しますか？その場合、設定する期間はどのくらいですか？ユーザー定義？ 1週間で十分なデフォルト値ですか？時間がインジケータでない場合、それは何ですか？時間が指標である場合、Cronsを実行してクリーニングを行いますか？

4）「変更」を判断する方法ユーザーが記事の最後に1つのドットを追加して[保存]ボタンを押した場合でも、新しい履歴エントリを作成できますか？これをどのように処理しますか？記事が変更されたかどうか、そうであれば新しいエントリを作成したかどうかを比較しますか？

それは私が知っているたくさんの質問ですが、あなたが意見や考えを持っているなら、私はそれらを聞いてうれしいです。 ：）

Answer 1

  

各記事に10のバージョンがある場合、   基本的に10倍以上のスペース   記事の内容全体...今想像してみて   1 MBの記事コンテンツがある場合、   DB全体で10 MBになり、   一部のホストには、サイズの制限があります   DB。

実際のエントリ（rc、subversionなど）を管理するためにWebサーバーでバージョン管理システムを使用する場合、変更がメジャーであるかどうか、保持する数、および保存する必要があるかどうかを心配する必要はありません。ディスク容量。これらのシステムは、バージョン間の変更のみを保存するように既に設計されています。したがって、10Mファイルへの1文字の変更は、両方のバージョンで約10Mのままです。