CVSを使ってファイル管理

ファイルシステムをテープに固めて管理するのが一番信頼性が高いという
結論がでますた。

>>931
素朴な疑問なんだが、だったらなんでバイナリ登録する必要があるの？
いつでも厳密にソースから同じバイナリが再作成できるんだったら、
登録管理する意味ないじゃん。

素人考えだと、手動でバイナリを登録管理するよりも、毎回フルビルド
した方が安全な気がする。モジュール間にあんまり気づかないような
依存性があった場合、手動のバイナリ登録だと、依存性に気づかずに
バイナリの登録更新を忘れてしまうんじゃないかな。実際、昔の
RPMで、何度かこれで痛い目にあってるんだよねぇ。

> いつでも厳密にソースから同じバイナリが再作成できるんだったら、

できる保障がないからだよ。何かの要因で完全なバイナリが再現できな
くなったら、汗屋呼んでバイナリの再検証、そしてテストやり直し。バグ
フィクスならいざ知らず、再コンパイルしたら違うバイナリになった程度で
そんなリスク負えるのかって (エンドユーザアプリの話じゃないぞ)。

まぁ話の前提の分野が違うので無視してくれ。俺も C/C++ や Java で
やる開発に来てからそんなシビアなバイナリ検証なんてしてないし、
最近はずっと CVS でソースレベル管理だし。

>>929
だから、金掛けずにできないもんですかねえ。
リリース管理チームとかに掛けるコストが無いんですが。

金かけないとCVS使ってもまともな品質管理は出来ないの？

だからテープ最強だっての。

>>938 それだったら、CD-RとかZipの方が安上がりだったり...

>>935

定期的にフルビルドしてるなら、前回分のフルビルドだけは残しておいて、
あとはバイナリを比較するだけで、厳密に同じバイナリを生成できること
を、完全自動で保証できるんじゃない？ 簡単そうな気がするけど…

まともな品質管理できるかどうかは使う人にかかってると思うが。
そういう意味で CVS はただの手段だよ。工程管理/品質管理について
いろいろ調べてみるといい。特に流通・製造・建築分野のはソフト
ウェアより歴史が長いだけあっていろいろ得るものがある。逆に
ソフトウェア側の管理本とか最新ネタ/情報キーワードちりばめた
だけで統計的な論議を無視してたりする。

ま、でもそういうプロジェクト管理技術をソフトウェアに持ってくる
のは殆んど無理ぽだったりするけどね。たとえば土木建築系で聞くよ
うな、設計と施工を別の業者にやらせるなんて、現状のソフトウェア
開発では墓穴掘ってるとしか思えない。
設計業者がオオボラ吹いて大風呂敷広げて、おまけに穴だらけで実装
不可能な設計内容を残してトンズラして、実装担当が泣きながらデス
マーチでなんとかするって、良くある話だしナ。

ちゃんとした設計ができて当たり前の土木建築の世界と、設計自体が
困難で、実装段階での見直しが不可欠なソフトウェアの世界は、全然
違うよ。

>>940
実際にトラブルがあったら、そのバージョン (もっと言えばその社に
納品したバージョン) レベルでバイナリを検証しなければいけない
んだよ (もちろんソースも検証するけど)。

なんか話の流れ見てると

　　CVS はバイナリが苦手だから乗せるべきではない。

が

　　バイナリレベルのバージョン管理は不要。

ってことに飛躍してるようだが大丈夫か?

>>942
それは公的機関がソフトウェア設計を管理していないからでは。いや、
みずぽじゃないけどいい加減ﾏｼﾞで何とかならんかな。

良く分からないんだけど、925が言っているのは開発段階での
バイナリの管理であって、納品物ないし本番用のバイナリに
ついては、当然バイナリの保存管理はしてるんじゃないの？
っていうか、基幹系の開発で、そういうレベルの管理をして
ないなんて、それこそ信じられないけど。

>>944
大規模ソフトウェアの設計っての難しさって、公的機関が
成果管理すれば解決するような簡単な問題じゃないと思い
まつ。たとえばISO9001をソフトウェア開発に導入して、
文書上でISO9001とのツジツマを合わせる作業のために
余計デスマーチがひどくなってるなんてのを見聞きする
につれ、公的機関が出てきたら、むしろ悪化すること
間違いなしっていう悪寒。

そういわれりゃそうだな、失礼

>>946
うん、だからそうできるまで業界と技術が枯れて来ると良いなぁと
いう希望。その頃には飽きて別分野行ってると思うが。

なんか話が大規模開発の話ばかりですが
皆さんは大規模開発してる人ばかりなんですか？

こんな時刻に起きているのは、大規模開発のデスマーチで
徹夜中の連中ばかりのためだと思われ。

ここまでの議論見てると、もうまるっきり破綻したチームを無理やり縛るために
CVS使ってみようみたいな感じだな。

まずは信頼関係を築く方法を学ぶのがいいと思うよ。

>>951
その場限りの外人部隊ばかりなんで信頼関係を築いてるうちにカットオーバーです。

そういう時はルールの徹底と守らなかった場合のペナルティの明確化でがんばる

そのルールの議論をしてるのでは？

>>954
ｽﾚ違い基地外

CVS is not a substitute for management.
CVS is not a substitute for developer communication.

>>955
CVSを使っての管理ルールのことじゃないの？

次スレは？

CVSではコンパイル環境の依存管理は無理だからなぁ。
厳密に同じバイナリを生成できるためにはどうしたらいいのだろう？

>959
原因が分かっているんだから対策も自明だろ

>>960
原因が分からないんだが。

>>960
自明とか言いつつ、お前が一番わかってないんだろ？

>>960
バイナリも管理しろってことですか？

厳密に同じバイナリができることを保証しないといけないような条件でなければ
タグうってテストするってことでいいですか？
厳密に同じバイナリを生成する方法はコンパイラの開発元にきいてくれ

なんだかすごく盛り上がっちゃったのね。

>>912
こっそり修正っていってもCVSに登録されてたんでしょ？
されてないなら、タグ打ってcvs exportしたやつをコンパイルしないのが問題。

ここまで読んできてけど、結局バイナリを管理する理由って、
「コンパイラに再現性100%でないバグがあるかも知れないから」
ってことなのね。
まあ、その可能性を考えるなら納得です。ミッションクリティカルな世界はあるだろうし。

バイナリはソース更新を管理じゃなく、IT用にビルドしたものを管理するってことでいいですか？
それぐらいだったら、CVSに放り込んじゃってもいいの？

バージョン管理するつもりなら、バイナリだろうと放り込んじゃえよ。差分だ
のブランチのマージだの、テキストでしか使えない機能はあるにせよ、少なく
とも体系立てて管理することはできる。

単に、CVSが一番多く使われてるだろうオープンソースの場合には、バイナリ
の再現性どころか共通のバイナリってもの自体がそもそもないから、扱わない
ことがほとんどってだけじゃないか?

どうしてもバイナリも管理したいっていうなら止めないけど、
バイナリファイルについては cvs add するときに -kb オプ
ションをつけないと大はまりする ($Id$ とかがバイナリ中に
存在すると展開されてしまう) ので気をつけて。

バイナリを管理する理由はコンパイラのバグじゃなくて主にバイナリ生成環境に思わぬ
環境依存があった場合のための措置だとおもう。
ex) 全然関係ないはずのソフトのバグフィクスのせいでコンパイラ等の動作が変わった。

皆さんの運用方法教えてください。
コーディングからテスト、本番反映までの。

つーか、次スレは？

>>969
そういえばWinXP環境でビルドすると、同じVC++6.0SP5を使っても
Win2000までと生成されるバイナリが違うなんて話はあったな。
(msvcrt.dllのバージョンが違うとlink.exeの動作が変わるそうな)

>>970
次スレはCVSにこだわらないのにしたいです。
CVS以外にもいくつかある(bitkeeperとかperforceとかsubversionとか)し、
あと管理ツールそのものだけでなく運用方針もけっこう話題が出てるんで
そういうのがスレ違いにならないようなタイトルにしたいですね。

って、誰かもう作ってるし

立てたら誘導貼れよ……。

CVS(2)
http://pc.2ch.net/test/read.cgi/unix/1047262230/

>>972
あ、私もそういうのがいいです。

>>972
そういうのもアリだとは思うけど、
それだったらunix板よりはム板が適してると思われ

クライアント cygwin, サーバ Debian GNU/Linux (sid) で CVS を使ってます。
ディレクトリ全体のサイズが 130 Mbytes ほどのファイルを
クライアントから pserver (sshでトンネル), ext を使ってサーバに import しようとしましたが、
途中で No space for left on device というエラーメッセージを出して止まってしまいます。
もちろんサーバ側には 70GByteほどの残り容量があるので、
設定か何かの誤りだと思いますがご助言をお願いします。

設定ですが、サーバはインスコしたままです。
クライアントからサーバに繋げるときは
$ cvs -d :ext:[email protected]:/home/kikyosha/CVSROOT
で繋げています。

もう一つ、サーバ側に SCP で全部のファイルを置いて
サーバでサーバ自身に接続して CVS import させるとちゃんとできます。

>>977
-T とか TMPDIR とか /tmp

>>978
素早いレス、カムサハムニダ。
/tmp は全然容量が足りませんでした。
もうちょっと容量のあるファイルシステムにシンボリックリンクを張って
もう一回実行したらうまく動いています。マンセー。

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

http://life.fam.cx/