Linus曰く「Subversionは史上最も無意味なプロジェクト」 113
ストーリー by mhatta
Monotoneもいいっすよ 部門より
Monotoneもいいっすよ 部門より
初心者なのでAC 曰く、
以前本家/.の記事になっていました。Mona OS開発者ひげぽん氏のブログ記事で今さらながら知ったのですが、かのリーナス・トーヴァルズが、「Subversionは史上最も無意味なプロジェクト」とこきおろしていたそうです。
元ネタはリーナス氏が半年ほど前にGoogleで行ったgitに関する講演(YouTubeビデオ)で、satologのブログ記事によればと述べていたとのこと。「CVS が好きな人は精神病院に行ったほうがいい」「tarボールとパッチのほうがはるかに優れたソースコード管理方法だ」などと怪気炎を上げていたそうです。ようするに、gitのような分散型でマージのサポートがきちんとしたSCMでなければLinuxカーネルのような大規模ソフトウェア開発では使い物にならない、という趣旨に見えます。タレコミ子はそもそもCVSを使い始めたのがつい最近のことなのですが、やはりgitか、他のSCMの使い方を勉強したほうがよいのでしょうか……。ぼくの CVS への憎悪が意味するのは、ぼくが Subversion のことを史上最大の無意味なプロジェクトだと見ているということだ。Subversion がしばらくの間スローガンにしていたのに、「ちゃんとした CVS」みたいなのがあったよね。そんなスローガンでスタートしたら、もうどこにも行くところがない。CVS をちゃんとすることなんて不可能だからだ。
意外とCVSが生き残ってる (スコア:5, 参考になる)
Mozilla: CVS
GNOME: Subversion
KDE: Subversion
Eclipse: CVS(Subversionからもアクセスできるらしい)
Apache: Subversion
X.Org: CVS
OpenOffice.org: CVS
意外とCVSが多いようです。もうみんなSubversionに移行したと思ってましたが。
分散型が流行らないのは移行の難しさもあると思いますが、マージする機会が少ないからかなぁ。
Re:意外とCVSが生き残ってる (スコア:4, 参考になる)
Mercurialに移行中です。
>X.Org: CVS
CVSのツリーはもう更新されてません。gitに移行済み。
Re:意外とCVSが生き残ってる (スコア:2, 参考になる)
君のアンテナは感度が悪すぎですよ。公式Wiki [mozilla.org]にはMoz2 uses Mercurial for version controlってちゃんと書いてありますし、もうWikipedia [wikipedia.org]にだってAfter a lengthy process, Mozilla has moved from CVS to Mercurial for Mozilla 2 development.って載ってるような情報なのに。
Re:意外とCVSが生き残ってる (スコア:2, 参考になる)
http://hg.mozilla.org/ [mozilla.org] Mozilla2 開発関連は大体こっち。
http://mxr-test.landfill.bugzilla.org/tamarin-central/ [bugzilla.org] lxr(mxr) 化も徐々に。
http://svn.mozilla.org/projects/ [mozilla.org] サイト関連や lab 開発物とか。
http://weblogs.mozillazine.org/preed/2006/11/version_control_system_sh... [mozillazine.org]
昨年末までの経過。
確かに決定ではないけども、このままいくならメインは Mercurial でしょ。
Re:意外とCVSが生き残ってる (スコア:2, 参考になる)
gcc: Subversion
samba: git + Subversion(4.0系列。gitにもミラーされている)
ですね。
Re:意外とCVSが生き残ってる (スコア:1)
Re:意外とCVSが生き残ってる (スコア:1, おもしろおかしい)
OpenSSH: CVS
OpenBGPD: CVS
OpenNTPD: CVS
OpenCVS: CVS
個人的にはTortoiseGITが欲しい (スコア:3, 興味深い)
こき下ろしてるんだと思うけど、総合的に評価するなら周辺ツール込みで見る
必要があるんじゃないかな。
例えば、Windowsでは何よりTortoiseSVNって出来のいいGUIクライアントが
あるのが非常に大きい。非プログラマのメンバーにも使わせられるのがすごく
ポイント高いんだ。
xxは根本的な問題を解決してたって自画自賛する人がいるけど、そういう周辺の
部分が見えないから限られた人にしか良さが理解されなくて損してるってパターン
じゃないかなぁ、今回も。
Re:個人的にはTortoiseGITが欲しい (スコア:4, 興味深い)
営業や生産、開発全ての箇所でバージョン管理は当然要るわけで、その要求を満たそうとすると現状Subversion以外に無いんですよ。
ここらで重要になってくる要求は、情報の量、質が優れていること。クライアントが使いやすいこと。
バイナリ管理が可能なこと。フリーであること。有料でサポートを受けれること。等です。
正直アルゴリズムなどはどうでも良いのです。お手軽簡単に使え、万一の時はお金で解決できれば。
プログラマの皆さんからするとけしからん意見かも知れないんですけどね。
# しっかしTortoiseIDIFFはもうちょっとマシにならんもんか…
Re:個人的にはTortoiseGITが欲しい (スコア:2, 参考になる)
Yuzam
Re:個人的にはTortoiseGITが欲しい (スコア:2, 参考になる)
http://tortoisehg.sourceforge.net/ [sourceforge.net]
出たばかりのようですし,さわったわけではありませんので,詳細はわかりません.
Re:個人的にはTortoiseGITが欲しい (スコア:1)
Re:個人的にはTortoiseGITが欲しい (スコア:1)
バージョン管理って、まじめにやると結構複雑ですからねぇ。
私はTortoiseSVNを愛用していますが、正直、初めて使う人にはわからないことだらけでしょう。
わからない人は、最初は、update/add/commitぐらいしか使わなければいいと思います。
ほかは周りのよく知っている人が助けてくれるでしょうし、最初はバックアップがあるぐらいの感覚の方がなれやすいと思います。
TortoiseSVNの一番の欠点は、時に不安定だったり、TortoiseCacheがフォルダをロックしやがったりすることでしょうね。
エクスプローラが不安定になるのは正直、かなり迷惑なときがある。
教育現場で利用してます (スコア:3, 参考になる)
TortoiseSVNとsvnでWin<->Linux間のデータ同期を学生にやらせてます。
私が受け持ってる学生達の場合、やったらやりっぱなし(復習なんて考えないし、前回なにやったかもあまり考えてない)というのがかなりいるため、作業は作業コピー内で行わせるようにし、こまめにコミットさせてます。時々 でログを見ることで簡単な復習になります。
コミットする際にコミットメッセージを書かせ、なにをしたか一言でもいいから自分の言葉でわかるようにねと言いきかせているものの、何のためにやってるのかがはっきりつかめてないために苦労してる子が見受けられます。
それでも後々業務で日報などを作成することを考えたら記録をつける習慣を持たせることが重要だと考えてます。
ここでsvnを選んだのは、それなりのUIがあること(Win側)で多少は敷居を下げていることと、コマンドベースでの操作練習(UNIX側)になるからです。
# 実際「これから作業するからここでaddしてcommitしとくんだよ」が多少は通じるようになってる
できれば早いうち(入学当初)から「記録をとっていくこと」をもっとしっかりやらせてあげたい気がするのは私だけでしょうか。
ちょっと試した範囲では、NautilusのSubversionスクリプト [scurtescu.com]も必要最低限使えるので、こういうものをもう少しcontribで各自増やしていけば、少しでも導入の敷居を下げられるんじゃないかな...
gitはカーネル開発以外には役に立たない (スコア:2, 参考になる)
mercurial (スコア:2, 興味深い)
Re:mercurial (スコア:1, すばらしい洞察)
Re:mercurial (スコア:1)
不満はないんですが、一度Windows環境でファイル名の大文字小文字が勝手に切り替わることがありました。
これはhgのせいじゃなくて別ツールのせいなんですが、気づかずそのままcommitしたら、以後updateもrevertも出来なくなってリポジトリ作り直しました。
NTFS上で動かしてるときはその辺吸収してほしいなあ。
自分が使わないだけだろ (スコア:2, 興味深い)
個人的にはcvsみたいに集約環境じゃないとやってらんないし、
cvs使うくらいならsvn使ってるけど
俺パッチみたいなのを長~く持ってるとか、ある時点でのtrunkからの差分としては
色々あるんだけど全部のブランチは切ってらんないぞとか、模索的で散漫なのは
cvs/svnには驚く程噛み合わない
なんで、linuxのコードの特徴にはcvs/svnは合わなかったので使ってないってだけだろ
いちいち、自分と違うことをやってる奴は莫迦発言なんてほんとにしたのかな?
用途に合わせればいいじゃない (スコア:1)
選択肢は少ないよりは多いほうがいい。
旅に出ます.(バグを)探さないで下さい.
Re:用途に合わせればいいじゃない (スコア:1, すばらしい洞察)
用途に合わせて使い分けられるなんてすごいですね。
それぞれ使い方が全然違うから、覚えるのが面倒臭すぎて僕には無理。 それに並列して使ってると操作を間違えて壊しそうだし。
Re:用途に合わせればいいじゃない (スコア:1)
開発環境が Windows で、参加メンバーが全員 WinCVS なら利用経験があって、新たに教育コストを掛けたくない場合、とかはあり得ますね。
機能面だけじゃなく、使う人の問題もありますから。
Windows でも TortoiseSVN でいいじゃんとは思うけど、あれはエクスプローラに乗ってくれるせいでエクスプローラの安定度を落とす原因になったりもするので、必ずしもこちらの方がいいとは限らない。
# repo を IPv6 も持ってるサーバに置いたら全力でアクセス失敗してくれて……なんてのもあったか。
一方企業では (スコア:1, 興味深い)
1社にOS/言語/開発環境/バージョン管理を全て委ねるのは、非常に問題あるとも思われるが、責任は会社持ちという従業員的立場からすれば楽チンきわまりない。
オープンソース界隈の「ソフト毎に操作が違う」なんて面倒な事が無くて。
Re:一方企業では (スコア:3, 参考になる)
だけだら、管理した気分になって、管理してますというポーズだけ作れて、
自分達の書いたコードの品質維持に責任持たなくていいなら、すごくお勧め。
実際なにも管理してないから、品質維持コストゼロ(維持される品質もゼロ)だし。
wild wild computing
Re:一方企業では (スコア:2, 参考になる)
SVNはむしろ「そういう運用でも全然平気だぜ」が最近は売りのひとつらしい。
かくいう私の職場も、(リポジトリURLの) svn:が旨く動いてくれなかったので file:で運用を開始したが、数年間ぜんぜん問題なく稼動している。
(少なくともWindowsの)共有フォルダにリポジトリを持ちたければ、
file://共有ホスト名/共有フォルダ名/以下お好きに/…
って感じね。
(スラッシュの数は正にこの通りだから間違えないように。
特にfile:の直後はスラッシュ2つだ。
これがローカルフォルダだと file:///c:/xxx/yyy というようにスラッシュ3つになる。
個人的にはリモートのほうが数が少ないのは直感に反するんだが…まあそれはそれ。)
(すさまじくオフトピだが、MSYSのbashで共有フォルダにcdする(できるんだなこれが。cmd.exeではできないのに)ときは、同じく //ホスト/共有フォルダ/xxx…)
今(?)のリポジトリの内部形式であるfsfs型とかいう奴は、ようするに自力でジャーナルファイルシステムもどきをやってるようなものだ。
リビジョン番号そのまんまがファイル名になってるファイルがリポジトリフォルダの中にはそれぞれ有り、そのファイルが「その回のコミットの情報」すべてを持っている。そして過去リビジョンのファイルは二度と更新されない。いちど作られたらずっとimmutableだ。こんなやりかただから滅多に壊れないぞと。
欠点としては過去バージョンを一通り舐めないと答えが出せない問い(svn logとか色々)に対する答えが帰ってくるのが遅いって点。だがそのかわり確実性は有る。
(Win9xで公開したフォルダだって平気だぜとか豪語してるようだ。もっとも9xではOSそのものの確実性のほうがよっぽど不安で全くお勧めできないが。)
SVNは以前「Apache入れないと運用できないんだぜ」とかいうデマのせいで普及が遅れた時機もあったが、今ではこのfile:ベースで紹介してるWebサイトも結構あり、むしろCVSより導入がずっと楽なんじゃないか?と思ってもらえる(実際そうだし)機会が多くなってる。
なお、こんなやり方なので、サーバ「プログラム/プロセス」が不要だってのは味噌だ。共有フォルダさえ開けてあればそれで運用できるわけ。何かをインストールする必要は無いんだ。
しかもトータスSVNとかでは、それ自体の機能で(adminコマンドとか使わず)リポジトリのクリエイトをやらせてくれる。
こうなってくると導入はすごく楽だ。以前あった書籍の謳い文句じゃないが、普通の人が普通使いできるバックアップツール(?)と呼ぶに値するモノにかなり近づいていると思う。(あとひといき)
たしかにLinusが求める機能/性能は無いのかも知れない。他にも色々な要望を満たせてないかも知れない。が、その範囲内では、SVNは結構健闘してると思う。機能も性能も。そして「使いやすさ」も。
少なくとも「Better CVS」という任はそれなりに果たしていると思う。
あと、ここで読み書きしてるかたがたには釈迦説法だろうが、CVSの概念を綺麗に焼きなおした功績は大きい。混乱しきったCVSの内部モデルを、徹底的にリファイン(リファクタリング??)し、「すべてはコピー」という美しいモデルにまとめたことは、賞賛に値するし、そのぶん今後の拡張性(つまり皆さんが指摘してる機能不足の解消)の可能性も高いと思われる。
ClearCase (スコア:3, 興味深い)
ClearCaseはITILでいう「ソフトウェア構成管理」を実装し、「変更管理」製品であるRational ClearQuestと連携できます。
1.OSの認証情報を使うので、PAM/Unix、ActiveDirectory/Windows環境で、認証に煩わされることなく、大規模展開可能(小規模だとActiveDirectory環境の構築が手間)。
2.プロセスを複数サーバに分散可能(水平拡張の設計思想)。
3.地理的に離れている場合は、MultiSiteというエディションで、レプリカ機能を提供。
4.APIとコマンドラインが充実しているのでシェル化が楽。
5.トリガという機能でコマンド前後にスクリプトを仕込める。
6.Eclipse Plug-inが存在するので、EclipseベースのIDEと連携可能。
7.Antタスクにも要素が用意されているので、サーバビルドをするなら、ビルド/リリースの自動化も可能。同一セグメント上にあって、シェルを書けば、だけど。
一個も出てないのがかわいそうなので、メリットを紹介しました(裏返すとデメリットでもある)。
IBM系の開発プロジェクトだと、結構使われているんではなかろうか。
Re:ClearCase (スコア:2, 興味深い)
機能的にもSubversionと対して変わらない(EclipseプラグインはSubversionより劣る)。
自分のところではSubversionとCVSがほとんどです。Eclipseとの相性がいいので。
CCがいいと思ったのはClearQuestとの連携くらいですね。
ボロクソ言ってるけど金の問題さえ何とかすれば使ってもいいと思うんだけどなぁ。
本当に融通が利かなくて困る。
# さすがにAC
Re:一方企業では (スコア:3, おもしろおかしい)
・VSSはMSDNのライセンスで使えるので追加投資がない(Windowsでそれなりの規模の開発やってれば、MSDNに入っていると思います)
・クライアントはGUI、管理もGUI、初めての人でもクライアントインストールしてもらうだけで簡単に使える、しかもインストールも当然GUI
・いちおうCUI操作にも対応しているのでバッチファイルとかに組み込める
・天下のMicrosft社製。何か困ったことがあっても、これもMSDNのライセンス内のサポートで全部解決してくれる。
・致命的な何かが起きてもMicrosoftが悪いといえば「仕方がない」となる。これがOSSだったりしたら、「選定した奴出て来い、何とかしろ!」となる。
先生!何か違います! (スコア:2, すばらしい洞察)
○致命的な何かが起きたら、「お前たちが何とかしろ」となる
#仕様なんて飾りです、偉い人にはそれが分からんのですよ。
Re:一方企業では (スコア:2, 興味深い)
特にチェックアウトするとロックがかかる仕様には殺意を覚えます
Microsoftの中の人はホントにこれでプロジェクト管理してるのかなぁ
Visual Studio 2005ではなんちゃらスイートとかって大規模開発用のも有ったと思うんですがあれってどうですか?
# 職場じゃ未だVS6なので関係なし
# ってか自分は6.0で止まってるんで最近のを教えて貰いたかったり
脳味噌腐乱中…
Re:一方企業では (スコア:1, 興味深い)
VSSには多重チェックアウトという設定が昔からあります。
スキルの低い技術者にはマージは高度な機能として
既定ではやらなくて済む設定になっているだけです。
上級者はプロジェクトメンバーのスキルを勘案して
設定を変えるので問題ありません。
むしろ私は、CVSに排他チェックアウトがないのか散々さがして
「CVSつかえねー」って思ったクチです。
まわりのメンバーのスキル的に不安だったので。
Re:一方企業では (スコア:1, 参考になる)
複数人で使いたければ、
リポジトリ(と呼ぶのもなんだが、ようはRCSって名前のディレクトリ)を
おのおの対応するソースが有るフォルダの下に
「シンボリックリンクで」置いておけばいい(乱暴にいえば)。
そういう環境を人数分作ればいい。
そのためだけにRCSを今更使うのはお勧めしないけどね。
というかあれはそれこそシングルユーザで、
「リポジトリなんか作らずに済む気楽さ」を重んじたいときに
はじめてメリットが有る。
あとそれこそSVNは最近はロックもサポートしてるようだ。
デフォだとMIMEタイプごとにロックかマージか決められてる、んだっけかな?
設定いじればロック対象を増やせる…と思う。
関心持ったことないので未確認だが。
いずれにせよバイナリファイルの扱いはCVSよりSVNのほうが数段良いらしいので、
(そしてテキストも負けてなんかいないので)
Linusみたいな状況に置かれないかぎりSVNはお勧め。
Re:一方企業では (スコア:1, 興味深い)
CVSを知っててRCSを知らないとは、時代が変わったものだなぁ(遠い目)
Re:一方企業では (スコア:1)
というか、逆にロックがかかってくれないと困ります。
Re:一方企業では (スコア:2, 興味深い)
Visual Studio 2008 の開発プロセスの方では VSS ではなく Visual Studio Team Foundation Server に移っているようです。
参考情報は 5000個のバグと戦った、MSが「Visual Studio 2008」RTM出荷 [atmarkit.co.jp] 辺り。
なんで今・・・? (スコア:1, すばらしい洞察)
老害 (スコア:1)
昔の成功が忘れられなくて、ちょっと突飛な事を言ってまた自分への注目を得ようとする。
それでかき回される周りの人がいかに迷惑を被っているか。
使い方次第だとおもいますがねえ (スコア:2, すばらしい洞察)
自分で視野を狭くしている印象がありますね
CVSだって十分使えますよ
CVSでなきゃいけない理由はないとおもいますが
Re:CVSもSubversionも子供のおもちゃ (スコア:1)
純粋にその優先順位を聞きたいですね。評価しているところはなんなのでしょうか。
Re:CVSもSubversionも子供のおもちゃ (スコア:3, 興味深い)
着目点は、
1. 気軽にブランチが作れて実験でき、気軽になかったことにできて黒歴史も残らない
2. 黒歴史なのが判明するのは後になってからだから、ブランチ作成時にマスターに記録が残らず、
マージを決意した時に初めて残る。
3. 同じ理由で、黒歴史作成中にも黒歴史内の履歴は残る必要がある。
4. トライアングルマージが容易
で合格点だったのが前に上げた奴。
monotoneはリポジトリにトラブルがあった時に救出できないっぽくて残念。
で、quiltはそれ自体では同期機能がなくて一手間増えるから番外行き。
Archの方がトライアングルマージを助けてくれる機能があるし、どこからマージしたが覚えてくれるからDarcsより上。
BitKeeperはなんだったかなー。とにかく快適だったのだけ覚えてるか…変態的命名規則が無いからArchより上かな?
唯一お試しできた商用ツールだったのが有利だっただけかも。
あの名前ルールと~/にミラーを作ってからクローン作成というルールさえなければ、
Archがあれば他は全部ゴミみたいな勢いだった。
Re:CVSもSubversionも子供のおもちゃ (スコア:3, 興味深い)
これは結構重要ですよね。
ブランチって、実験のために作るのだけど、実際に実験してみてうまくいかなかったのにずっと残ってしまうのは精神的にもよくないです。
あとは、うちの会社では、Subversionですけど、新人君が、テストコードの中に秘密のパスワードを書いたりしてしまって、履歴から消すために、dump/filter/restoreという手間を経なければ消せなかったのはきつかったです。
Re:CVSもSubversionも子供のおもちゃ (スコア:2, すばらしい洞察)
まるっきり逆では?
実験してみて、それが駄目だったことが、はっきり記録に残った方が遥かにいいでしょう。
もし記録から完全消去してしまったら、また誰か別の人が同じ実験で時間を浪費することになるかもしれないし。
逆に、無駄だと思ったことが、諸条件が変わるとあとで有効に変わることがありますよ。
Re:CVSもSubversionも子供のおもちゃ (スコア:4, 興味深い)
今あるレポジトリをもとに、まだコンセンサスがとれていないアイデアを試してみたいと思ったことはありませんか?
そしてそのアイデアを試すためには一度のコミットで済まないほど大きな変更が必要な場合はどうしますか?
その都度ブランチしたり、ローカルにバージョン管理システムを用意しているなら
分散レポジトリに対応したバージョン管理システムを検討してみてはいかがでしょう。
上記のような問題はおよそ解決されると思います。
慣れない場合も運用次第で単一レポジトリの場合と同じように扱えますし。
#元ACの考えとは多少違うとは思いますが。
Re:CVSもSubversionも子供のおもちゃ (スコア:3, 興味深い)
(ここまで見た範囲で)誰も
SVKに言及してないのは何故だ?
それこそ「使えない」からなのか?
(いや、私も使ったことが無いのでOKかNGかは判らないんだが)
一応説明をしておくとSVNを階層バージョン管理ツール化しちゃう一種のプロキシリポジトリを作れるツール。
ところでひげぽん氏は
「どこからどこまでがマージされたのか?というメタ情報がSubversionにはないのですよね」
といってるが、
それこそSVNの「プロパティ」で管理すればいいんじゃないかな?
マージ情報を入れとくプロパティを決めて、それに書くっていう。
もっともクライアントがそういう処理をやってくれないと
ならない(というか旨みが無い)が。
Re:CVSもSubversionも子供のおもちゃ (スコア:3, 参考になる)
http://subversion.tigris.org/roadmap.html [tigris.org] によると
>1.5
>Merge tracking: tracking of merge history (see info)
となってるんでもう少し待てば Subversion 本体で使えるようになるんじゃないかと思います。
Re:CVSもSubversionも子供のおもちゃ (スコア:4, すばらしい洞察)
プロジェクトの管理方法の責任をソースコード管理システムにしわ寄せしても
それは破綻するだけだと思うし、実際、そうなったという話に見える。
道具って使い方がまずいと混乱を招くだけ。適材適所を常に考えて使わないと
駄目だと思うよ。
Re:CVSもSubversionも子供のおもちゃ (スコア:4, すばらしい洞察)
Re:CVSもSubversionも子供のおもちゃ (スコア:4, 興味深い)
>サブシステムA,B,Cの相互作用により発生する問題を解決するサブプロジェクト
まず、それがサブシステムA,B,Cの設計ミスで、手戻りになることを認識する必要がある(ミスがあること自体は仕方がない)。その上でそこが解決するまで関連部分の開発を凍結すべき。そこは進めても手戻りになる確率が非常に高い。同様にマージが大量発生している部分は手戻りになる確率が高い。賽の河原の積木崩しは士気を削ぐ。わざわざメンバを死地に赴かせる事もなかろ?
コードや人やグループの「情報の局所性」を考えたらソース管理は教条的にはロック式が基本。でもそれじゃ例外的事態に対応できないのでマージがあると考えるのが安全だよ。それともバザール式で開発する?だとするなら同じ場所にいることは大してアドバンテージにならないけどね。
Re:CVSもSubversionも子供のおもちゃ (スコア:1)
できないのかな?
例えばfeature freezeってフェイズがあるとして、
API定義(Cならヘッダ、javaならinterface?)は変更禁止とか
定義と実装が混じってるコードだと難しいけど、インテリジェントになれば可能な気がする
Re:CVSもSubversionも子供のおもちゃ (スコア:1, おもしろおかしい)
ウウッ!