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 ウィンドウの並びとして出力されます。