レス数が1000を超えています。残念ながら全部は表示しません。

CVSを使ってファイル管理

1 ：名無しさん＠お腹いっぱい。 ：2001/08/10(金) 18:10

CVSを使ってファイル管理している人の質問スレ

887 ：名無しさん＠Ｅｍａｃｓ ：03/03/05 13:07

>>886
ありがとうございます。
上のようにやったらCVS/の下のファイルも更新されました。
-dオプションはCVSROOTを指定するためだけに使うものと
考えてましたが、もしかしたらCVS/の下のファイルを更新する
っていう意味もあるんでしょうか。ちょっと調べてみます。
どうもありがとうございました。

888 ：名無しさん＠お腹いっぱい。 ：03/03/05 14:54

cvs [こっち] コマンド [そっち]
こっちとそっちでは同じオプションでも意味がちがう

889 ：名無しさん＠お腹いっぱい。 ：03/03/06 00:32

>>881
そもそもこっちでコンパイルしてるときに他の奴がciしたら、次にcvs upした
ときに再コンパイルされなくなってしまう。タイムスタンプでの管理なんて無
意味。

890 ：876 ：03/03/06 00:54

>>878
「タイムスタンプが変わっちゃう」というか、タイムスタンプまで保持してくれない。
って、保持してくれても何も嬉しくないと思うが。
詳しくは
ttp://katsu.watanabe.name/cvs/p32.html
見てくれ。
漏れ的には、そもそも「タイムスタンプで管理」なんて発想自体が信じ難い。。
makeを「タイムスタンプで管理」って言うなら話は別だが。

891 ：名無しさん＠お腹いっぱい。 ：03/03/06 01:09

まあまあ。汎用機なんつーロクな道具のなかった旧石器時代の先人の
知恵なんだろうよ。現代から見れば迷信レベルなわけだが。

892 ：名無しさん＠お腹いっぱい。 ：03/03/06 05:56

>>891
そういう人とうまく関係を保ちながら発想の転換を促すのって
大変だけど大事なことだよ。

893 ：名無しさん＠お腹いっぱい。 ：03/03/06 08:52

大事かも知れんが、とっても大変。

894 ：名無しさん＠お腹いっぱい。 ：03/03/06 21:41

>>875
ＵＴ完了時にＣＶＳにソースを登録しといて、
ＵＴで使用したバイナリをＩＴ、ＳＴ、本番へと反映すればいいことじゃないの？
なんの問題も無いじゃん

そしたら、開発時のタイムスタンプたいした意味を成さなくなるんじゃないの？

ＵＴ完了時のソースをＣＶＳに登録して、
ＩＴ時にチェックアウトしてコンパイルとか馬鹿なことしないだろ、普通。

895 ：名無しさん＠お腹いっぱい。 ：03/03/06 21:51

>>894
UT, IT, STって略語なんでしょうか(「何とかテスト」)?

896 ：名無しさん＠お腹いっぱい。 ：03/03/06 21:54

Unit Test
Integration Test
System Test
かな?

897 ：894 ：03/03/06 22:20

>>896
そのとおりです。

基本的な言葉ではないのですね。

金融系の仕事ばかりしてますが
どこもUT,IT,STって使ってたもので、つい。

898 ：名無しさん＠お腹いっぱい。 ：03/03/06 23:52

>>894
>ＵＴ完了時のソースをＣＶＳに登録して、
>ＩＴ時にチェックアウトしてコンパイルとか馬鹿なことしないだろ、普通。

「普通」はね。
CVSの使い方が分からんと言って、わざわざ人と手間をかけて
人間CVSやらせてるアフォな現場もあったりするよ。
(って今の俺の現場がまさにそう)

もちろんとてもじゃないが信用できんので自分のグループ内部
ではCVS管理してるが、それだけだと最終的にリリースされた
バイナリが正しい物かどうか保証できないので(タイムスタンプ
も奴らがビルドした時間になっちゃうし)、>>881のようなマーカー
埋め込みは必須。

C/C++みたいにモジュール間の結合依存度が高い言語だったら
それでも破綻してるだろうな。(Javaはその辺楽だ)

899 ：名無しさん＠お腹いっぱい。 ：03/03/07 19:26

漏れもRCS IDからタイムスタンプをセットするツールってのは作ったことがある。
アフォくさいけど、そういうのを要求するDQN会社もあるんだよな。

900 ：890 ：03/03/07 23:41

単に漏れが想像できないだけなんだが(ずっとJavaで開発してるし、そんなに大規模じゃないので)、
> ＵＴ完了時のソースをＣＶＳに登録して、
> ＩＴ時にチェックアウトしてコンパイルとか馬鹿なことしないだろ、普通。
これってダメなの？
コンパイルする度に挙動が変わるようなバグが潜んでいる可能性があるから？
個人的にはそういうバグは潰すべきだと思うが。
それとももっと深遠な理由があるのかなぁ。大規模開発は想像ができん。。

901 ：名無しさん＠お腹いっぱい。 ：03/03/08 02:29

>>900
ＵＴでつかったバイナリを使えば
中身が同じってことが保障できる。
ＩＴ時にコンパイルしたら
ＣＶＳのＳＴＡＴＵＳで
ＵＴに使用したバイナリとＩＴで使用したバイナリが
同じソースからコンパイルされたことを
いちいち証明した上でテスト結果をまとめないといけないじゃん。
面倒だよ。


それに、カットオーバーの異なる２つのプロジェクトが
同時に同じソースいじることが時々あるけど、
そのときはどうするつもり？
ソース修正(1)→ＵＴ(1)→ＩＴ(1)
→ソース修正(2)→ＵＴ(2)→ＳＴ(1)→本番反映(1)
→ＩＴ(2)→ＳＴ(2)→本番反映(2)
みたいな流れになったときとか。

902 ：名無しさん＠お腹いっぱい。 ：03/03/08 03:41

>>901
勢いよく説明 (反論？) しているけど、
UT、IT、CVS、STATUS 全て全角で書いちゃう
センスはいかがなものかと...

903 ：名無しさん＠お腹いっぱい。 ：03/03/08 04:30

>>902
901の書き込みは全角使っていること以外は
あってるということですか？

904 ：名無しさん＠お腹いっぱい。 ：03/03/08 04:45

>>902
つまんないつっこみなんかいいから901の内容についての意見を聞かせてよ。
くだらない煽りいれるぐらいなら書き込まないでくれる？
「...」を半角でかかれると見えにくいんですが．．．（笑

個人的にはシステムテスト前に次の単体テスト終わってるってのが
気になるんですが、それってよくあることなの？

あまり無いと思いますが、
システムテストで問題発覚！とかだとどうなるんでしょう？

CVSの話からずれてるかもしれないけど、気になったものでsage．．．

905 ：902 ：03/03/08 05:39

>> 904
> 「...」を半角でかかれると見えにくいんですが．．．（笑

いや、別にそこは無理して見なくてもいいよ。

というつまらあい煽りはもうやめます。ごめんなさいね。

906 ：名無しさん＠お腹いっぱい。 ：03/03/08 06:30

>>901
> ＣＶＳのＳＴＡＴＵＳで
> ＵＴに使用したバイナリとＩＴで使用したバイナリが
> 同じソースからコンパイルされたことを
> いちいち証明した上でテスト結果をまとめないといけないじゃん。
> 面倒だよ。

じゃあ逆に、保存しているバイナリがUT完了時のものだとどうやって
証明する?

> それに、カットオーバーの異なる２つのプロジェクトが
> 同時に同じソースいじることが時々あるけど、
> そのときはどうするつもり？

それってCVSのメリットが最大限活かされる局面なんでは?

907 ：名無しさん＠お腹いっぱい。 ：03/03/08 06:47

ていうか、>>894 って要はアリバイ作りの発想なわけで、
開発全体の成功には後ろ向きだよね。

908 ：名無しさん＠お腹いっぱい。 ：03/03/08 07:58

3点リーダーは2マスだ!

909 ：名無しさん＠お腹いっぱい。 ：03/03/08 10:47

就職活動でNTTComのES書いたけど全部全角で書かないといかんかった。
全角って大事だな

910 ：名無しさん＠お腹いっぱい。 ：03/03/08 11:03

しかし、勝手な略号使うのは勘弁して欲しいものです

911 ：名無しさん＠お腹いっぱい。 ：03/03/08 13:10

略号は特定のコンテクストと共通知識を共に背景として備える場合のみ、
意図通りに理解されることを期待できるものだからね。

>>909 のESはエントリーシートのつもりなんだろうけど
就職活動と関係ないところで使っても正しく理解される保証がない。
ESをエントリーシートと解するという知識は、
いまだ就職と関係ない学生はもちろん、そんなもの書かずに就職する人間にも
期待できないから。
少し前まで秋葉原マップを見てた俺は、最初 engineering sample かと思ったよ。

ちなみに就職活動方面でESをエントリーシートと解することを一般に期待できるかどうかは知らないが。

こういう人間が就職すると、社内だけしか通用しない独自略語や用語を
外でもたれ流しちゃう香具師になるんだろうなあ。

912 ：名無しさん＠お腹いっぱい。 ：03/03/08 13:12

>>907


・単体テスト終了
・結合テスト開始
・協力会社のﾔｼが単体テスト時にケース漏れで気づかなかったバグを発見
・ｺｿｰﾘ修正してコンパイル
・修正したものでシステムテスト開始
　（協力会社のﾔｼしかそのことを知ってる人間はいなかった）
・システムテスト終了
・本番反映直前に発覚

って、ことがあって相当問題になったんですが、
ダメダメなﾔｼしか雇えないようなうちの会社では
アリバイつくりでも何でもいいので
問題の出にくいやりかたを考えないといけません。

皆さんは、開発〜テスト工程でCVSをどのように運用してるのですか？
規約とか、標準化とかあったら知りたいです。

913 ：名無しさん＠お腹いっぱい。 ：03/03/08 13:19

>>912
ﾊｧ?
ここのみんなは性善説の上に成り立ってる運用方法しか使ってないじゃねえの？
ｽﾚ読んでればなんとなくわかるじゃん。

そんなﾔｼ雇う方がﾊﾞｶ

ぐらいのﾚｽしかつかねえ〜つ〜の。

914 ：名無しさん＠お腹いっぱい。 ：03/03/08 13:20

自作自演ハケーン

915 ：名無しさん＠お腹いっぱい。 ：03/03/08 13:41

やめとけ。CVSに限らず使う奴がダメダメならなんでもダメ

916 ：912=913 ：03/03/08 13:43

>>914
ﾊﾞﾚﾀ?

917 ：名無しさん＠お腹いっぱい。 ：03/03/08 14:46

ＣＶＳッて何よ？

918 ：名無しさん＠お腹いっぱい。 ：03/03/08 14:58

>>917
computer-controlled vehicle system
(コンピューター制御自動運転輸送システム)。

unixの技術がコンビニを支えていまつ。

919 ：名無しさん＠お腹いっぱい。 ：03/03/08 15:50

>>917
新たな煽りか?

920 ：名無しさん＠お腹いっぱい。 ：03/03/08 16:38

>917
CSV の typo です

921 ：名無しさん＠お腹いっぱい。 ：03/03/08 23:38

で、>>912 に対する回答はないのかい?
なんだみんな厨か

922 ：名無しさん＠お腹いっぱい。 ：03/03/09 00:04

>>921
だから、913の書き込みに行き着くんじゃないの？

923 ：名無しさん＠お腹いっぱい。 ：03/03/09 01:16

>>912

> ・コソーリ修正してコンパイル
> ・修正したものでシステムテスト開始

これができてしまったということは、テスト対象のバイナリを、
担当者が勝手に置き換えるとことができたということで、多分、
ここがまずいのでしょう。

単体テストが終了したら、ソースにタグをつけて、バイナリ一式を
スナップショットとしてセンタに登録し、勝手に書き換えることが
できないようにし、以降のテストは、それらのバイナリをテスト対象
にすればいいと思います。

# 好みによっては、「テスト対象のバイナリは、CVS でタグがついて
# いるソースから、再生成したものを利用する」という方針でもよい
# と思います。

一般に、テスト工程で成果物の管理をきちんとするには、まずは、
CVS のタグを用いるなどして、テスト対象のソースの版、テスト
プログラム自身の版を明確にし、それをきちんと記録に残すこと
だと思います。

924 ：名無しさん＠お腹いっぱい。 ：03/03/09 01:44

>>923
結局はバイナリを管理するということですか。

>>894の話に近い考え方ということになるんですか？
ソースとバイナリを別に管理する必要があるということ？

コンパイルもコンパイルサーバで行う会社もあるみたいですが。。。
ソースを登録してその登録したソースをコンパイルして
作成されるバイナリをそのまま登録してしまうという。。。
（VisualStudioでしたが）

925 ：名無しさん＠お腹いっぱい。 ：03/03/09 03:49

いまだにバイナリを登録するなんて開発スタイルをとっているところ
があるのか。それは、はっきり言ってお勧めできない。
基幹系みたいな重要システムの場合、リリース管理専任チームがいて、
リポジトリにコミットされているリリース・ブランチの内容を、
リリース管理チームの責任下で定期的にフルビルドする。これが常識。

当然、バイナリを保存しておくようなリリース管理はしない。
そういうやり方じゃなくて、正しく動作するバイナリが、リリース
管理チームの定義した環境下で、いつでもソースから正しくビルド
できることを保証することが最も重要。
そうでないと、障害対応の段階になって、同じバイナリを作成して
再現することさえできないなどという、最低の状況が生まれる。

926 ：名無しさん＠お腹いっぱい。 ：03/03/09 04:30

>>925
「リリース管理専任チーム」がいるのが常識？
そんな奴雇ってる金なんてないんだが。
２０００〜３０００万のプロジェクトで
そんな奴ら雇ってたら赤字なんだけど。
その程度の規模の仕事は非常識か？

927 ：名無しさん＠お腹いっぱい。 ：03/03/09 04:32

軍事や生命にかかわる分野の開発ではバイナリに対してテストし管理
するのが普通だし、金融基幹系などでもやってるところはやっている。
ソースありきの管理は「コンパイラにバグは無い」「OS にバグはない」
という前提があって始めて成り立つが、本当にクリティカルな分野は
そういうわけにも行かない。

928 ：926 ：03/03/09 04:33

>>925
ｽﾏｿ。
基幹系って書いてたね。

俺は、基幹系なんかやってないんだよ。
中小企業から開発頼まれてるだけ。
バイナリ登録がお勧めできないのなら
どういう運用がお勧めか聞きたいんだけど。

929 ：名無しさん＠お腹いっぱい。 ：03/03/09 04:56

>>927

925は、「リリース管理チームが、任意の時点のバイナリを常に再現
できる (リリース管理チームのバイナリ作成環境がきちんと文書化
されており、ソースコードのみならず、コンパイラやOS、パッチの
レベルも含めて完全に再現できる) 」ということであって、927で
行なっているレベルの保証よりも、より強力なレベルの保証である
ことに気づいて欲しい。当然のことだが、正式なテストは、常に
リリース管理チームが作成したバイナリに対して行なわれる。

繰り返しになるが、927のような開発形態は、テスト済みの筈の
モジュールにバグが発見されたり、仕様に変更が生じたり、あるいは
システム全体に関わる定数の変更の結果、モジュールの再コン
パイルが必要になった場合に、破綻する。
つまり、クリティカルな開発において、より信頼性が高いのは
925の方なんだ。

930 ：名無しさん＠お腹いっぱい。 ：03/03/09 05:05

cvs は、バイナリのバージョン管理には、あまり向いてないから、
cvs を使うのはソースに関してだけにして、バイナリに関しては
別途登録管理すればいいんじゃない？

あと、他の人も書いてるけど、登録されたバイナリの判別を日付
でやるのは意味ない。日付なんて、ちょっとした操作で簡単に
偽造できるんだから。
もし厳密に管理するなら、登録したバイナリのチェックサムを
記録しておいて、それを比較するのが良いと思う。と言っても、
昔ながらのチェックサムやCRCは、やはり偽造が可能なので、
md5 とか sha1 とかいとかいった、偽造が困難な値 (いわゆる
secure hash 値) を登録管理するのが良いと思う。UNIX 系 OS
だと、そのものずばり md5, sha1 とか、digest とか、そういう
値を登録するコマンドは標準でついていることが多いけど、
Windows でもフリーでいくらでも転がっていると思う。
チェックサムの記録の管理には、cvsを使ってもいいかもしれない。

931 ：名無しさん＠お腹いっぱい。 ：03/03/09 05:09

>>929
いやいや、誰もソースや環境の管理しねーとは言ってなくてさ。
まぁいいや、適当にオナニーしててよ。

932 ：名無しさん＠お腹いっぱい。 ：03/03/09 05:11

>>931 (;´Д｀)ﾊｧﾊｧ
…しますた。

933 ：名無しさん＠お腹いっぱい。 ：03/03/09 05:19

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

934 ：名無しさん＠お腹いっぱい。 ：03/03/09 05:20

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

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

935 ：名無しさん＠お腹いっぱい。 ：03/03/09 05:32

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

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

936 ：名無しさん＠お腹いっぱい。 ：03/03/09 05:39

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

937 ：名無しさん＠お腹いっぱい。 ：03/03/09 06:00

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

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

938 ：名無しさん＠お腹いっぱい。 ：03/03/09 06:13

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

939 ：名無しさん＠お腹いっぱい。 ：03/03/09 06:21

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

940 ：名無しさん＠お腹いっぱい。 ：03/03/09 06:21

>>935

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

941 ：名無しさん＠お腹いっぱい。 ：03/03/09 06:27

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

942 ：名無しさん＠お腹いっぱい。 ：03/03/09 06:43

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

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

943 ：名無しさん＠お腹いっぱい。 ：03/03/09 06:46

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

なんか話の流れ見てると

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

が

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

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

944 ：名無しさん＠お腹いっぱい。 ：03/03/09 06:49

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

945 ：名無しさん＠お腹いっぱい。 ：03/03/09 06:52

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

946 ：名無しさん＠お腹いっぱい。 ：03/03/09 07:00

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

947 ：名無しさん＠お腹いっぱい。 ：03/03/09 07:01

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

948 ：名無しさん＠お腹いっぱい。 ：03/03/09 07:03

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

949 ：名無しさん＠お腹いっぱい。 ：03/03/09 07:34

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

950 ：名無しさん＠お腹いっぱい。 ：03/03/09 07:42

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

951 ：名無しさん＠お腹いっぱい。 ：03/03/09 12:22

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

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

952 ：名無しさん＠お腹いっぱい。 ：03/03/09 13:10

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

953 ：名無しさん＠お腹いっぱい。 ：03/03/09 13:11

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

954 ：名無しさん＠お腹いっぱい。 ：03/03/09 13:16

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

955 ：名無しさん＠お腹いっぱい。 ：03/03/09 13:20

>>954
ｽﾚ違い基地外

956 ：名無しさん＠お腹いっぱい。 ：03/03/09 15:57

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

957 ：名無しさん＠お腹いっぱい。 ：03/03/09 16:23

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

958 ：名無しさん＠お腹いっぱい。 ：03/03/09 16:27

次スレは？

959 ：名無しさん＠お腹いっぱい。 ：03/03/09 20:35

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

960 ：名無しさん＠お腹いっぱい。 ：03/03/09 20:45

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

961 ：名無しさん＠お腹いっぱい。 ：03/03/09 20:55

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

962 ：名無しさん＠Ｅｍａｃｓ ：03/03/09 20:57

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

963 ：名無しさん＠お腹いっぱい。 ：03/03/09 21:22

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

964 ：名無しさん＠お腹いっぱい。 ：03/03/09 23:05

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

965 ：900 ：03/03/10 01:10

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

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

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

966 ：348 ：03/03/10 01:18

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

967 ：名無しさん＠お腹いっぱい。 ：03/03/10 02:49

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

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

968 ：名無しさん＠お腹いっぱい。 ：03/03/10 03:14

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

969 ：名無しさん＠お腹いっぱい。 ：03/03/10 03:39

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

970 ：名無しさん＠お腹いっぱい。 ：03/03/10 07:39

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

つーか、次スレは？

971 ：名無しさん＠お腹いっぱい。 ：03/03/10 08:18

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

972 ：名無しさん＠お腹いっぱい。 ：03/03/10 11:11

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

973 ：972 ：03/03/10 11:12

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

974 ：名無しさん＠お腹いっぱい。 ：03/03/10 21:08

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

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

975 ：名無しさん＠お腹いっぱい。 ：03/03/10 21:35

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

976 ：名無しさん＠お腹いっぱい。 ：03/03/10 21:37

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

977 ：棄教者 ◆egKIKYO7cg ：03/04/06 21:51

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

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

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

978 ：名無しさん＠お腹いっぱい。 ：03/04/06 22:03

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

979 ：棄教者 ◆egKIKYO7cg ：03/04/06 23:26

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

980 ：山崎渉 ：03/04/17 12:26

（＾＾）

981 ：山崎渉 ：03/04/20 06:04

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

982 ：堕天使 ：03/04/20 15:22

http://life.fam.cx/

983 ：仕事人 ：2006/08/04(金) 17:49 ID:1iSVMaaQ

誰か教えてください！！
サーバ：win2000server　クライアント：win200pro
CSV＋eclipsを使用しています。
コミットしようとすると次のエラーが出ます。

”cvs　追加”コマンドの実行中にサーバがエラーを報告しました。
cvs　server：scheduling　file　'ファイルのパス'　for　addtion
cvs　server：cannot　rewrite　CVS/Entries，Backup；No space left on device
cvs　server：cannot　rewrite　CVS/Entries，Backup；No space left on device
cvs　[server　aborted];cannot　open　CVS/ファイル名,t；No space left on device

ちなみに、ファイルの拡張子はjavaです。

解決策を教えてください。
お願いします！！

984 ：仕事人 ：2006/08/04(金) 17:51 ID:1iSVMaaQ

983に一部間違いがありました。。。
CSV＋eclipsじゃなくて、
CVS＋eclipsですね・・・。
どうでもいいことでしょうけど・・・。
よろしくお願いします。

985 ：名無しさん＠お腹いっぱい。 ：2006/09/11(月) 17:46 ID:p3lll1po

ｓ

986 ：浪江亮太 ：2006/09/11(月) 17:48 ID:???

ぼっくんこ

read.cgi ver5.26+ (01/10/21-)