svnadmin dump した結果を覗く
※ 手元の zsh を 4.1.1 から 4.2.5 にしたら突然便利になった。今まで ssh の hostname も補完してくれないし、なんか不便だなーくらいに思いながら使っていたのだけれど、これはなんかすごいかもしんない。そして 4.3.2 の環境の zsh は compinit してなかったよ！ バカですか、おれ。補完が強力になるとなんかこう、羽が生えたかのように軽やかな気持ちになりますな。
えー。
先日の svndumpfilter の続き。要するにリポジトリの中から要らないリビジョンを消しちゃえばいいんだろと思ったんだけど、無関係な node だけを削除するのではダメことが分かった。
それは cvs2svn がブランチを切る際に、丸ごと trunk を branches 以下にガバっと copy したあとに不要な node を削除しまくるという作業を一つの revision でやっているため、Node-path だけ見てても必要かどうかを判断できない。Node-path だけ見て拾ったものがいきなり delete アクションに割り当てられててなんじゃこれと思ったら直前に copy されているというわけ。ということはこの copy のアクションが残ってないと dump ファイルを load したときにエラーが出ちゃう。
本当に無関係なら copy も含めて revision まるごと削除すればいいんだけど、その本当に無関係かどうかを機械的に判断するのは結構難しい。例えば必要なパスの中のさらに一部のファイルにだけブランチタグを打っていた場合、cvs2svn では丸ごと copy したあと、その必要なファイル以外を次々 delete していくという履歴を起こしてくれるんだけど、この履歴を見ただけじゃ残るファイルがなんなのか分からない。それこそ svn と同じことをして前から順番にたどってこないとこの時点でそのファイルが必要かどうか分からないのだ。うーん。なんだこれ。履歴を辿りながらすべての Node-path を記録していって、この時点の丸ごと copy ではこれだけのファイルが対象になるってことを確認しないといけない。
って、それまんま svn の仕事やんけ。
Subversion に移行したとき、要るファイルだけを別 branch に copy するのがものすごくやりにくいと思った記憶はあるんだけど、まさかそれがこんな形で効いてくるとは。丸ごとコピーして削除ってそりゃないよ！
copy のアクションがあったらその revision はとりあえず残す方針にして、そのあとの delete アクションで確実に自分の意図したパスが除外されていると分かる場合だけその revision を削除できる…。もっと簡単なパターンマッチで処理できるかと思っていた。甘かった。
※ 最終的には手作業での dump ファイル修正を含めて目的の形にリポジトリを分割することができました。
cf.