偽偽夜食日記: Subversion

2004年09月07日(火)

cvs2svn

cvs2svnでMacFaceのリポジトリをSubversionに移行してみるテスト。移行するCVSリポジトリと移行後のSVNリポジトリを指定するだけなので簡単、と思ったら移行中にエラーが発生して中断してしまった。この時、cvs2svnはカレントディレクトリに作業ファイルを作りまくるということを思い知った。処理が完了すればこれらの作業ファイルは削除されるのだが、念のため新しくディレクトリを作ってそこで実行した方が良いかもしれない。それはともかく、コメントなどに日本語を使用している場合は-encodingオプションを指定する必要があるようだ。ということで-encoding=UTF-8を追加。今度はうまく行った。

さっそくSubversionでチェックアウト。やはりというかなんというか、すんなりとはやらしてもらえず、svn: Can't recode stringという謎のエラーが出て中断してしまうのだった。googleで検索するといくつか引っ掛かるが解決法は無し。recodeはdecodeのスペルミスらしい。するとやっぱり文字コード関係? ということで環境変数LANGにja_JP.UTF-8を設定したら無事チェックアウトできるようになった。よかったよかった。

どうでもいいけどcvs2svnは何をどう判断してrryuというブランチを作ったのだろうか。って書いていて分かった。ベンダーブランチかあ。

2004年09月26日(日)

cvs2svnとcvswrappers

以前にcvs2svnを使ってCVSからSubversionに移行したMacFaceのリポジトリ。このリポジトリからチェックアウトしたソースをビルドしたものは、なぜか起動直後に異常終了してしまう。どうもnibファイルのファイル形式が変な為、読み込みに失敗して、そのまま終了という事になっているようだ。なんでnibファイルが壊れているのだろうと首をひねっていたが、原因が分かった。

Developer ToolsにはCVSリポジトリに設定すべきcvswrappersファイルが付属している。この中にはパッケージに対する設定が記述されている。パッケージの実体はディレクトリなので、CVSで扱うにはちょっと具合が悪い。そこでtarとgzipで固めて、リポジトリ内ではパッケージをひとつのファイルとして扱うように、cvswrappersで設定されている。つまり、Subversionのリポジトリからチェックアウトしたnibファイルらしきあれは、実体はgzipファイルだったのだ。がーん。

まあ、自分でgzipなnibファイルを展開してコミットしなおせばいいといえばいいのだが、過去のリビジョンが全部罠入りというのはちょっといただけない。cvs2svnのVer.1.1.0(このバージョンはまだFinkではインストールできない)に、RCS経由だと残念な思いをする人の為の --use-cvs というオプションがあるのだが、それを付けても状況は変わらなかった。

なんかもう履歴はいらないから、普通にリビジョン1から始めようかなあ。

2004年09月28日(火)

Subversionクライアント開発日記(1)

MacOS X用のSubversionクライアントはあるにはあるが、どれもびみょーな感じがする。コマンドを叩かなくて済むのはありがたいが、なんかそれだけという感じ。もうちょっとこう、リビジョンツリーとか、状況把握できるような機能が欲しい。無いなら自分で作ってみようということで、頑張ってみるテスト。

Subversionのドキュメントによると、下位レイヤーはライブラリ化されていて、他のソフトウェアからも利用可能になっているらしい。ｓｖｎコマンドはSubversionの公式クライアントだと書いてあるくらいなので、きっとそれらのライブラリをあれしたりするだけで、別途定めるクライアントが作れたりする勢いなのだろう。

で、それらのライブラリを利用するにあたってのドキュメントはどこにあるのだろう。

2004年10月03日(日)

Subversionクライアント開発日記(2)

Subversionライブラリのリファレンスマニュアルは、ソースコードからDoxygenで生成したドキュメントを見れ、ということのようだ。Subversionのソースを入手して、Doxygenをインストールして、ドキュメントを生成するのは面倒だなあと思って探したら、ネットで公開されているものを見つけた。

http://svn.collab.net/svn-doxygen/index.html

……ちょっとこれだけではキビシイような。Getting Standardとかチュートリアルっぽいドキュメントが欲しい感じ。

2004年10月04日(月)

Subversionクライアント開発日記(3)

ドキュメントはきっとSubversionのソースにあるに違いないと思って、http://subversion.tigris.org/からソースコードをゲット。それなりな数のドキュメントが含まれていたが、Subversion本体の開発はどうでも良くて、とにかくライブラリを使って何かしたいという人の為のドキュメントというのは無いっぽい。すくなくともさくっと見つけられるようなところに無かった。むむう。ということはsvnコマンドのソースがライブラリ利用ドキュメントとか?

なんか、大抵のMacOS X用のクライアントが、svnコマンドのラッパーとして実装されている気持ちが分かったような気がした。ソースコードの海を彷徨うくらいなら、コマンドの出力を解析する処理を書いた方が楽そう。

2006年05月06日(土)

Subversionでリポジトリをかさ上げする方法

偽偽不比等日記のシステムはいちおうSubversionでバージョン管理している。改善計画実施にあたって当然スタイルシートとかもいじることになるわけで、色々やった揚げ句、なんかもういっそサイトごとリポジトリに入れてしまえということになった。現在はサイトの/nisenise-fuhitoがリポジトリの/trunkになっているので、これをかさ上げして/rtunk/nisenise-fuhitoに持って行かなければならない。考えられる方法は以下の3つ。さてどの方法が適切だろうか。

/trunkを/trunk/nisenise-fuhitoにリネームする
/trunk/nisenise-fuhitoを追加し、/trunk/*(ただしnisenise-fuhito 以外)を/trunk/nisenise-fuhitoに移動する
/trunk/を/nisenise-fuhitoにリネームする。その後/trunk/を追加し、/nisenise-fuhitoを/trunk/nisenise-fuhitoに移動する。
リポジトリをダンプして、新しく作ったリポジトリの/nisenise-fuhitoにロードする

まず1番目はそもそも実行不能である。ファイルシステムの操作的には出来ないがSubversionならあるいはと思ったが、やはり出来なかった

2番目はnisenise-fuhito以外というのが面倒くさそうだが、実は簡単にできた。svn listにはaddしただけのものは出てこないので、xargsを使えば簡単にできるのである。

svn list | xargs -I % svn move % nisenise-fuhito/

3番目が一番簡単そうだと思ったのだが、MTの大量のファイルを二度もdel/addするのもアレで、2番目が簡単にできるならそっちの方が良いような気がする。

4番目は以前同じURLを持つ違うリポジトリ(リポジトリのUUIDが違う)にスイッチできなくて難儀した記憶があるので、できればやりたくない感じ。

Subversionの達人的にはどの方法が定番なのだろうか。

2006年07月17日(月)

Subversionブロック図

やっぱりMacOS X用のSubversionのGUIクライアントアプリケーションが欲しいということで、もう少し頑張ってみようと思う。ついでにその経緯をPagesを使って紙面にまとめる事で、せっかく買ったPagesを活用してみようという計画。ちなみに今までクライアントアプリケーションを作ろうと奮闘した結果は以下の通り。

Subversionの機能はライブラリ化されている
標準のCLIクライアントもそのライブラリを使用して作られたひとつの実装例
ライブラリのドキュメントはソースコードからdoxygenで生成されたリファレンスマニュアルだけ
クライアントアプリケーションの開発をサポートしてくれるようなドキュメントは無い

この結果からすると、要するに標準のCLIクライアントのソースコードを見て参考にしろという事なのだと思う。で、詳細はdoxygenで生成されたリファレンスマニュアルか、ソースコードを見ろということなのだろう。とはいえ、クライアントアプリケーションを作るにあたって、どのライブラリを理解していかなければならないのかということが分からないと、いささかやりづらい。ということで、まずは各ライブラリがどのレイヤーに位置して何と関連しているかという、ありがちなブロック図をひねり出してみた。

[Subversionブロック図]

この図の元ネタはいくつかあるが、どれも微妙だったので理解の為に自分で描き直した。こうしてみると、Subversionは3層+1で構成されている事が分かる。クライアントは異本的にlibsvn_clientだけを相手にしていれば、基本的にはそれより下の層については何も考えなくて良い。事実、標準のCLIクライアントは、ほぼlibsvn_clientのラッパーという感じになっているようだ。が、逆に言えば、標準のCLIクライアントが持っている機能以上のものを実装しようとする場合は、libsvn_wcとlibsvn_raのお世話になるしかないということにもなる。

クライアントアプリを作るならとりあえずlibsvn_clientを理解すべしということが分かったのは心強いが、謎はまだまだある。たとえばコミットするにはどのファイルをコミットするのかというのを指定しなければならないが、その指定方法はlibsvn_clientのソースコードを見ただけでは分からない。また、リポジトリの操作には認証が必要になる場合が多いが、どうやって認証情報を渡しているのかは、Subversionでもかなりの謎の部類に入りそうだ。

ちなみに図では最下層となるリポジトリインターフェースの下には、本当はファイルシステムインターフェースが存在する。libsvn_fsがそれにあたる。この両者の違いはリポジトリを操作した際の各種フック処理が起動されるか否かである。ファイルシステムインターフェースを直接使用することはほぼ無いと思われるので、図ではあえて省略している。

2006年08月06日(日)

svnコマンドmain()関数

クライアントアプリを作る為にSubversionのCLIクライアントを解析してみよう第1回。まずはmain()関数を調べて、クライアントアプリ実行に先だって必要な処理やコンテキストの生成について調べてみたい。コンテキスト的なものがあるはずという予想は、認証に関しての処理がサブコマンドの処理内に存在しない事による。認証が必要かどうかはサーバ等にアクセスしてみない限り分からないが、libsvn_clientが独自に処理してしまうと、任意の認証インターフェースを実装する事が困難になる。それができるとドキュメントで明言されている以上、認証処理用のコールバックの情報を保持したコンテキスト状のものをlibsvn_clientに渡しているはずに違いないという予測が立てられる。

main()関数内の処理の大半はコマンドライン引数に関する処理で分かりづらいが、やっている事を大ざっぱにまとめるとこんな感じになるようだ。

トップレベルのAPRメモリプール生成
svnライブラリ系の初期化
コマンドライン引数の解析および関連処理
svn client_content生成
svn client_contentのauth_baton設定
サブコマンド処理呼び出し
APRメモリプール破棄

これだけ見ると簡単な感じがするのだが、ここから先が大変なのだ。なにしろAPRもSubversionも基本的にはAPIリファレンスしかない。client_contentに何が保持できるか、auth_batonに何を設定しなければならないのかは個々のAPIの説明を見ても分からない。前途多難な予感。

偽偽夜食日記

Subversionに関する日記