svn ファイルシステムのダンプ/リストアのフォーマットに関する提案 (Ben Collins-Sussman)

svn ファイルシステムのダンプ/リストアのフォーマットに関する提案。
解決したい二つの問題
====================
 1. node-id の形式を変更すると、すべてのデータを移行しなくてはならなく
 なってしまう(dump と restore によって)
 2. バックアップの形式を用意すること。いつかは別のソフトウェアツールに
 よって読めるようにすること。
設計の目標
==========
 A. svn_fs.h に新たに二つの関数を追加すること。新しい 'svnadmin' のサ
 ブコマンドによって起動されるように。
 B. ファイル形式は fs の時間に関係しない概念だけを使って設計されること。
 ダンプ形式は私たちが *理解している* 決して変更されることのないく
 らい十分一般的な概念だけを参照する必要がある。これらの概念は内部
 的ないかなる node-id の形式とも独立に存在する必要がある、あるいは
 バックエンドの DB 保存形式からも独立していなくてはならない。言い
 換えると2000年5月に考えた、われわれのもともとの基本的な "設計仕様
 " に基づいたものであること。
ファイル形式の意味
==================
私たちの fs の時間概念に依存しないような設計のセマンティクスは以下で
ある -- これが私たちのダンプ形式に保存されるものになるだろう。
 - ファイルシステムはツリーの並びである。
 それぞれのツリーは "リビジョン" と呼ばれ、バージョン化対象とはな
 らない属性が付随している。
 - リビジョンはそこにぶらさがっている "ノード" のツリーを持っている。
 実際にはファイルシステム中のノードは DAG を構成する。ひとつの
 リビジョンは常にある初期ノードを指している。これはあるツリーの
 'ルート' を表現したものである。
 
 - ツリーのノードの大部分はそれ以前に作られたツリーのノートに対する
 ハードリンク(参照) になる。
 - ノードは以下のものを含む 
 - バージョン化されたテキスト
 - バージョン化された属性
 - 先行するノードの履歴: "自分はどのノードから派生したものなのか?"
 - コピー履歴: "自分はどのノードのコピーなのか?"
 履歴は存在しない(これはそのノードが完全に新規に作られたことを意味
 する)か、{リビジョン, パス}の値を持つかのどちらかになる。
------------------------------------------------------------------------
Proposal #2 の詳細化: (グレッグスタインとの議論の後)
=====================
それぞれのノードは RFC822 形式のヘッダで始まる。最後のヘッダは
'Content-length:' であり、その後に内容が続くのでレコードの区切り位置を
推測することができる。
レコード内容の部分は二つに分割される: プロパティー情報のハッシュと完全
なテキストである。この二つのセクションの区切りは属性ハッシュの最後に
"PROPS-END\n" タグを置いて示す。ディレクトリのノードやリビジョンの場合
は属性ハッシュだけが存在する。
-----------------------------------------------------------------
SVN ダンプファイル、バージョン1 形式
この形式はダンプ形式のバージョン番号で始まり
("SVN-fs-dump-format-version: 1\n") リビジョンレコードの並びが続く。そ
れぞれのリビジョンレコードはリビジョンに関する情報で始まり、そのリビジョ
ンで変更のあったノードが可変個続く。[かどかっこ] でくくったフィールド
はオプションで、認識できないヘッダは常に無視される。これは下位互換性を
保つためである。
Revision-number: N
Prop-content-length: P
Content-length: L
 ...P バイトの属性データ。属性は作業コピー属性ファイルで利用されるの
 と同じ人間が読める形のハッシュダンプ形式で保存される。ただし最後は
 より見やすくするため "PROPS-END\n" で終わる。
Node-path: /absolute/path/to/node/in/filesystem
Node-kind: file | dir (1)
Node-action: change | add | delete | replace
[Node-copyfrom-rev: X]
[Node-copyfrom-path: /path ]
[Text-copy-source-md5: blob] (2)
[Text-content-md5: blob]
[Text-content-length: T]
[Prop-content-length: P]
Content-length: Y (3)
 ... Y バイトのデータ内容がくる。これは P バイトの "属性" データとT 
 バイトの "テキスト" データに分割される。属性が先にくる; その全体の
 長さ(書式を含めた)は Prop-content-length とNode-content-length にな
 る。"PROPS-END\n" 行は属性が存在する場合には常に属性セクションの最
 後にくる。Y バイトの残りは(これは Text-content-length と同じである
 だろうが)ノードの内容を表現している。
注意:
(1) ノードが削除を表現しているときにはこのフィールドはオプションとなる。
(2) これはコピー元のチェックサムになる。ローダーはこのチェックサムによっ
 てファイルシステム中にすでに存在するコピー元のパス/リビジョンが本
 当に *正しい* ものであるかどうかを判断する。
(3) Content-length ヘッダは技術的には不要である。この情報は(そしてそれ
 以上の情報が)Prop-content-length と Text-content-length のフィール
 ドにあるからである。Subversion 自身はダンプファイルを読み取るとき
 にこの情報を使うことはないが RFC822 パーサとの互換性を保つためこの
 フィールドも含める。
(4) 実際には 2 種類のバージョン 1 ダンプストリームが存在する。通常のも
 のは r2634(svn 0.14.0) から導入されたものである。フィルものもバー
 ジョン 1 であると言われるがブロックヘッダにProps-content-length と 
 Text-content-length のフィールドが存在しない。当時は *常に* 属性ブ
 ロックが存在していたのだ。
-----------------------------------------------------------------
例
リビジョン 1422 の例を以下に示す。ここで私は新しいディレクトリ "baz"
を追加し、新しいファイル "bop" をその中に追加し、さらに "foo.c" を
修正したものとする。
Revision-number: 1422
Prop-content-length: 80
Content-length: 80
K 6
author
V 7
sussman
K 3
log
V 17
Added two files, changed a third.
PROPS-END
Node-path: bar/baz
Node-kind: dir
Node-action: add
Prop-content-length: 35
Content-length: 35
K 10
svn:ignore
V 4
TAGS
PROPS-END
Node-path: bar/baz/bop
Node-kind: file
Node-action: add
Prop-content-length: 76
Text-content-length: 54
Content-length: 130
K 14
svn:executable
V 2
on
K 12
svn:keywords
V 15
LastChangedDate
PROPS-END
Here is the text of the newly added 'bop' file.
Whee.
Node-path: bar/foo.c
Node-kind: file
Node-action: change
Text-content-length: 102
Content-length: 102
Here is the fulltext of my change to an existing /bar/foo.c.
Notice that this file has no properties.
-------------------------------------
SVN ダンプファイル、バージョン2 形式
この書式は以下を除いて バージョン1 の書式とまったく同じです:
1.) フォーマットはダンプ形式の新しいバージョン番号で始まること
 ("SVN-fs-dump-format-version: 2\n").
2.) "リビジョンレコード" に加えて、別のレコードがサポートされたこと:
 つまり "UUID" レコードがそれで以下の形をしている:
UUID: 7bf7a5ef-cabf-0310-b7d4-93df341afa7e
 これは元のリポジトリの UUID 値を示すのに利用される。
-------------------------------------
SVN ダンプファイル、バージョン3 形式
この形式はバージョン 2 と以下を除いて同一です:
1.) フォーマットはダンプ形式の新しいバージョン番号で始まること
 ("SVN-fs-dump-format-version: 3\n").
2.) ノードの変化を示す二つの新しいオプションヘッダが追加されたこと:
[Text-delta: true|false]
[Prop-delta: true|false]
 この二つのヘッダのデフォルトの値は "false" です。"true" に設定
 するとテキストと属性の内容はノードの直前の内容との差分として扱われます。
 (直前のノードは追加の場合は履歴に対するコピー履歴、また修正の場合には
 直前のリビジョンの値によって決まります)。
属性の差分は以下の 2 点を除いて通常の属性リストと同じ書式です。例外は
(1) ノードの直前の内容と同じ値の属性は表示されないことと、(2) 削除された
属性は
D 

のように表示されることです。後の場合、表示内容自体は通常の属性表示と同
じですが、"K " の代わりに "D " になり、値の部分がありません。
テキスト差分は svndiff ウィンドウの並びとして出力されます。