1

時々、記事/コンテンツの以前のバージョンを選択して基本的に「復元」プロセスを実行できる、ある種の記事履歴/バージョン管理を備えたWebアプリケーションを見つけます。そんなものを考えていますが、心に浮かぶことがいくつかありますので、ご意見を伺いたいと思います。

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

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

3)バージョンを削除したことはありますか?記事のバージョンが十分長い間そのまま残っている場合、それらを削除しますか?もしそうなら、あなたが設定した期間は何ですか?ユーザー定義?1週間で十分なデフォルト値ですか?時間が指標ではない場合、それでは何ですか?そして、時間が指標である場合、あなたは掃除をするためにCronsを実行しますか、それとも何ですか?

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

たくさんの質問がありますが、ご意見・ご感想をいただければ幸いです。:)

4

1 に答える 1

2

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

Web サーバーでバージョン管理システムを使用して実際のエントリ (rcs、subversion など) を管理する場合、変更がメジャーかどうか、保持する変更の数を気にする必要がなく、ディスク容量も節約できます。 . これらのシステムは、バージョン間の変更のみを保存するように設計されています。したがって、10M ファイルへの 1 文字の変更は、両方のバージョンで約 10M になるはずです。

于 2009-06-19T11:47:55.240 に答える