Arch 作者 Tom Lord のインタビュー 42
ストーリー by Oliver
まずは使ってみよう 部門より
まずは使ってみよう 部門より
tamo 曰く、 "OSDir の Steve Mallett がリビジョン管理システム Arch の作者 Tom Lord にインタビューした記事を日本語訳しました。 Tom Lord がいつも通り CVS や Subversion を痛烈に批判しています。Arch は使いにくいと言われることが多いですが、根底に流れる思想を理解することで、好きになれるかもしれません。OSDir の責任者 Steve Mallett に翻訳および公開の許可を得てあります。"
arch使ってます (スコア:3, 参考になる)
慣れてしまえばそれほど気にならないのですが、一番の障害は珍妙ともおもえてしまうレポジトリ名等々です。このおかげでWindowsでの動作が難しいです。
* archive/category--branch--version--patch という長いアーカイブ名
* CVSというディレクトリならともかく、{arch}なんてディレクトリなんで、OSによっては"{}"が使えず動作できない
前者は実際の取得の際にはarchive/category--branch(--version)で済むため、たいしたことはないですが、後者はけっこうイタいです(だからってARCHなんて使ったらいかにも本来のソースにかぶりそうだ)。
このあたりをさっぴいても、使ってる身としては便利な道具です。
-- やさいはけんこうにいちば〜ん！
Re:arch使ってます (スコア:0)
あのー、そもそもmakeするときに
src下に"=build"ディレクトリを掘って"../configure"しろとか言われるのがうへって感じなんですが。
"="って何故。エスケープ欲しいし。
あとCygwin対応はどうなのでしょうか。
ググったらMLに何か投げられてたけど…？
SubversionはCygwinのバイナリが出てるので是非archも。
＃Windowsネイティブでもいいけど。
Re:arch使ってます (スコア:1)
$ ../src/configure
すりゃいいんで、エスケープがめんどいと思った時は
$ mkdir build; cd build
$ ../src/configure [options]
ですませちゃってます。ごめんよTom.
# 全然偉くないけどID
-- やさいはけんこうにいちば〜ん！
Re:arch使ってます (スコア:0)
TortoiseTLAキボンヌ。
Arch? (スコア:1)
誰か使っている人。
これ読んで使ってみようかと思った (スコア:1)
使う、なんてことがけっこうある。
もちろんそういうときの修正というのは自分のところの環境に
特化するためのもので、上流に持ってはいけない類いのものだ。
まぁ現状では、変更点も全部あわせて数百行以下、って程度の
修正なので CVS も使わずに diff & patch だけで管理してる。
でも、こういった修正の規模がどんどん大きくなったら
どうしよう、とは思ってる。
実際に使ってみたわけじゃないので、文面の上からの推測なんだけど、
上記のような用途には便利なように見えるなー。
ただ、上流がそもそも Arch でソース管理していないと
そういう使い方はできないんだとすると…つらいなぁ…
＃ Debian だと tla ってパッケージ名なのね
# mishimaは本田透先生を熱烈に応援しています
Re:これ読んで使ってみようかと思った (スコア:2, 興味深い)
GNU archは昔はlarch [srparish.net]という名前の
shell scriptのセットで後にC版のtlaに変わったとかいう歴史が。
＃それにしてもarchっていう名前は検索の時に不便だ。tlaもだが。
Re:これ読んで使ってみようかと思った (スコア:0)
ViewARCH-ja.txt [bluegate.org]:
あとarch win32 todo [gnuarch.org]とか
Re:これ読んで使ってみようかと思った (スコア:0)
pathの長さ (スコア:0)
NAME_MAX 255 (終端nulを除く1階層の文字数)
PATH_MAX 4096 (終端nulを含むフルパスの文字数)
Windows
MAX_PATH 260 (終端nulを含むフルパスの文字数)
WindowsでもNT系で特殊なパスの形式を使えば
32767ワイド文字まで扱えるけど大抵のツールは
対応してないからイマイチ扱いづらい現実が。
Re:これ読んで使ってみようかと思った (スコア:1, 参考になる)
/etc の履歴管理にCVSを使っています。
昨日の自分と、今日の自分と、明日の自分はずいぶん考え方が変わるので(^^;
Re:これ読んで使ってみようかと思った (スコア:2, すばらしい洞察)
Re:これ読んで使ってみようかと思った (スコア:1)
/etc って（ゾーンDBも含めて）そんなに複雑な管理がいるものでもないと
思いますが。日に何回も複数の人間がいじるってんなら分かりますが、
それはその時点ですでに何かが間違っている気がします。
# それとも ISP とかそういう管理してるのかな？
Re:これ読んで使ってみようかと思った (スコア:1)
Re:これ読んで使ってみようかと思った (スコア:1)
# まだ何か勘違いしてるのかな
Re:これ読んで使ってみようかと思った (スコア:0)
してました。BIND に頭が引っ張られてました。そういう意味じゃなくて
/etc 全般を使い回したいっつーことですね。了解。
Re:これ読んで使ってみようかと思った (スコア:1)
ってのは駄目かな。
もちろんやったことはないけどさ。
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re:これ読んで使ってみようかと思った (スコア:0)
書くっつーのはどうでしょう
Re:これ読んで使ってみようかと思った (スコア:0)
やるんですか？
/etc/CVSとか、/etc/httpd/CVSとか出来ちゃって邪魔じゃない？
Re:これ読んで使ってみようかと思った (スコア:0)
Re:これ読んで使ってみようかと思った (スコア:0)
自分のサイトを CVS で管理しています
長文だと1行が長いのでちょっと管理しにくいですが、CSS の修正なんかは
だいぶ扱いやすくなります。前の方がよかった、ってこと案外ありますからね。
Re:これ読んで使ってみようかと思った (スコア:0)
Re:これ読んで使ってみようかと思った (スコア:1)
Re:これ読んで使ってみようかと思った (スコア:3, 参考になる)
まさにCVSを使えば幸せになれるケースなのです．
CVSは単にファイル間の差分(diff)を管理しているに過ぎないですから，
普段diffやpatchを使って作業している人ならCVSへはスムーズに移行できるし，
差分の管理が楽になると言う点でメリットもあると思います．
具体的な方法は，itojunさんのKernel hackerのためのcvs入門 [itojun.org]あたりを見ると良いと思います．
ソース間の差分(diff)を管理する目的だけで利用するなら
CVS(やsubversion)はかなり良い選択です．
インタビュー中にもありますが，この点はTom Lord もみとめています．
Re:これ読んで使ってみようかと思った (スコア:2, 興味深い)
# なんか PHP の実装があったような気がするので識者のツッコミを期待
Re:これ読んで使ってみようかと思った (スコア:2, 参考になる)
ViewCVSはSubversionにも対応していますね。まあViewCVSなしでもWeb経由で覗くことは可能なんですが、ちょっと不便ですな。SVNのWebインターフェースは他にもWebSVN [tigris.org]やSVN::Webがあります。
一方、GNU ArchのWebインターフェースには [cpan.org]ViewARCH [bluegate.org]やArchZoom [sixbit.org]があります。
> # なんか PHP の実装があったような気がするので識者のツッコミを期待
Choraは既に紹介されてるようなのでphpCVSView [sourceforge.net]を挙げておきます。
Re:これ読んで使ってみようかと思った (スコア:1)
Chora CVS Viewer [horde.org] のことですカー。cvs.php.net [php.net] で使われていますね。
Re:これ読んで使ってみようかと思った (スコア:1)
> まさにCVSを使えば幸せになれるケースなのです．
Tom Lord 氏のインタビューによれば、
そういうケースの扱い方がうまくないのが CVS の欠点、
ってことじゃないの？ Arch ならそれがうまくできる、と。
少なくとも、うちでは CVS を導入するメリットより
導入コストの方が上回ってたわけですし。
> ソース間の差分(diff)を管理する目的だけで利用するなら
「単一のブランチについての」ソース間の差分(diff)だけを管理するならね。
ちなみに、内部のみで開発したプログラム（＝単一のブランチしかない）では
Subversion を使って管理してる。
これはこれで便利だけど、リリース時にはちゃんとブランチ
分けて管理しよう、とまではめんどくさすぎて思わない。
あの文書読んで、やっぱり CVS / Subversion でブランチ
管理するのって誰がやってもめんどくさいものだったんだ、
と気付いたね。
# mishimaは本田透先生を熱烈に応援しています
Re:これ読んで使ってみようかと思った (スコア:0)
>そういうケースの扱い方がうまくないのが CVS の欠点、
>ってことじゃないの？ Arch ならそれがうまくできる、と
元の話はブランチじゃなくてローカルのリポジトリを作れば解決するように
読めるんだけど、そういうことじゃないの？
そもそも Arch のストーリーだってことで (スコア:2, 興味深い)
当然上流が更新されれば（場合によっては）追従しなければ
いけないようなプログラムだと思っていただきたい。
そうすると上流が更新されたら、そこに自分の加えた変更点を
マージしなきゃならんわけで。
CVS でマージ、とか言われるとちょっと怖気づいちゃうわけで。
そこで怖気づかない人だけが CVS をちゃんと使えてる人なんだろうけど、
まぁ自分はいわゆるインタビュー中で言うところの
(強調は俺)ってところの「ほとんどのユーザ」。
これは確かに勉強不足と言い替えることもできるけど、
やっぱりそれは導入コストが高いってことだし。
# mishimaは本田透先生を熱烈に応援しています
Re:そもそも Arch のストーリーだってことで (スコア:0)
>まぁ自分はいわゆるインタビュー中で言うところの
ブランチしないんならマージつっても別に何も特別なことはないと思うけどな。
arch になったからって劇的に改善されるというものではないと思う。
Re:そもそも Arch のストーリーだってことで (スコア:0)
Re:そもそも Arch のストーリーだってことで (スコア:2, 参考になる)
Re:そもそも Arch のストーリーだってことで (スコア:1)
あとは人間がなんとかする。
逆にそう割り切っちゃえばそんなもんかなとも思っちゃう。
Subversion はなんとなく使いたくないなぁと思っていたので将来的には
こっちに転ぶ方向で考え始めました。
Re:これ読んで使ってみようかと思った (スコア:0)
> 特化するためのもので、上流に持ってはいけない類いのものだ。
自分の場合はローカルにCVSリポジトリを作ってますが、上流への追随についてはitojunさんのKernel hackerのた [itojun.org]
Re:これ読んで使ってみようかと思った (スコア:1)
> 上流への追随についてはitojunさんのKernel hackerのための
> cvs入門を参考にしています。
そうそう、更新頻度やプログラム規模は違うけど、
まさにそういう例ですよ！
「そういう場合に CVS はすっげぇ分かりにくくて、
Subversion は CVS から何も進歩してないけど、
Archならシンプルで分かりやすいよ！」ってのが
Tom Lord 氏の意見であって（たぶん）、だからこそ使ってみたいわけ。
ただ、現状では間違いなく導入コストの方が高くつきそうだな…
# mishimaは本田透先生を熱烈に応援しています
Re:これ読んで使ってみようかと思った (スコア:0)
なにか忘れているような (スコア:0)
Re:なにか忘れているような (スコア:0)
# ユーザの移り変わりによって、このネタが分かるのはもう百人くらいしか居ないんじゃないかとか妄想
Re:なにか忘れているような (スコア:0)