Yuki/改版履歴管理機能 - Neptune Wiki - Neptune

Yuki/改版履歴管理機能

Yukiのアイテム作成時に、アイテム情報として作成日時、及び作成者情報を記録する。
これら記録された情報を参照することにより、誰が、いつ、どんな修正をしたか一発で分かる。

またこれらの情報を記録しておくことにより、xx年xx月xx日の時点ではどんな状態だったかも、
（その日付以降のアイテムを削除したデータを作る事により）見ることが出来るし、
その時点でのソースにロールバックする事も簡単になる。よもやバージョン管理システム等と言った「古臭い」システムは不要になるわけである。

なおこれだけだと、削除したアイテムや既存アイテムを修正した場合にそれらの情報が管理されなくなってしまうので、以下のようにする。

アイテム削除時：

• 削除したアイテムを Deleted Pool に移動する。
• と言うか削除処理自体が、完全にアイテムを削除するわけではなく、既存のリンク関連から外し、Deleted Pool に移動したとするフラグを立てる作業になる。

アイテム修正時：

• 既存のアイテムコピーし、Unlinked Pool に移動する。
• その後既存のアイテムに修正を行う。これにより前のアイテムの状態が保たれる。
• まぁ、無駄なアイテム情報一式をコピーするので、アイテムのサイズによっては超無駄が発生するかも知れないが、とりあえず昨今のストレージサイズやネットワーク速度を考えればたいした問題ではない！！ハズ・・・。
• もしどうしても・・・と言うのであれば、修正した部分のみの、その修正前の情報が入っているアイテムを生成し、Unlinked Pool にコピーする。処理が複雑になるので余りしたくは無いが・・・。

チェックポイント

単にこれらだけだと、データが破損した場合に、全く持って過去の状態を把握できなくなる可能性がある。
なので、チェックポイントを設け、定期的にまるまるの情報を保存しておいた方がいいかも知れない。

回数

一定回数ごとにとる方式（例えば10回ごととか）

時間

一定時間ごとにとる方式（こっちはあんま必要ないかな・・・）

人間的方式

一体どう人間的なのか。

人間は新しい事はよく覚えているが、昔の事になれば昔の事になるほど忘れてしまうものである。当然である。
同じように、昔であれば昔であるほどチェックポイントの間隔が開く。

・・・と言うのを具体的にどうロジックで実現するかと言えば、例えば、5回ごとにチェックポイントを取るとする。
ただし、20回より昔のものは10回ごと、50回より昔のものは50回ごとにとる・・・としたい場合、
まずは普通に5回ごとにとる。んで、とった時、20回より前の奴が5回ごとになっていれば、それを10回ごとに直す。つまり、その間の一回の情報を消す。
50回より昔のものも同様。

基本的に人間がそうであるのと同じように、昔のものであれば昔のものであるほど要らないはずなので、このようなロジックでも問題ない
・・・と言うか一番理想的ではないんかなー、と思う。

チェックポイントを取っておくと

パフォーマンス的にも良いかもしんないですね。つーかパフォーマンス考えると必要だわ。（笑

例えば1000回前の情報を知りたい際に、

必要じゃなかった。Subversionとかとは違うのだから。以降の日付を消すだけなのだから、どっちにしろ全部をループする。
どっちかっていうと、パフォーマンス的にはアイテム数のほうが影響するな・・・。