5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

バージョン管理ツールの必要性

1 :仕様書無しさん:2006/07/04(火) 14:23:48
CVS・VSSなどのツールがチーム開発における構成管理の運用に
役立つものであるのかを議論するスレッドです。
必要派、不要派の忌憚ない意見を投稿してください。
安直なマンセー・却下はご遠慮願います。

2 :仕様書無しさん:2006/07/04(火) 14:48:45
>>1 SVNが入っていない時点で終了。
いまどきCVSとかVSSなんてありえね(プゲラッチョ

3 :仕様書無しさん:2006/07/04(火) 15:06:05
ツールがどうこうの前に人間系のルールを決めないと意味がない

4 :仕様書無しさん:2006/07/04(火) 18:39:44
この手のツールは結局
人がルール守らないから強制させる為の物

無くても出来るではなくさせる為の物だから必要
ただその運用も守らないからあっても意味無い所が多いのには同意

5 :仕様書無しさん:2006/07/05(水) 00:37:43
>>2のレスで思い出したけど、
そういやプロジェクトがSVNに変わるんだった。

6 :仕様書無しさん:2006/07/05(水) 02:43:16
良スレage

7 :仕様書無しさん:2006/07/05(水) 13:27:05
チーム開発じゃなくても十分に役立つんだけど、
一人でやってるからそういうの無意味だよ、とかって言う人、
たまに居るよね。

8 :仕様書無しさん:2006/07/05(水) 22:37:57
一度も使ったこと無い人ね。

9 :仕様書無しさん:2006/07/05(水) 22:38:38
ソースコードにもよるんだろうね。
1つのソースをみんなで突かない限りバッティングすることは無いわけだから
いらないっていう現場があってもおかしくないでしょ。

いまだにプロジェクトに全変数が記述されていたりするマスターヘッダーなんてものがある
環境ならバージョン管理は確かにいるけどそういうものがないなら基本的に
ソースをみんなで突き合う状態にはならないでしょ。

この場合バージョン管理なんてあんまり必要ない。
あと、現場によっては前回と今回のバージョンで差分を出してソースレビューをするところもあるとか・・・
そういうことをやる環境ならバージョン管理は無いと確かに面倒臭い。

ソースコードの内容まで突っ込まないとその人の環境でバージョン管理が必要かどうかはわからないな。

10 :仕様書無しさん:2006/07/06(木) 01:39:17
>>9
そりゃ、実験的なことをするためにブランチ切ったり、バグフィックスと機能強化を並行して
行ったりしない単純な開発だけやってりゃいらないかもな。

11 :仕様書無しさん:2006/07/06(木) 02:04:57
まだ必要性を論じている段階なんですか、って感じがする。


12 :仕様書無しさん:2006/07/06(木) 07:04:57
>>10
別にそんなの当り前の話で単純とか複雑とかいう話にはならない。

13 :仕様書無しさん:2006/07/06(木) 09:48:07
ソース1本ならバージョン管理ツール要らないって・・
バッティング解決のためだけのツールじゃないんだけど・・。
もしかしてソフト改修の度に修正箇所をコメント化して残したり
丸ごとファイルコピーしたりしてるの?



14 :仕様書無しさん:2006/07/06(木) 19:09:34
>>13
いや、そもそも改修作業に対するドキュメントの整備が義務化されてないから
そんな手間はいらない。

15 :仕様書無しさん:2006/07/06(木) 20:46:17
改修作業をコードの書き直しだけと思ってる奴も居るくらいだからな
テスト位やれよ

16 :仕様書無しさん:2006/07/06(木) 21:27:04
>>15
でも、前との差分とってどうにかなる改修なんて結局前の差分なんていらんし。
そういう既存のソースをいつまでもとっておく会社って糞コードになってるところ多いじゃん。

17 :仕様書無しさん:2006/07/06(木) 21:32:22
#if 0
/* 元が酷いので修正 */
(コード…)
#endif

#if 0
/* ↑が目に余るので直した */
(コード…)
#endif

#if 0
/* ↑は五十歩百歩、根本的に修正 */
(コード…)
#endif

#if 0
/* オリジナルがいちばんまとも+バグ修正 */
(コード…)
#endif

こんなソースを見ないためにも必要。

18 :仕様書無しさん:2006/07/06(木) 22:22:15
一人であっても、普通に「どの時点にでも安心して戻れるアンドゥ」のためのツールとして
便利だよな。

19 :仕様書無しさん:2006/07/06(木) 22:24:44
VSS何とかして欲しい点

・Officeファイルの差分を表示できない(同じMS製品やろが!)
・サーバーのPCの時間でなくファイルをうpしたPCの時間でチェックインされてしまう

20 :仕様書無しさん:2006/07/06(木) 22:27:01
>>18
アンドゥ自体そんなしないし。
するとしてもエディタのアンドゥ以上の機能必要ないし。

21 :仕様書無しさん:2006/07/06(木) 22:28:21
>>19
VSS何とかして欲しい点:追記

同僚の上げやがったDebugとReleaseをもっと速く消してほしい。

22 :仕様書無しさん:2006/07/06(木) 22:37:05
最近追加開発で入ったプロジェクトが、
既存ソース見ると、あちこちに
「---- 2004/12/3 h.sato modify start ----」
とか書かれてる。
あと、使わない部分もコメントアウトされてるだけで削除されてない。
だからソースが読みにくいこと読みにくいこと。
こういうのって、バージョン管理ツールが無いところの発想だよなぁ。
会社の方針ってわけじゃなく、初期開発した会社が勝手にやっただけらしいから
自分が触るクラスにそういうのがあったら、ばんばん削除してるけどね。

>>9とか、「バージョン管理」って意味が分かってない奴が多いな。
競合管理にしか使わないなら、ただのファイルサーバで
読み取り専用のON/OFFあたりで管理すれば充分。
一人でやってもバージョン管理は必要だよ。

>>10
何一つ実験的なこともしてないしブランチ切ったりもしないけど
それでもバージョン管理ソフトのありがたみは充分わかる。

23 :仕様書無しさん:2006/07/06(木) 22:47:36
>>22
てか、昔のソースなんて残しておく必要ないよ。
昔、どうなってたか、なんて確認する必要ないって。
いつ確認する必要がでるの?
それって誰かが「あのときは動いた」って主張してるときだけでしょ?
そんなのつい最近のことじゃん。
しかも、差分比較してわかるような内容なら昔のソースなんてみなくたって原因特定できるって。

すくなくとも1週間以上前のソースを残す意味がわからない。(開発時)
前の納品物をとっておく程度ならわかるんだけど。

24 :仕様書無しさん:2006/07/06(木) 22:49:07
>>22
で?
君がバージョン管理ツールが必要だと主張する理由がかかれてないのは叩かれたくないからかな?w

25 :仕様書無しさん:2006/07/06(木) 22:51:28
>>23 君みたいな人のためだよ

26 :仕様書名無しさん:2006/07/06(木) 23:06:18
>>20
リファクタリングしてるうちに訳わかめになって、
前に戻すときには非常に便利。

27 :仕様書無しさん:2006/07/06(木) 23:31:29
>>26
そこまで戻す必要に迫られないw

28 :仕様書無しさん:2006/07/06(木) 23:42:08
>>24
22の文章だけでも、バージョン管理の利点が理解できないPGがいるとは思わなかった。
ちょっとこのスレのレベルを甘く見てたな、すまなかった。

つまり、バージョン管理をしていないところでは
しばしば
「---- 2004/12/3 h.sato modify start ----」
というような形式で、誰がいつ、どこを弄ったのかをソース中に記述していたり、
本来なら削除すべき部分をコメントアウトで残しておいたりして、
ソース自体の可読性が非常に低下する。
バージョン管理ソフトを使えばこれらが不要になる。

そもそもそういうログは不要ではないかという意見もあるかもしれないが
自分が対応したものに不具合が出て、前のバージョンに戻す必要が出たとき
そういうログが無い場合は、「前のバージョン」を1から作ることになるのか?
その方がよほど効率が悪いのではないか。

これぐらい22を拡張すればわかるかな。

29 :仕様書無しさん:2006/07/06(木) 23:44:17
逆になぜバージョン管理を拒む人がいるのか、わからない。

30 :仕様書無しさん:2006/07/06(木) 23:53:39
>>23
仮に、一週間以上前のバージョンを残す必要がないと仮定して。
一週間あれば、内容にもよるけど延べ10〜100ファイルぐらいは
コミットすることが出来ると思うんだけど、
その間のバージョン管理はどうするんだ? 手で頑張るのか?

しかも1週間って、PGと単体しか担当しない奴の視点だと思うんだが。
例えば結合でA、B、Cと3つバグが出て、
ABCの順で直しました、それぞれ単体も通して再度結合テストしました、
そしたらBの修正が原因の別の不具合が出ました。
こんな事はたまにあることだと思う。特に外接とか携帯対応とかあると。
こういう時、A、B、Cそれぞれの修正範囲がわからなければ、
Bの修正だけ再修正するために、多大な労力を支払わなきゃならないだろう?
大体ここまでに、一週間以上経ってると思うんだが。
結合ならまだ一週間でいけるかもしれないが、それが総合とか受入になればもっとだな。

31 :仕様書無しさん:2006/07/06(木) 23:55:19
>>29
ネタ

32 :仕様書無しさん:2006/07/07(金) 00:15:19
>>27
過去に安心して戻れることが保証されていると、派手にリファクタリングしまくれる。

クラス名や変数名をちょっと変えるだけならまあ人間でも覚えておけるが、
糞コードをガラリと書き直すとか、アルゴリズムを大幅に差し替えるとか、
その辺になるともう昔のことは覚えたくないだろ。

で、その後、万が一コンパイルや xUnit が通らなくなったとかなった場合に、
バージョン管理してればサクッと revert すればよいだけ。

33 :仕様書無しさん:2006/07/07(金) 00:20:17
フロッピーディスク持って各担当者のプログラムをかき集めて再構築してた頃に比べりゃ、天国だろ。

つうか、人間関係とか、ルール守らないとか、関係無いですから。

34 :仕様書無しさん:2006/07/07(金) 01:22:30
ヴァージン管理ツール

35 :仕様書無しさん:2006/07/07(金) 02:06:46
>>34
ガードは堅いですか?

36 :仕様書無しさん:2006/07/07(金) 06:51:30
>>30
>その間のバージョン管理はどうするんだ? 
さぁ?
必要だったことないからわからない。
そもそも1週間前はそうだったよ。
なんていわれたって「ふーん」以上。
一週間前そう動いたっていうならそれは主張する奴に実証させればいい。
だいたい、こういうのが問題になるタイミングってのは他のどっかに
リリースしたタイミングだけだから、そのリリース時のソースだけを残しておけばいい。
それ以外のときは問題にならない。

37 :おじゃばさま:2006/07/07(金) 08:40:51
>36
仕様変更されてAさんが修正した。Aさんは契約切れでいなくなった。
2週間後に「やっぱりこの前の仕様変更はなし。元に戻して。」って言われたらどうする?
ちなみにAさんはその仕様変更以外にも修正してるし、連絡は取れない。

>32
一つだけ言いたい事がある。
「コンパイルが通らないソースをチェックインするな!!」


38 :仕様書無しさん:2006/07/07(金) 08:56:23
古いソースをコメントで残す事がなくなった
思い切った改修が出来るようになった
動作がおかしくなったら正常に動くリビジョンまで戻ればいいし
本当に便利

39 :仕様書無しさん:2006/07/07(金) 09:15:39
要するに作成物に対する責任を感じない人間は管理もしない。
「どんな変更したの?」「えー、わすれたー」
「以前はどう書いてたの?」「えー、しらなーい」
「以前のバージョンで検証したいんだけど」「えー、むりー」
「私が修正した部分が消えてる・・」「俺は悪くないもん」
「何でちゃんと残さないの?」「だってそうしろって言われないしー」
「リファクタリングしようよ」「えー、動いてるからいーじゃん」

あと「---- 2004/12/3 h.sato modify start ----」 な現場って、
コメント抜きでも数百行の関数とか平気で作ったりするのな・・。


40 :仕様書無しさん:2006/07/07(金) 12:30:22

すみません。初歩的な質問なのですが。

A -> B -> C -> D

という改変があったとして、(仮にすべて機能追加だとします。)

B や C の時点に戻せるのは当然だと思うのですが、

B の変更を加えていない C

つまり、

A -> C

のような復元(そもそも復元じゃないんでしょうけど)

って可能でしょうか?



41 :仕様書無しさん:2006/07/07(金) 12:50:33
そりゃ、CVSなんてリビジョン間の差分情報で管理してるし、
サーバーからローカルにチェックアウトするときは、
ローカルの変更生かしたままで差分情報をローカルに加えて最新ソースにするお。

つまり、初歩的質問じゃなくて、愚問。

42 :仕様書無しさん:2006/07/07(金) 14:02:51
>41が言ってることはいまいちわからないが

>40
ツールの機能として出来るかと言えば無理だとおもう。
少なくとも聞いたことはない。
でもまあ、バージョン管理してあれば
してないときよりは遥かに効率よく戻せるよ。

43 :仕様書無しさん:2006/07/07(金) 14:42:22
B が機能追加じゃなくて機能削除だったとしても大丈夫かなぁ


44 :仕様書無しさん:2006/07/07(金) 15:01:51
>>40
Bでの修正の中に間違いが発見されて、それを修正してCにした場合は、どうしたらいいんだ?


45 :仕様書無しさん:2006/07/07(金) 15:16:05
>>44
どうしたらいいですか?


46 :仕様書無しさん:2006/07/07(金) 15:56:49
どのリビジョンにも行ったり来たりできなかったっけ?
俺はやってたつもりだったんだが

47 :仕様書無しさん:2006/07/07(金) 16:02:41
>>46
どのリビジョンでも行き来出来るのはもちろんだけど、
特定のリビジョンだけ取り消して、その後の変更は残すなんてのは
人力が必要か、という話ではないのか。


48 :仕様書無しさん:2006/07/07(金) 16:10:11
それは確か無理だよね
履歴を取り消す行為自体がバージョン管理に反する

49 :仕様書無しさん:2006/07/07(金) 16:31:20
>>48
ツール上の履歴を取り消したいという話ではないから
バージョン管理には反しないのでは?
もう一回>>40読んで話の流れをつかんでくれ。

50 :仕様書無しさん:2006/07/07(金) 16:34:31
BとCが独立かどうかによる
と言ってしまうと元も子もないが
そもそも独立かどうかが分からないことが多いかな

51 :仕様書無しさん:2006/07/07(金) 22:06:06
普通に、A→B の変更点とB→C の変更部分を見ながら手で修正だろ。
WinMergeのようなビジュアル差分エディタがあれば変更点を色付きで表示してくれる。
あとはソースを見比べながら「ここは必要」「ここは不要」と選んでいくだけで作業完了。

ただし、それできちんと動くかどうかは別問題。
そもそもプログラムの動作までチェックしてくれる神ツールなんぞ無いから
普通はこれにUnitテストツールなんかを活用してバグの発生を抑えるわけだ。

52 :仕様書無しさん:2006/07/08(土) 06:27:07
できるか、できないかを聞きたいだけなのに、
いきなり頼まれもしてないのに、わざわざやり方を披露しはじめる人って馬鹿に見えませんか?

53 :仕様書無しさん:2006/07/08(土) 06:28:21
しかも、わかってることを。

54 :仕様書無しさん:2006/07/08(土) 06:51:32
劣等感丸出し

55 :仕様書無しさん:2006/07/08(土) 08:13:31
もし B と C が独立なら、そもそも
A -> B -> D
A -> C -> D
というパスが可能なはずで
そういう管理が可能かどうかという話が出来るんだけど

A -> B -> C -> D
という一次元の管理になってることが問題なんじゃない?

56 :仕様書無しさん:2006/07/08(土) 12:30:00
SCM知らない奴って、拒否反応を示すか逆にへんな幻想を抱くかのどっちかだよな。

バージョン管理は単に履歴を残す為のツールであって、それ以上でも以下でもない。
なんか導入するだけでバグが経るとか勝手にバックアップ取れるとかチーム開発が上手く行くとか
過去のバージョンから途中をすっ飛ばして今回の修正だけ付け加えたいとか。

んなわきゃねーだろ!!

57 :仕様書無しさん:2006/07/08(土) 12:40:56
つか、Aの上にBがあって、Bの上にCがあって、Cの上にDがある構造なのがバージョン管理。
だからBを抜いてCが存在すること自体不可能だと思われ。

これは別にファイルをわけたらどうとかってもんじゃなくて
因果律みたいなモンで絶対に不可能なことだと思われ。

でも、正直、できてほしいのは確かに>>40みたいなことなんだよね。
だから、はじめ導入して「あれ?」って思うのはこの辺。
こうなると「あんま役に立たんかなぁ・・・」って思うのも無理はない罠。

俺もバージョン管理は履歴を垂れ流すだけでそこまで便利なツールではないと思う。

58 :仕様書無しさん:2006/07/08(土) 12:43:12
まあ普通に考えればどだい無理な話だわな

59 :仕様書無しさん:2006/07/08(土) 12:44:04
あくまで作業履歴だからなバージョン管理は。ソースを自動的に
変更させるためにあるんじゃない。
一部だけ戻したら、戻すという作業が履歴として残り、
次のリビジョンが作られる。それだけだ。
>>55
一次元の管理が問題じゃなくて、システムの目的を履き違えてるお前のほうが問題。

60 :仕様書無しさん:2006/07/08(土) 13:30:07
ここ10年のCSで一番進化が遅れているのがCVSかも試練

61 :仕様書無しさん:2006/07/08(土) 13:37:36
よく言えば枯れてる
それが不満ならSVNがあるだろうに

62 :仕様書無しさん:2006/07/08(土) 14:13:51
SubVersion(SVN)いいね。
と言っても、自分はちゃんといろんな機能使ったことはないけど。

最初の案件だけVSS使ってて、その後はずっとCVSでやってきてて
VSSと比べた、CVSの機能の弱さにかなり参ってたんだけど、
この間入った案件がSVNだった。
その時はCVSと同じような機能しか使わなかったんだけど、別に使いにくくなかったし
その後、ディレクトリ削除とか、ファイル移動とか、
日本語ファイル名の各種バイナリファイルの登録が出来ると聞いて感動した。

VSSと比べて足りない機能って、チェックアウト機能ぐらいか?

63 :仕様書無しさん:2006/07/08(土) 17:08:12
clear case はどう?

64 :仕様書無しさん:2006/07/09(日) 00:44:54
ドキュメント関係はVSS、ソースはCVSかSVNが良いと最近思う
ワードやエクセル等の差分を見れるツールってないのだろうか

65 :仕様書無しさん:2006/07/09(日) 00:52:08

ありますよ


66 :仕様書無しさん:2006/07/09(日) 01:51:11
>>62 チェックアウトっぽい機能(ロック)はあるよ。
ttp://subversion.bluegate.org/doc/ch07s03.html
ttp://www.caldron.jp/~nabetaro/svn/TortoiseSVN_ja/tsvn-dug-locking.html

ただし、VSSの感覚とは別物なので注意が必要。

>>64 xdocdiff だな
ttp://www.itmedia.co.jp/enterprise/articles/0510/31/news108.html
ようは一旦テキストにしてその差分を表示するツール。
まぁ、これで事足りる人は使えば?ていう程度のものだが。

個人的には画像の差分比較ツールがあれば助かるんだけど、なかなか使えそうなものがないんだよな。

67 :仕様書無しさん:2006/07/09(日) 02:09:11
>>66
そんな微妙な動作ごちゃごちゃ覚えなきゃいけない時点で返って手間が増えてる希ガス。
なんかもう1週間ごとにみんなのもってるソース丸ごとコピーでいいよ。

68 :仕様書無しさん:2006/07/09(日) 02:13:30
原始人あらわる

69 :仕様書無しさん:2006/07/09(日) 08:03:07
毎日、バックアップしてます。
ソース入ったフォルダごと。

70 :仕様書無しさん:2006/07/09(日) 08:17:06
OSのファイルシステムが進化してくれれば、まるごとバックアップでいいんだよな。
とりあえず、コピーしても時間がかからなけりゃいいし、
もうちょっとすすんで、何からコピーされたか情報がのこってくれるといい。


71 :仕様書無しさん:2006/07/09(日) 09:43:11
SubVersionをLinuxにインストールする段階でくじけた

72 :仕様書無しさん:2006/07/09(日) 10:59:56
>>70

プロジェクトごと圧縮するとコピーすればするほど圧縮率上がるから問題なしだね


73 :仕様書無しさん:2006/07/09(日) 13:05:38
手作業で行うとミスがあるし
060709.zipとかのファイルが延々と増えていくのも馬鹿らしい

74 :仕様書無しさん:2006/07/09(日) 15:23:30
>>73
そうはいってもあんまりでかいとVSSとかってハードディスクに入りきらないとき面倒なんじゃね?
小さいプロジェクトとかソースだけとかならハードディスクにはいるだろうけど。

75 :仕様書無しさん:2006/07/09(日) 15:25:35
そんならなおのこと丸ごと保存するのは馬鹿らしいだろうに
バージョン管理ツールは差分で管理するからサイズも小さいよ

76 :仕様書無しさん:2006/07/09(日) 15:55:33
CVS、SVNで競合無視してオーバーライドとかする奴がいると泣きたくなる

77 :仕様書無しさん:2006/07/09(日) 16:23:53
>>75
いや、丸ごと保存の場合はzipにまとめて日付だけ気をつければいいけど、
VSSの場合ハードディスクってわけて使えるっけ?
つまり、片方のハードディスクが一杯になったら、別のハードディスクも取り付けて使用可能かどうかだけど・・・。

78 :仕様書無しさん:2006/07/09(日) 17:10:24
使用可能です

79 :仕様書無しさん:2006/07/09(日) 17:31:05
>>78
マジで?
どういう仕組みなんだ?
ハードディスク3つ目に突入したとして、始めの1つ目が死んだら、
他の2つも平行して死亡なんではないだろうか?実はw
なんつーか、ソースとデータでわけたいな。
ソースはハードディスク1つあれば十分過ぎるけどデータがでかい。無駄にデカイ。
差分を保存とか効かないし。
始めにわけなかったから共倒れ状態だな。

80 :仕様書無しさん:2006/07/09(日) 17:36:35
そうはいってもzipで丸ごと保存する方法を取った場合は
バージョン管理の場合に比べて何十倍もの容量が必要になるわけで
そもそもの比較が不適切ではないか?

81 :仕様書無しさん:2006/07/09(日) 17:38:30
>>80
いや、そうでもない。
1ヶ月単位でまとめて圧縮かけたりすると圧縮率が結構高くなる。(そりゃ同じプロジェクトだしねぇ)

82 :仕様書無しさん:2006/07/09(日) 18:10:40
>>80

0709.zip
0710.zip
0711.zip

とかやってない?効率悪いよ


hogeproject/0709/...
hogeproject/0710/...
hogeproject/0711/...
hogeproject/0712/...

hogeproject というディレクトリに圧縮かけるんだよ


83 :仕様書無しさん:2006/07/09(日) 19:05:01
>>82
構成管理って保存だけが目的じゃないだろ。
効率悪すぎなんだよ。死ねよ。

84 :仕様書無しさん:2006/07/09(日) 19:06:57
あらら、差分管理もできないJavaプロジェクトの厨が暴れてるのか

85 :仕様書無しさん:2006/07/09(日) 19:08:41
丸ごと馬鹿な丸ごとzip厨が暴れていると聞いて
駆けつけました。

86 :仕様書無しさん:2006/07/09(日) 19:12:02
>>83
いや、保存だけだろ。
他にあるなら上げてみろ。

87 :仕様書無しさん:2006/07/09(日) 19:21:05
>>86
トラッキング

88 :仕様書無しさん:2006/07/09(日) 19:24:41
>>87
はぁ?

89 :仕様書無しさん:2006/07/09(日) 19:36:12
使ったこと無い連中に何言っても判らんよ>バージョン管理

90 :仕様書無しさん:2006/07/09(日) 19:43:49
>>86
バージョン管理という言葉の意味を考えてみ

リポジトリのバックアップはもちろん別にやるぞ

91 :仕様書無しさん:2006/07/09(日) 21:44:49
日付で管理って事は、古いバージョンとの差分が欲しいときは
変更が入った日を探すために、
日付ごとのファイルをいちいちWinMargeにかけるんだな。
当然変更コメントなんてツールでは管理できないから、
ソースに全変更コメントを記述するか変更コメントは残さないかの2択になりそうだ。
各バージョンの更新者管理も出来ないな。
自分の管理してるソースを、誰かがこそっと変更していても犯人がわからないのか。
チェックアウト機能もないから、毎日全ファイルを最新と差し替え。

……面白すぎるw

92 :仕様書無しさん:2006/07/09(日) 21:50:19
>>91
え?君、なんか頭悪いだけじゃない?

93 :仕様書無しさん:2006/07/09(日) 22:00:08
バージン管理ならやってみたいかも

94 :仕様書無しさん:2006/07/09(日) 22:02:30
>>92
ん? 自分はバージョン管理ツールで使ってる機能を思い浮かべて
単にファイルサーバに上げて日付別でバックアップ、となると
実際にどう自分の作業が変化するのか考えただけだけど?
実際かなり不便になりそうに思えるけど、どこがおかしいかなw

チェックアウト機能って書いた部分だけは、アップデート機能の間違いだな、スマソ。

95 :仕様書無しさん:2006/07/09(日) 22:04:37
>>80
今時のストレージの大容量化低価格化を考えたら、さして障害になるとも
思えないが。何十ギガバイトもソースがあるわけでもないだろうし。

96 :仕様書無しさん:2006/07/09(日) 22:12:31
前の会社でバージョン管理導入して
不便になったという人居なかったけどな

今の会社でも布教してて
使い始めると好評

たまに面倒がる人もいるけど
その人はそもそもドキュメント書くことも苦手で
古いタイプのPGの人だけだね。

ほとんど、今までなんで使わなかったんだろうって言う人ばかりだ
いまだにバージョン管理使わないのはよほど不勉強な人ばかりの職場なんじゃないの?

97 :仕様書無しさん:2006/07/09(日) 22:13:50
>>94
馬鹿か?
そういう時は変更点も台帳とか作って別途管理するだろ普通

98 :仕様書無しさん:2006/07/09(日) 22:17:49
>>96
いや、別にあってもいいけど細かいルール付けばっかりこだわってそれの整備を理由に仕事しない奴がいるのよ。
で、そいつの決めるルールがまたうざくて、正直、もうバージョン管理なんてしなくていいよ。って感じ。

99 :仕様書無しさん:2006/07/09(日) 22:18:21
手動管理してる人は大体、ほんとに手動
(ソースフォルダをコピーor圧縮→名前に日付を付け加える→サーバ等にアップ)
でやってて、この処理をするスクリプトorバッチファイルを作っていて、かつ
バージョン管理システムはめんどくさいと言ってる人はあまり見たことない。

100 :仕様書無しさん:2006/07/09(日) 22:19:21
>>97
台帳つけるぐらいなら最初からバージョン管理使えよw

101 :仕様書無しさん:2006/07/09(日) 22:20:01
変更するたびに台帳の奪い合いになるのか〜。
そんな仕事、俺はごめんだし「普通」ではないとおもう。

102 :仕様書無しさん:2006/07/09(日) 22:21:46
>>98
それは確かにウザイね、同情するよ

最初は厳密にやらんでもチェックイン・チェックアウトのやり方と
リビジョン番号の管理やらリリース管理とかだけ決めて
徐々にやったほうがいいんだよね

どんなツールでもそうだけど、使う側が使ってくれないと意味無いからね


103 :仕様書無しさん:2006/07/09(日) 22:22:23
そんな台帳もつけないでしょ。
ただ、日付があってそれに対応するプロジェクトが保存してあるだけ。
そもそも解凍すること自体ありえないけど。

104 :仕様書無しさん:2006/07/09(日) 22:23:10
>>102
てか、そういう決める事項があるだけで奴等のいい口実になっちゃうの。

105 :仕様書無しさん:2006/07/09(日) 22:24:05
でも少々うざいのは仕方ないよ
そうやって「啓蒙」してかないと慣れたことしかしないんだし。
否定派は個人目的で良いからまずsubversion入れることを勧める。

106 :仕様書無しさん:2006/07/09(日) 22:27:44
スレ違いかもしれんが、今はバージョン管理や構成管理って言うと何があるの?

おいらが知ってるのはVSS,CVS。
製品名が違うんだろうがPVCSシリーズ


107 :仕様書無しさん:2006/07/09(日) 22:30:46
>>105
御利益が「過去のソースがどうなってたか?」ってのが見れるだけじゃん。
見ないよ。
見たいと思ったことないもん。
やっぱり、会社で作業してて「昔はこうだった」って言われたときぐらいしか開くことないって。

108 :仕様書無しさん:2006/07/09(日) 22:31:57
>>107
見ないのかよw

109 :仕様書無しさん:2006/07/09(日) 22:34:24
製品としてリリースしているプログラムで不具合が発生したときに、どのバージョンのものかで再現性が変わるからなぁ。
既知の不具合ならサポセンで完結するからどうでもいいけどさ。

110 :仕様書無しさん:2006/07/09(日) 22:36:46
そりゃバージョン管理自体してないなら意味ないわな

111 :仕様書無しさん:2006/07/09(日) 22:39:37
うちの会社だと
複数の人間が、同じソースを触ることがあるから更新ミスを防ぐだけでも効果あったよな

手動でも更新台帳運用で問題ないようなとこならいいんだろが
レベルの低いうちんところはバージョン管理入れるだけでも劇的にミスが減ったよw

112 :仕様書無しさん:2006/07/09(日) 22:40:04
CVS入れたらデグレが増えるケースってあるよな。
分岐の激しい場合とか特に。

113 :仕様書無しさん:2006/07/09(日) 22:42:41
>>112
分岐はつかったことないけど
CVSとかバージョン管理ソフトというより
開発ルールとかの問題と思うなあ

114 :仕様書無しさん:2006/07/09(日) 22:45:52
>>97
ヒューマンエラーの事を考えない馬鹿発見w
「他の奴が台帳つかんでるから後にしよう」
とか言って、そのまま更新し忘れる奴が絶対出るだろw
バグ発生自体を隠したいとかで、意図的に台帳記入しない奴もいるだろうし。

115 :仕様書無しさん:2006/07/09(日) 22:48:29
>>111
バージョン管理システムの最大の利点は、そういう「劇的なミス」を
防ぐことだから、「俺はそんなミスはしない」と思ってる人を説得するのは
ホント難しいんだよね。一度痛い目にあってもわらないと。
(しかしそういう人は痛い目にあっても相変わらず学ばないのだが)

116 :仕様書無しさん:2006/07/09(日) 22:51:03
>>115
そうなのよ
「そんなの無くても各人が”注意”してやればいい」
って発想だよな

元が生産工学系なんで、人間の”注意”だけに期待するのはオカしいと考えるんだけど
そうでないらしい。

117 :仕様書無しさん:2006/07/09(日) 22:51:18
バージョン管理目的で圧縮ファイル残してる奴は
四の五の言わずsubversionインスコするべき

118 :仕様書無しさん:2006/07/09(日) 22:52:03
>>115
なんでそんなほとんど問題にならないことに力入れてるの?
こんなとこ問題にならねぇよ。

119 :仕様書無しさん:2006/07/09(日) 22:52:38
>>112
自分も分岐はマトモに使ったことはないな。
どういう時に使って、どう管理するもの?

120 :仕様書無しさん:2006/07/09(日) 22:52:44
開発してて昔のバージョンのソースをそんなに頻繁に見るのか?

121 :仕様書無しさん:2006/07/09(日) 22:53:44
ぶっちゃけ、業務システムみたいに何とか版何とか版ってひたすら分岐していく奴には
SVNのほうが向いている。
CVSはオプソのように大人数で一つのバージョンに向かって作りこんでいく場合に向いている。

適材適所で使わないとデグレの嵐。

122 :仕様書無しさん:2006/07/09(日) 22:54:37
>>118
そんなこと言ってると

客先「いついつのバージョンを元に別ソフト作って」
自分「そのときのソースはもうありません」

てことになる

123 :仕様書無しさん:2006/07/09(日) 22:56:09
>>120

コード管理とは無関係に単にデータのバックアップを考えて見れ
そんなに頻繁にバックアップデータにアクセスするか?

万一のときのためにあるんだよ。万が一だよ。


124 :仕様書無しさん:2006/07/09(日) 22:59:33
機械的に管理されるということは人為的なミスを減らすということ
バージョン管理なんて場合によっては致命的なことになるんだし。

125 :仕様書無しさん:2006/07/09(日) 23:07:42
その万が一なんてときっていつくるの?
俺は普通に納期に間に合わねぇ自体のがよっぽど多いけど。
一生懸命導入して決めごと確立してメンバーに徹底させるほどの意味ねぇじゃん。

126 :仕様書無しさん:2006/07/09(日) 23:11:21
作りっぱなでメンテしないならいらないんじゃね

127 :仕様書無しさん:2006/07/09(日) 23:11:49
バージョン管理しつつ、サーバがお亡くなりになった場合にそなえて定期的に
cron等を使ってバックアップを取る。これでいんじゃないか?

128 :仕様書無しさん:2006/07/09(日) 23:24:40
なぜか強く抵抗を示す人がいるんだよな。不思議。

129 :仕様書無しさん:2006/07/09(日) 23:29:03
>>128
それ(バージョン管理)を仕事にされてたまるか。以上。

130 :仕様書無しさん:2006/07/09(日) 23:30:29
仕事はツールがやるもんじゃね

131 :仕様書無しさん:2006/07/09(日) 23:31:08
そだな。
うちは毎日の差分ダンプと一ヶ月ごとのフルダンプをcronで走らせてるよ。
しかも同時にミラーサーバーにもコピーしてるのでSVN用サーバーが死んだら
切り替えるだけで通常通り稼動するので、最悪でも24時間分の巻き戻りですむ。

あ、いま書いてて思い出した。そろそろダンプをCDに焼いてディスク領域をあけなきゃだわ・・・

132 :仕様書無しさん:2006/07/09(日) 23:34:33
>>131
はぁ・・・無駄・・・
何をそんなに恐れているのか全くわかんね。
もっと優先度の高いリスクはほかにもたくさんあるだろうに・・・。
自己満足通りこしてキチガイだな。

133 :仕様書無しさん:2006/07/09(日) 23:34:40
>>126 俺はまさにそうしている。
ところで、バージョン管理を嫌がる奴ってどんな奴が多い?
俺のところでは、確かめもせずに「〜のはずです」「できません」を
連発して、バグだらけのものをリリースする奴です。

134 :仕様書無しさん:2006/07/09(日) 23:34:50
>>129
バージョン管理ツール云々より
おたくんところの導入旗振り役の奴の問題じゃなかろか

135 :仕様書無しさん:2006/07/09(日) 23:36:03
>>129の意味がわからない。
バージョン管理ツールを使ったほうが、制作効率が上がるわけだが。

136 :仕様書無しさん:2006/07/09(日) 23:36:19
>>132
正直導入すれば幸せになれるものをどうしてそこまで拒むのか判らん

137 :仕様書無しさん:2006/07/09(日) 23:37:42
マージうざい。
俺のソースにゴミをまぜるな

138 :仕様書無しさん:2006/07/09(日) 23:39:10
○月×日以降にこのバグ出てるみたいなんですけど・・・
⇒そんな時には?

139 :仕様書無しさん:2006/07/09(日) 23:40:38
バグなんてなおせばよくね?

140 :仕様書無しさん:2006/07/09(日) 23:41:32
>>133
うちんところにいたのは単に操作がメンドクサソウって奴だったな
便利そうとか興味はあったんだが
そいつは退職した連中の引継ぎソースを雪だるま式に抱えてて
それらを把握するだけでうんざりだったんだと思う
バージョン管理ソフトに登録しようにも整理する暇なさそうだった

で、今そいつが辞めて地道にVSSに登録しだしてる

141 :仕様書無しさん:2006/07/09(日) 23:41:51
>>135
効率は上がらないでしょ。
バッティングなんて普通しないもの。
過去のソースを見ることも普通はそれほど頻繁にはない。

>>136
問題はバージョン管理ツールの管理を仕事にする奴がいるのが頭にくる。

142 :仕様書無しさん:2006/07/09(日) 23:42:14
規模も決めずに議論しても仕方ないから必要になる基準を作ればいいんじゃね?

従事する開発者の数:
全ソースファイル数:
開発期間     :
使用する言語   :
成果物の耐用年数 :


143 :仕様書無しさん:2006/07/09(日) 23:42:18
>>139
そんなときに○月×日以前と以降の差分を比較してバグの原因を探るんだろ?


144 :仕様書無しさん:2006/07/09(日) 23:43:39
>>142
そういう基準を作るのにまたくだらない会議をするのがいる・・・すげーむかつく。

145 :仕様書無しさん:2006/07/09(日) 23:43:42
>>141
なら自分で管理すれば問題ないのでは?

146 :仕様書無しさん:2006/07/09(日) 23:44:58
>>132 別に、優先度がどうって程難しくないよ。
空いてるPCにLinux+Apache+SSH+SVN入れてるだけで
cron用の定期バックアップスクリプトも単純だし。

全部の環境用意するのに3日もかからなかったんだが、その程度の作業で
バージョン管理の環境が得られるんなら安いもんだと思うがな。
それも出来ないほど忙しいってんなら、もっとヒマな時に環境作ってみれば良いじゃん。
Linux鯖なんて猿でも作れるんだしさ〜

147 :仕様書無しさん:2006/07/09(日) 23:45:37
パーのためのツールだろ。

148 :仕様書無しさん:2006/07/09(日) 23:45:41
>>145
いや、そいつがやりたがるし、「時間とらないでね」っていってるのに
「うーん」とかなんかよくわからんこと悩んでて(おそらくフリ)いつもサボり出す。
いっとくけど仕事割り振ってるの俺じゃないし、自分が勝手にやるとかできないから。
会社に勤めたことあるの?

149 :仕様書無しさん:2006/07/09(日) 23:46:17
>>146
その作業に導入と毎日の動作で何分かけた?

150 :仕様書無しさん:2006/07/09(日) 23:46:34
>>148
中小なんだよ
悪いかコラ

151 :仕様書無しさん:2006/07/09(日) 23:47:37
>>150
てめぇのところはバージョン管理なんてしてる場合じゃねぇだろ。タコ。

152 :仕様書無しさん:2006/07/09(日) 23:48:22
>>151
バージョン管理で地獄見たから忠告してるんだろボケ茄子

153 :仕様書無しさん:2006/07/09(日) 23:48:40
EUCとSJISが混在してるとうざい。

154 :仕様書無しさん:2006/07/09(日) 23:49:24
>>152
はぁ?バックアップなら手動で十分だよね?
あくまで「バージョン管理を使わなきゃどうにもならない」理由なんだろうね?

155 :仕様書無しさん:2006/07/09(日) 23:50:28
>>152
っていうのはね。
そういううさんくさいものをもってきては自分の仕事にして
毎回それしかやらない奴がいるから。
それを実績にして仕事やったきになられると非常にむかつくんだよね。

156 :仕様書無しさん:2006/07/09(日) 23:50:45
一回サーバ構築してしまえば複数のプロジェクトも管理できるし
1,2日程度割り当てても損はしないと思うけどな〜
それ以上かかるようなら別対策立てればいいと思われ
まあ、バージョン管理が嫌いならそれは仕方ない

157 :仕様書無しさん:2006/07/09(日) 23:51:43
>>122が実際に起きて
客先はこちらに報告なしでそのバージョンを売ってた
でそのときの納入ソースだと言い張るCDがどう見ても何ヶ月かずれてる

まあきちんと取り決めをしてなかったのが悪いんだが

158 :仕様書無しさん:2006/07/09(日) 23:53:26
>>156
は?なんで3日もかかんの?
1ヶ月20日しかねぇのになんで3日も使うんだよ。死ねよ。
お前もおれんとこのプロジェクトにいる詐欺師といっしょだろ。

159 :仕様書無しさん:2006/07/09(日) 23:54:15
>>149 導入には3日。
メンバーにTortoiseSVNインスコさせて教えるのに1日。
あとは各自が毎日の作業でコミット。右クリックメニューから選ぶだけなので数秒〜数十秒程度。
まぁ一日に10回もコミットすれば多い方だから、せいぜいが2〜3分程度だな。

これが、バージョン管理を使わないとこう↓。おれなら一瞬たりとも迷わないけどなw

・バックアップ時の作業
フォルダのフルバックアップ
名前に日付を追加
バックアップ用のサーバーにコピー

・過去のソースの検証をする場合の手順
修正履歴を台帳から調べる
バグのあった日以前のバックアップを取得し、解凍
現在のソースをの変更部分を見比べながらバグの原因を修正(複数のソースならその分繰り返し)
このバージョンで問題が無ければさらに別の日のバックアップを取得して繰り返す


160 :仕様書無しさん:2006/07/09(日) 23:55:29
RCSで十分。CVSは糞。とうか、業務系にはむかない。
オプソで使われてるってだけの理由で新しもの好きのバカが音頭とって踊り出す

161 :仕様書無しさん:2006/07/09(日) 23:55:38
>>155
それは特殊な例だと思うんだ。
バージョン管理ツールに罪は無いよね?

162 :仕様書無しさん:2006/07/09(日) 23:56:38
>>159
なんだそりゃ、人増えるたびに教えるのに1日使うの?
3ヶ月のプロジェクトがあったとしてトータルで何日使う気?

163 :仕様書無しさん:2006/07/09(日) 23:58:54
>>161
でも、導入に3日、その管理でトータル1週間もかけられたんじゃ困るなぁ。

164 :仕様書無しさん:2006/07/09(日) 23:59:09
>>150-151
お前ら仲良くしろボケ

165 :仕様書無しさん:2006/07/09(日) 23:59:12
>>162
累積すれば毎日のタイムロスのほうがどう考えても大きいだろ
もうお前みたいな分からず屋は勝手にzipでバックアップとってろ

166 :仕様書無しさん:2006/07/10(月) 00:00:20
まあ、CVSマンセーな奴もエクリプス無しでは何も出来なかったり

167 :仕様書無しさん:2006/07/10(月) 00:00:29
>>162 最初に教えとけば、人が増えた時は仕事の引継ぎの一環でバージョン管理の使い方を教えるので(つーか出来ないと仕事にならない)通常のOJTの範囲内ですむ。
細かい事はみんな既存メンバーが使ってるの見て勝手に覚えるしな。
つーか、バージョン管理ぐらい出来ないようなゴミムシは、どうせ試用期間でクビなので問題なし。

168 :仕様書無しさん:2006/07/10(月) 00:02:47
>>167
はぁ?どうせそういう強引な理論になるならはじめっから意味ありそうにいうなよ。
どうせ、バージョン管理なんてたいして役に立ってねぇよ。

169 :仕様書無しさん:2006/07/10(月) 00:03:07
CVSって、シフトJIS使えたっけ?

170 :仕様書無しさん:2006/07/10(月) 00:05:43
結論は必要なしでok?

171 :仕様書無しさん:2006/07/10(月) 00:06:12
馬鹿には見えないツールでFA

172 :仕様書無しさん:2006/07/10(月) 00:06:22
バージョン管理ツールを使わないで、複数人で作業する場合、
他の人が作業した分の更新の確認とかマージとか、どうしてるの?


173 :仕様書無しさん:2006/07/10(月) 00:06:52
>>168
そりゃ、おまえんところの作りっぱなしプロジェクトならそうだろうよ。
そんなとこの引継ぎなんざやりたくねーがな。

174 :仕様書無しさん:2006/07/10(月) 00:07:30
>>172
してねぇだろ?w
そんなことw
重要でないことをさも重要そうにいうな。ボケ。

175 :仕様書無しさん:2006/07/10(月) 00:08:05
>>174
おまえ、しねw
この馬鹿

176 :仕様書無しさん:2006/07/10(月) 00:08:33
>>173
バージョン管理ツールがあると引継ぎが楽になるんだw
はじめて聞いたよw
あることないこと言い放題だなw

177 :仕様書無しさん:2006/07/10(月) 00:09:40
空気読まずに質問。
個人ユーザでも入れとくと便利なもの?
開発機がWindows機1台のみなんだがcvsとsvnってどっちがいいの?
外部に公開する気は無い環境で利用するつもりです。
どっちがどんな利点があるのかとかわかんないから入れたいけど入れれないorz

178 :仕様書無しさん:2006/07/10(月) 00:10:04
>>114
そういうプロジェクトだとライブラリアンとか言ってそれ専門の奴が1〜2名付くんだよ
障害管理と一体化されて管理される物なんだ

本リポジトリにはPGは触れないのが普通
テスト完了してコミットされたソースのみがバージョン管理される

最近はそういう管理工数も開発ツールのコストも要らないから削ってねとか言い出す馬鹿元請が多くて困る

179 :仕様書無しさん:2006/07/10(月) 00:10:04
>>170
うん、必要なしと思ってる人には必要なしでok

180 :仕様書無しさん:2006/07/10(月) 00:11:00
>>177
無条件で死ねw

181 :仕様書無しさん:2006/07/10(月) 00:11:38
嫌われる原因の一つにWinCVSの糞さと文字コードの問題がある。

182 :仕様書無しさん:2006/07/10(月) 00:12:00
>>177
TortoiseSVN
詳しくはぐぐれ

183 :仕様書無しさん:2006/07/10(月) 00:12:05
>>177
便利。
今からWindowsで使うならsvnがおすすめ。

184 :177:2006/07/10(月) 00:12:38
>>180
だが断る

185 :仕様書無しさん:2006/07/10(月) 00:12:46
>>174 は仕事してないの?

186 :仕様書無しさん:2006/07/10(月) 00:13:11
日本語の書籍があるかどうかだろ。

187 :仕様書無しさん:2006/07/10(月) 00:13:28
>>177 今からならSVNでおk。
とりあえずTortoiseSVNをいれて、適当なフォルダをリポジトリにして使ってみるといいと思うよ。
それで気に入れば使い続けりゃ良いんじゃね?

誰かがどっかで書いてたけど、日々の作業にアンドゥ機能がついた感じ。
失敗してもコミットしたとこまで戻せる安心感があるのは相当でかい。

188 :177:2006/07/10(月) 00:15:40
>>182,>>183
おk
ありがと。
挑戦してくる。

189 :仕様書無しさん:2006/07/10(月) 00:17:12
>>187
>失敗してもコミットしたとこまで戻せる安心感があるのは相当でかい。
重要でないことをさも重要であるかのようにいう奴が多くてやだね。

190 :仕様書無しさん:2006/07/10(月) 00:17:45
>>187
安心感はでかいね。おかげでざくざく先に進める。

191 :仕様書無しさん:2006/07/10(月) 00:17:56
>>177
ttp://tortoisesvn.bluegate.org/Help/dailyuseguide.html
↑TortoiseSVNユーザーズガイド(日本語)

ttp://tortoisesvn.sourceforge.net/downloads
↑本体はここから「TortoiseSVN-1.3.5.6804-svn-1.3.2.msi」ってのをダウンロード。
ついでに日本語LanguagePackも落としてきて、TortoseSVN入れた後にインスコすれば日本語化できる。


192 :仕様書無しさん:2006/07/10(月) 00:18:58
>>189 はトリップつけてみたら? (つけないでもだいたいわかるけど・・・)

193 :仕様書無しさん:2006/07/10(月) 00:20:28
tarballにしとけば確実に戻せる。

194 :仕様書無しさん:2006/07/10(月) 00:25:06
プログラマなら自分のコードぐらい覚えてるのが常識だよな。
いつでも自分の記憶を元に復旧できるのでバージョン管理なんて無駄。

195 :仕様書無しさん:2006/07/10(月) 00:25:28
>>192
君が付けたらそうしようか。

196 :仕様書無しさん:2006/07/10(月) 00:26:32
>>194
まあ、すくなくとも2週間以上前のソースに戻すことはないね。

197 :仕様書無しさん:2006/07/10(月) 00:26:52
いつどの様な理由でコミットしたのか台帳に書いてください。

198 :仕様書無しさん:2006/07/10(月) 00:28:19
>>197
そんなのバージョン管理ツール使ってたってコメントなんてつけねぇだろw
普段やらねぇことやってるようにいうな。ボケ。

199 :仕様書無しさん:2006/07/10(月) 00:28:41
コメント変えただけでコミットするバカがいてうんざり

200 :仕様書無しさん:2006/07/10(月) 00:33:30
バイナリを登録したら怒りだした管理者がいました。

201 :仕様書無しさん:2006/07/10(月) 00:33:57
>>199
javadocでエラーが出ててたらしょうがないな。

202 :仕様書無しさん:2006/07/10(月) 19:45:02
否定派:作業履歴が残るとまずい人
肯定派:履歴を次の作業に活用できる人

203 :仕様書無しさん:2006/07/10(月) 21:04:38
緑の人はなんでここまでスパークしていたんだろうかw

204 :仕様書無しさん:2006/07/10(月) 22:04:39
日曜だからじゃないの?

205 :仕様書無しさん:2006/07/10(月) 23:09:46
バージョン管理ツールを導入したら癌が治りました。おまけに彼女も
できるし給料もあがるし昇進するしで、もうえらいことです。

206 :仕様書無しさん:2006/07/11(火) 11:06:37
このスレを見ただけでも、バージョン管理を使ったことがない職場、
特に技術レベルの低い中堅PGがいるところで導入が進まないのが納得できるな。

言い訳しすぎ。使ってみてダメならやめればいいのにそれすらしない。だからデスマるんだよ。

207 :仕様書無しさん:2006/07/11(火) 11:19:13
全くなんでだろうね。
未知への恐怖?
自分の糞コードが記録されてしまうことに抵抗あるとか?


208 :仕様書無しさん:2006/07/11(火) 11:23:22
昔のはひどかったからな
途中でソースがなくなるとか普通に有ったよ

209 :仕様書無しさん:2006/07/11(火) 11:55:12
>>206に書いてる様な無意味に保守的な会社はコケてくれればそれでいい。
だだしそういうPGが書いたコメントアウトだらけのソースさえ
こちらに回ってこなければ。



210 :仕様書無しさん:2006/07/12(水) 00:02:55
ごめん。CVS、SVNは未だに使い方が良く分からん。
VSSは使ってるんだけど。

211 :仕様書無しさん:2006/07/12(水) 00:20:58
初めてVSS使ったのが大規模プロジェクトで、ソースアップするのに半日から一日がかり
VSSうぜーとか思ってたけど
十数人規模のプロジェクトに移ってからは便利だわ、これ

212 :仕様書無しさん:2006/07/12(水) 00:51:34
>>210
簡単に言えば、
CVS、SVNはソース自体の履歴管理のみだけど
VSSはそれに加えた競合管理の面が強い。
複数人で同じファイルを弄るならVSSが便利、
一人なら競合はないからCVSやSVNで充分。
だと思う。
チェックアウトして編集という概念以外は、考え方はあまり変わらないよ。

213 :仕様書無しさん:2006/07/12(水) 01:00:17
CVS、SVNも競合は管理してるでしょ

214 :仕様書無しさん:2006/07/12(水) 01:39:10
管理はしてる。解決するのは人間


215 :仕様書無しさん:2006/07/12(水) 10:42:10
それは逆。

ファイルのロックがベースという古い世代なのがV$$とRCS。

それに対してオプソ開発的にみんなが同時に編集できるようにしたのがCVS。
で、CVSではうpする前にサーバーの最新情報をローカルにチェックアウトしてからチェックイン。

216 :仕様書無しさん:2006/07/12(水) 21:44:40
>>215
マージが手動じゃ意味ねぇじゃんw

217 :仕様書無しさん:2006/07/12(水) 21:49:09
簡単な衝突ならSVN側で解決してくれるよ

218 :仕様書無しさん:2006/07/12(水) 22:14:27
ソースレベルでマージする必要がないように、分割コンパイルと、リンカ
やライブラリアンが存在するわけだろ。 なんで、「一杯のかけそば」
のように、複数で同一ソースを触んなきゃならんのよ。

C/C++なら、外部インターフェースを公開するためのヘッダファイルが
独立しているわけだし。いくらでも方法あるだろ。

>>217
> 簡単な衝突ならSVN側で解決してくれるよ

簡単な衝突かどうかの判断ロジック、SVN側で解決してくれる(くれた)か
どうかユーザー側が知るための方法の解説よろぴく。

219 :仕様書無しさん:2006/07/12(水) 22:21:16
>>216
バージョン管理という概念としては
ファイル更新が衝突するかどうかなんてのは、瑣末な問題でしかないんだろう。
マージが手動であっても、手動で解決できるなら問題ない。
バージョンはちゃんと管理できるんだから。


220 :仕様書無しさん:2006/07/12(水) 22:36:55
ソースのマージはうざいよな。
大体、デグレがおこるのはそこ。ヒューマンエラーが介入してしまう。

221 :仕様書無しさん:2006/07/12(水) 22:45:12
おみゃーらに習って入れてみた。けど、孤独は解決されん罠...orz

222 :仕様書無しさん:2006/07/12(水) 22:53:18
マージする時にCVSが全自動で仕様の妥当性チェックまでしてくれたら、マンセーするよw

223 :仕様書無しさん:2006/07/12(水) 22:55:02
おー、こんなレベルの低いスレがあるとは。
バージョン管理ツールってのはどこの会社も当たり前のように使っているものだと思ってた。

224 :仕様書無しさん:2006/07/12(水) 23:00:58
CVSでもロックを掛けることはできるし、
他人による変更を通知してもらうこともできる。

逆にVSSではロックを掛けることしかできない。

両方の使い方をちゃんと覚えてから議論しようね。坊や達。


225 :仕様書無しさん:2006/07/12(水) 23:04:58
修正前の行を全てコメント文で残しておけば、ファイルの一元管理ができるだろ?
メジャーで5回も改版されたソースは、スパゲッティどころの状態ではない。
もはや、ゲージツ品に値する。ああ、頭痛ぇーーー!

226 :仕様書無しさん:2006/07/12(水) 23:21:17
>>220
>大体、デグレがおこるのはそこ。ヒューマンエラーが介入してしまう。
なぁ。
自信満々でやった更新が履歴にも残らねぇ最悪の一手になる可能性があるよな。
だったら、そもそも触らせないようにしたほうがいいって。
その間作業が止まるなんつってもやっぱり、そこはソースを分割して作業できるようにしなかった
自分の頭の悪さを呪うべきだと思う。

227 :仕様書無しさん:2006/07/12(水) 23:30:59
コードの共同所有

228 :仕様書無しさん:2006/07/13(木) 00:00:13
>>226
ソースは分割して作業するからそもそも衝突が起こりにくい
でももし起こってしまった時の保険だろ

229 :仕様書無しさん:2006/07/13(木) 00:00:32
VSSみたいなチェックイン/チェックアウト方式だとデグレは発生しないの?
ソース管理を使わないほうがデグレが発生しないの? ちがうだろ。
バグの発生とバージョン管理は別の問題だと思うぞ。
かえって、マージのときにツールを使ってビジュアルに変更点を確認しながら修正する方がミスが少ないんじゃないだろうか。

まぁ、修正の時にマージツールだけを使えばいいんだけどさ。
バージョン管理してない奴って、ExamDiffとかWinMergeのような
比較/マージツールを使ってない(知らない)ケースが多いような希ガス


230 :仕様書無しさん:2006/07/13(木) 00:01:29
つxUnit

231 :仕様書無しさん:2006/07/13(木) 00:02:26
同じコンパイル単位でも別々の人間が同時に作業することはよくある
そういうときにVSSは大変使いにくい

232 :仕様書無しさん:2006/07/13(木) 00:03:21
>>229
TortoiseSVNには割と使いやすいマージツールが付属する罠

233 :仕様書無しさん:2006/07/13(木) 00:09:31
>>229
てか、同時進行で修正する機会なんてそう頻繁になんてねぇんだから、
マージなんてやらせるぐらいなら更新させないでほしいと俺は思うがな。
EclipseでもVisual化されてるけど差分意識して矢印ぽちぽちやってんの結構苦痛だ。

234 :仕様書無しさん:2006/07/13(木) 00:29:51
>>224
CVSのロックって、コミットをロックするだけで
ユーザが自分のマシン上で修正する事までは
ロックできないんじゃなかったっけ?
それはVSSのロックとはだいぶ違うと思うんだが。

>>229
VSSなら、チェックアウトするまでは
管理下の全ファイルは読み取り専用だから
ユーザ側で意図的に無理な更新をしない限り、
少なくとも更新の衝突によるデグレは発生しないと思うが。
デグレ発生原因の一つが減るのはそれだけで意味があると思う。

235 :仕様書無しさん:2006/07/13(木) 00:38:56
ロックする戦略の方がマージする戦略より昔からあった訳だが。

236 :仕様書無しさん:2006/07/13(木) 00:45:08
VSS使ってても、修正の時にチェックアウトせずに書き込み付加属性をはずして修正して、
修正終わったらチェックアウト→上書き→チェックイン するキチガイがたまにいるけどな。
ぶん殴ればよかったかも。

237 :仕様書無しさん:2006/07/13(木) 00:57:42
零細企業は大変ですね。

238 :仕様書無しさん:2006/07/13(木) 01:08:59
基本的な質問で申し訳ないのですが
ソースの書き方で気に入らないのがあって

for(hoge; fuga; hage)
    {

aho;
boke;
kasu;

  }

みたいな書き方を延々とする香具師がいるので
ソース清書することがあるのですが
こういうの(改変ではなくて清書だけの作業)を
バージョン管理するメリットはありますか?


239 :仕様書無しさん:2006/07/13(木) 01:10:05
そうして、元々書いた奴との熱いコミット合戦が。

240 :仕様書無しさん:2006/07/13(木) 01:12:37
>>234

cvs watch on 使ってもダメってこと?
正確にはロックとは違うけどかなり近いでしょ。

後はリポジトリをいじる権限があれば、
特定の権限者以外の permission を落とすというのも
場合によっては有効かもね。
FreeBSD ではリリース前はそんな感じだ。

まぁWindowsで閉じているのならVSSでもいいんじゃないかな。
VSS+SharePoint+Project の環境もちゃんと作れば
捨てたものではないよ。仕事じゃなかったら使わんけど。


241 :仕様書無しさん:2006/07/13(木) 01:16:14
>>238

それは commit 前にコード整形ツールのフィルタを置いておくと
お互い意識しなくていいんじゃないかな。

というか先にコーディング規約を決めておくべきだな。
Emacs だったら mode を定義しておくとか。


242 :仕様書無しさん:2006/07/13(木) 01:40:22
昔々、ある関数群を一人で担当するからといってそれを一つのファイルにまとめる、
というアフォーな決定をしたPM様がいらっしゃいました。
もちろん、共用モジュールでもないし、スーパークラスでもない、末端の処理なんだが。
じきに担当者の首が回らなくなりみんなで分担する事にしたのですが、
一人づつしか編集できないので、ーー以下略。

要は、VSSやらなんやらはあくまで道具であって、
使う人が基本的なプログラムの設計も出来ないとどうしようもないという事だ。
このスレ見てると、何はともあれVSS使っていれば大丈夫、みたいに考えてる現場いっぱいあるんだろうね。


243 :仕様書無しさん:2006/07/13(木) 01:49:52
ttp://www.banbanban.jp/zero/men.html
メンズZERO

激白!男のニオイ

*OLと思われる女性数人がテーブルを囲んで会話している。


女性A「男くさいっていうけど、ホントにあるんですよ。」

女性B「あれって汗のニオイなのかな−。」

女性C「清潔な人でも何となく感じる事あるんですよ。」

女性D「男だらけの会議室とか入ると、ウッとくるもんねー。」

女性E「男の人って気付いてないんですかねー。」


*場面が切り替わり、男性へインタビュー(?)

男性「全然気付かないですよ。男は。」


パソコンテレビGYAOで映画の途中に挿入されていたCMです。

この女性って顔にモザイク掛かっているけど、島田伸介を訴えたあのAさんじゃない?
知っている人いたら教えて!!


244 :仕様書無しさん:2006/07/13(木) 02:02:32
>>239 >>241

参考になりました。

本当にありがとうございました。


245 :仕様書無しさん:2006/07/13(木) 02:36:40
>>241 うむ。
SVNならprecommitフックにastyle(ttp://astyle.sourceforge.net/)実行スクリプトかまして
コミット時には強制的にプロジェクト標準のコーディングスタイルに
整形フォーマットすると幸せになれるかもしれんな。

246 :仕様書無しさん:2006/07/13(木) 06:19:16
こんなツールはどこの馬の骨かわからない人がよってたかってソースをいじり倒すオプソ用。

247 :仕様書無しさん:2006/07/13(木) 09:28:48
>216
>>215 マージが手動じゃ意味ねぇじゃんw

その通り。CVSでチェックアウトしたときローカルを生かしてサーバーの更新情報を反映する。

>234
>>224
>CVSのロックって、コミットをロックするだけで
>ユーザが自分のマシン上で修正する事までは
>ロックできないんじゃなかったっけ?
>それはVSSのロックとはだいぶ違うと思うんだが。

その通り。ローカルで自由に修正できるようにRCS(サーバーもローカルもロック)→CVSと進化した。
バージョン管理ツールがローカルを締め付けるなよ。実験も出来無いじゃん。

248 :仕様書無しさん:2006/07/13(木) 13:53:28
>>247
実験は本リポジトリに接続していないところでやる方が安全じゃないのか?


249 :仕様書無しさん:2006/07/13(木) 15:17:00
>>248
本リポジトリじゃないところにファイルコピーして?


ヴぁかじゃん、おまい。

CVSならサーバーとローカルとキッチリ切られてるから安心。

250 :仕様書無しさん:2006/07/13(木) 16:48:34
コミットしなけりゃ何してもOK
やばくなったら実験コードを捨てて直近のファイルをチェックアウトするだけ。


251 :仕様書無しさん:2006/07/13(木) 19:15:32
本データもいいけど、どうせなら、作った実験データも保存してほしいよね。
ラベルと日付付けて、「〜のテストしました。」とかって保存する機能ほしいね。
わずらわしい設定無しで右クリでラベル付けて「ポン」って感じでできないかな・・・。

それとこっちとそっちと二通りの組み方で迷ってるときに後でどっちにでも変えられるような機能ほしいね。

ここまでできないとバージョン管理も魅力無いな。

252 :仕様書無しさん:2006/07/13(木) 21:09:31
>>247
誰がいつ何をいじるかわからないオプソの世界なら
誰でも好きなときに弄って実験できる方がいいかもしれないが、
納期がある、順番どおり作っていく必要がある普通のプロジェクトで
好きなときに好きなように弄られても、困るだけじゃないか?

253 :仕様書無しさん:2006/07/13(木) 21:27:07
MS製品もOracle製品もCVSの登場するずっと前からあるよ。
おまいらの会社はそれらの製品よりはるかにソースの少ない少ない自称大規模プロジェクトの
業務系だろ。
CVSが無いと管理出来ないほど頭が悪いのか?

254 :仕様書無しさん:2006/07/13(木) 21:49:44
ディレクトリごとコピーとっときゃ良いんだよw

255 :仕様書無しさん:2006/07/13(木) 21:54:47
>>253
うん

256 :仕様書無しさん:2006/07/13(木) 21:56:44
>>251

ブランチ切ってタグ打てばいいんじゃないの?
魅力無いとか言う前に機能をちゃんと調べなさいよ。



257 :仕様書無しさん:2006/07/13(木) 22:01:17
>>253

そうなのか。

CVSは俺は1993年くらいからいまとほぼ同様の使い方で使い始めたんだけど、
初期のバージョンは1986年からあったみたいだね。

当時はMS製品もOracle製品も使ってなかったからな…
若輩者ですまん。


258 :仕様書無しさん:2006/07/13(木) 22:11:27
>>256
鬼門だと知って話題を振っている件について

259 :仕様書無しさん:2006/07/13(木) 23:04:48
right と correct の違いについて教えてください

260 :仕様書無しさん:2006/07/13(木) 23:17:06
>>259
まず、綴りが違います。

261 :仕様書無しさん:2006/07/13(木) 23:27:16
なるほど
ありがとうございました

262 :仕様書無しさん:2006/07/14(金) 00:46:43
>259
まず綴りが間違っています。

richtigとkorrektです。

263 :仕様書無しさん:2006/07/14(金) 05:10:07
WEBの世界にどっぷり浸かった
WEBエンジニア暦6年
CVSもVSSも利用したが、とりあえず。

2,3人でやる仕事なら、短期開発が多いので、ツールいらない。
むしろ邪魔。
5人以上集まってやばそうな奴いるなら管理する。
技術力の低い奴とかちょっと鬱入っちゃった奴とかいると、ツールが逆に邪魔になるケースもある。
ただ、「誰かが、古いバージョンに書き換えちゃった」な事件が一度おきたら、
そいつは何度もするからツール導入する。

264 :仕様書無しさん:2006/07/14(金) 05:12:14
追記で

DIFFコマンド+目視のが安全だったりしません?

265 :仕様書無しさん:2006/07/14(金) 07:31:18
もちろん

266 :仕様書無しさん:2006/07/14(金) 11:14:16
>>264
そんなんで追いかけられる程の規模ならな

267 :仕様書無しさん:2006/07/14(金) 13:10:14
バージョン管理の話だし、一日一回は更新するだろ?
一日 書けても1000行じゃないか?
きついとこなら200行書ければ良くない?
それくらいなら余裕でみれねえか?
意味わからんDIFFコマンドだから違う部分だけ出てくるからそこを追記して更新すりゃいいんじゃないの?


268 :仕様書無しさん:2006/07/14(金) 13:23:12
>>263
>2,3人でやる仕事なら、短期開発が多いので、ツールいらない。

どうやってソースの渡しあいをするのか不思議でならない。
たとえ1人でやる場合でも、ローカルディスクにCVS管理フォルダと実ソースと置いとけば完璧だけど。
CVSのインストールだけだし。

>DIFFコマンド+目視のが安全だったりしません?

本当そうですね。
WinCVSでチェックイン直前にDIFFツールで目視してますが、本当に安心。

269 :仕様書無しさん:2006/07/14(金) 14:36:22
>>267

一日一万行くらい書けますが何か?

270 :仕様書無しさん:2006/07/14(金) 17:18:26
分かり切っているものを打ち込む あるいはコピペなら。
もしくは無駄なウダウダ書いてる行数を計算に含めて良いなら。

271 :仕様書無しさん:2006/07/14(金) 19:22:04
>>268
>どうやってソースの渡しあいをするのか不思議でならない。
ツールばっかり使ってて馬鹿になったんじゃないの?w

272 :仕様書無しさん:2006/07/14(金) 21:30:43
バージョン管理?そんなの要らないだろ。共有フォルダをリリースの
タイミングでバックアップすれば良いんだよw

273 :仕様書無しさん:2006/07/15(土) 01:26:51
週末になって緑の人がまたキタ━━━━(゚∀゚)━━━━!!


274 :仕様書無しさん:2006/07/15(土) 02:17:17
>>273
最近、流れがよくわからなくて参戦してないんだけど?
俺はDIFFで比較すらしない。
そもそもソースがバッティングすること自体アフォ。

275 :仕様書無しさん:2006/07/15(土) 02:32:33
ま、痛い目あったことがないラッキーくんなんだろうな。。。
ネタだろうけどね

276 :仕様書無しさん:2006/07/15(土) 03:12:52
>>275
具体的に説明してくんね?
痛い目ってどういう目のことをいうの?
普通にサーバーが飛んでサーバーのデータが消えた程度のこと?
それだったら、個々のマシンではデータが残ってるから全滅はありえないんだけど?

277 :仕様書無しさん:2006/07/15(土) 03:36:22
リリースが今日と明日と明後日とあって
今日の分も100%の出来じゃないのにリリースしなきゃならないような状況とか

278 :仕様書無しさん:2006/07/15(土) 03:38:50
>>277
え?俺は痛い目がどういう目にあうことなのかを説明してくれっていったんだけど?
コミュニケーションあんまり得意じゃなかった?

279 :仕様書無しさん:2006/07/15(土) 03:54:11
喧嘩腰の人間にまともに答える人は、そういないよばかばかしい。
バージョン管理ツールは、ツール使う人のなかでも信者論争があるくらいだ。
平行線辿るだけだろう。

保守的な人間が工程変えたくなくて大きな声だしてるだけ。


280 :仕様書無しさん:2006/07/15(土) 05:29:03
進化を忘れた猿に道具の使い方を教えても無駄だってw

今時バージョン管理ツール使わないプロジェクトなんて極希だし、
「CVSなんて糞wwwww」とか言う猿は放置しとけばじきに絶滅するよw

問題は道具を間違って使う猿なんだ… orz

281 :仕様書無しさん:2006/07/15(土) 06:38:57
>>236
やるやるw
サーバーでいじっているファイルを見られるのが嫌でたまんない

282 :仕様書無しさん:2006/07/15(土) 07:47:25
>>279
自分が頭悪いのを俺のせいにしないでよw

283 :仕様書無しさん:2006/07/15(土) 10:26:21
そら、バージョン管理ツールの必要が無い人なんて、いくらでもいるだろ。
捨てコード書くのにバージョン管理するやつなんて、オナニーだろ。
痛い目くらい、ぐぐれば出てくるが、一つも例を挙げずに罵倒する自体、痛いヤツのすることじゃねーのか。

284 :仕様書無しさん:2006/07/15(土) 10:42:26
>>280
CVSなんて糞wwwww

てゆーか、昔のCVSで管理されてた糞案件全部subversionに移行したい…。
CVSじゃパッケージ移動とかの激しいリファクタリングがむずいんだよな。

285 :仕様書無しさん:2006/07/15(土) 10:51:44
>>283
こういう態度の人間にはなにいっても無駄じゃねーかとは思うけどな

286 :仕様書無しさん:2006/07/15(土) 12:06:30
バージョン管理ツールは無くても作業はできる。
(昔の人は実際使って無いんだし)
だが使いこなせば、ツールが人力でコツコツやった時以上の
仕事をこなしてくれるため、労力を減らせることは間違いない。
しかしながら、使いこなせるようになるには「学習コスト」が必要だ。
すなわち、
 ツールにより削減されるコスト>学習コスト
ならば使う意味はあるが、それ以外は使う意味が無いってことだ。
従って結論は、「学習能力の無い奴は使わんで良し。」

287 :仕様書無しさん:2006/07/15(土) 13:01:04
正直、バージョン管理なんて学習するほど難しいもんじゃないよな。

分からない奴は、使わない方がいい。というよりも、この業界から足洗って欲しいな。

288 :仕様書無しさん:2006/07/15(土) 14:40:07
豪快!共有フォルダ丸ごとバックアップ。これ最強。

289 :仕様書無しさん:2006/07/15(土) 20:51:04
>>288
それはそれで必要な事も有るぞ
月に1度はフルバックアップしたいよな

290 :仕様書無しさん:2006/07/15(土) 21:09:40
>>289
しかもバージョン管理ツールなしでやるのだ。

291 :仕様書無しさん:2006/07/15(土) 21:14:55
>>290
うん、それでいいんだよ。
もしかしてバージョン管理ツールを根本的に分かってない?

292 :仕様書無しさん:2006/07/15(土) 21:15:39
必要性ってか、絶対必要だろ。
前も、間違ってファイル消して、ソース書き直してるうんこがいた。
俺は個人の趣味でプログラムやるときだってSVN使ってるよ。

293 :仕様書無しさん:2006/07/15(土) 21:16:27
>>287
バージョン管理すらわからんやつが、どうやってコードを書くのだ・・・
マジで足洗って欲しいよな。

294 :仕様書無しさん:2006/07/15(土) 21:40:39
いや、コードを書くことはできるだろう。
問題は、作ったアプリを他人に使わせられるかとういうこと。
障害が起きたときに、提供時のソースが残っているかどうか・・・。

295 :仕様書無しさん:2006/07/15(土) 22:09:28
>>294
それで犯人探ししてその後どうするの?
もう、すでに担当者なんていないとかそうだったときなんの意味もないじゃん。

296 :仕様書無しさん:2006/07/15(土) 22:19:03
>>294
あー、バージョン管理がなくてもソースは書けるよ。
俺が言いたいのはバージョン管理システムの使い方もわからん奴が、
まともなコード書けるのかってこと。

297 :仕様書無しさん:2006/07/15(土) 22:30:41
バグだらけのCVSなんか使えんわ

298 :仕様書無しさん:2006/07/15(土) 22:31:24
一番よくあるトラブルとして、サーバーが吹き飛んでもバージョン管理のデータって復活できるの?

299 :仕様書無しさん:2006/07/15(土) 22:50:10
気楽に使える個人用CVSって無いのかな?
サーバとかじゃなくてSQLiteとかが埋め込まれてるだけのもの。
IDEのプロジェクト単位で標準で付けて欲しいのだが

300 :仕様書無しさん:2006/07/15(土) 22:53:39
Tortoise SVNなら気軽にローカルにリポジトリ作れるじゃん。

301 :仕様書無しさん:2006/07/15(土) 23:13:36
バージョン管理否定派てオブジェクト指向も出来なさそうな感じ

302 :仕様書無しさん:2006/07/15(土) 23:14:53
>>295
>それで犯人探ししてその後どうするの?
犯人探し?・・・馬鹿?
君、仕事でプログラムのサポートしたことないでしょ?

303 :仕様書無しさん:2006/07/15(土) 23:27:37
>>295
まず、問題の起きた場所を特定しそのソースは
いつ書かれた(変更された)ものかを突き止める。

そしてその時点のコミットログと差分を見てどの様な意図で
ソースが書かれたのかを突き止める。

担当者がいればそのコードの意図を問い合わせ(居なければ読み解き)
ソースを、本来の意図に沿ったコードに書き換えてコミットする。

と、言うわけでコミットログはみんな書いてくれよ。頼むから。

304 :仕様書無しさん:2006/07/15(土) 23:28:01
OOで思い出したが、Javaで同名クラス禁止のプロジェクトに関わったことがある
判断が微妙だが、被っていいのは他所のライブラリとだけみたいなのは普通?

305 :仕様書無しさん:2006/07/15(土) 23:45:57
>>295
提供先で障害が出たら、(運用のサポートは別途するとして)
開発担当がまずやるのはまず最初に現象出しだろう。

そのときに、提供時点のソースが残ってなかったら、
どうやって現象再現させるの?
まさか、最新のソースで同じ操作して現象がでなかったら、それでノープロブレムで、
最新版提供しておしまいとかいわないよね?

提供時のソースで現象出し->原因究明
->必要に応じてブランチ作成するなどして修正->顧客提供
->最新版ソースの開発が一段落するのを待ってブランチをマージ
・・・ 最低限、このぐらいの段取は必要なんでないの。

306 :仕様書無しさん:2006/07/15(土) 23:51:54
>>304
アプリケーション固有のクラスに関しては、
同一アプリ内で被らないほうがいいだろうね。

たとえば、ユースケースベースで開発する場合、
一つのユースケースに関連するクラスは、複数のパッケージにまたがってるから、
ユースケース単位のクラス図を描くときに、名前が被ってると、
ユースケースの設計をするときに、一つのクラス図の中に、
同じ名前のクラスが出てくることになる。
パッケージまで出せば、区別がつくけど、クラス図が不必要に複雑になる。

実際は、アプリケーション固有のクラスって、
役割がはっきりしている(汎用でない)から、
よほど名前が被る場合ってないんだけど。

307 :仕様書無しさん:2006/07/16(日) 00:09:45
はぁ?そんなのやってねぇよ。
ちなみに派遣で松下、富士通、日立、沖、東芝、NTTまわったけどどこもそんなことしてるところねぇよ。
妄想もいい加減にしろ。
やってないことをさもやっているように語るな。嘘吐き。
バグったら、バグってる箇所見つけて、修正してリリースするだけだ。
別に書いた奴の意図なんかしらねぇよ。
俺はただ、バグった箇所を修正するだけ。

308 :仕様書無しさん:2006/07/16(日) 00:24:35
>305
> そのときに、提供時点のソースが残ってなかったら、
> どうやって現象再現させるの?

それって丸ごとexe含めてバックアップした方が、安全確実だと思うけど?
このスレで「バージョン」管理って称してる内容って、つまるところファ
イルの変更履歴でしかないだろ?

問題は、バージョン管理ツールだけでは、ある時点のソースで何を変更したとか、
機能追加したとかって内容については、ソース内のコメントや別途ドキュメントを
残さない限り、記録してくれないことだわな。だから、DIFFとかでソースの差分を
取って、変更点を探し出さなきゃならんわけだ。

例えば、○月×日にリリースされたバイナリに不具合があって、その日に何回か
複数のソースがコミットされていたとしたら、exeのタイムスタンプを頼りに
VSSやCVSの履歴を1つずつ遡って差分を再生するわけ?

漏れは実行ファイルを含めて、フォルダ丸ごとバックアップして、圧縮ファイル
の名前を日付を入れたファイル名にして、保存している。Windows XPなら、ZIP
ファイルを展開しなくても、エクスプローラでそのまま中身を見れるし、圧縮も
フォルダの右クリック一発で終わり。変更履歴は、別途テキストファイルに自分で
決めたフォーマットで記録してあるので、客先にプログラムを送る際にも、その
一部を切り出してメール本文にコピペしている。

HDD容量のコストなんてゴミみたいなもんだから、手間をケチるなよ。
漏れは、ヤバそうな大幅変更を掛ける時は、1日でも数回バックアップを
作成するし、過去の履歴は全部専用のフォルダ作ってプロジェクトの終了
後も残してあるよ。


309 :仕様書無しさん:2006/07/16(日) 00:27:10
>>308(苦笑

310 :仕様書無しさん:2006/07/16(日) 00:28:51
>306
開発者毎に異なるネームスペースを使うとか、クラス名や関数名の頭に固有
の名称や文字を付けるように、あらかじめコーディングルールを決めておけば
よいのでは?

クラス名がかぶる心配以前に、腱鞘炎の心配をしているのかしらんが、クラス名や
関数名、グローバル変数名などを必要以上に短く省略する香具師がいるのは困り
物だな。

311 :仕様書無しさん:2006/07/16(日) 00:33:33
>>308
激しく同意。

312 :仕様書無しさん:2006/07/16(日) 00:33:42
変数名が有効なのは先頭の2文字

313 :仕様書無しさん:2006/07/16(日) 00:43:43
>>308 こりゃまた微笑ましいレスだなwww

314 :仕様書無しさん:2006/07/16(日) 00:46:02
緑が俺だけでないことを目視で確認。

315 :仕様書無しさん:2006/07/16(日) 00:50:17
>>308
あんたが言ってることって、ツールより手作業のほうが確実かつ効率的だって
言ってるのに等しいんじゃない?IT不要論者?

316 :仕様書無しさん:2006/07/16(日) 00:51:26
コミットログじゃ駄目なのか?

317 :仕様書無しさん:2006/07/16(日) 00:53:19
>>315
いや、ツール使っても大事なことはできないじゃない?
っていってるんじゃね?

318 :仕様書無しさん:2006/07/16(日) 00:56:41
>>308
そのケースに限定しすぎ。
たとえば一人でやってても、ここ3日なかったバグが出たら、
疑わしいところを前のバージョンとdiffとったりするけどな。
あと、たまにコミットログ読み返すのも趣味として楽しめるぞw

319 :仕様書無しさん:2006/07/16(日) 00:57:21
>>308
>それって丸ごとexe含めてバックアップした方が、安全確実だと思うけど?
微妙な話だな。
ビルドファイルは当然管理するんだけど。
しかし、同一ビルドファイルとソースファイルから同一の exe が出ない理由なんてあるんだろうか?

>例えば、○月×日にリリースされたバイナリに不具合があって、その日に何回か
>複数のソースがコミットされていたとしたら、exeのタイムスタンプを頼りに
>VSSやCVSの履歴を1つずつ遡って差分を再生するわけ?
いや、そんな面倒なことはしない。
リリースするバイナリを作るときに、そのビルドファイルで、バージョンタグを打っちゃう。
不具合があったときは、バージョン指定してチェックアウトすれば、その時点のソースが一式得られる。




320 :仕様書無しさん:2006/07/16(日) 00:58:45
>>317
なにができねーっていってるわけ?
リリースタグうったり、コミットログとばしたりじゃ足りないって?

321 :318:2006/07/16(日) 01:00:05
あと、俺はTortoise SVN使ってるんだけど、
エクスプローラーで見たときにコミットしてないのは
チェックマークが付くから、ああコミットしなきゃって気になる。
ただのバックアップだと怠りがち。
コミットの習慣=定期バックアップの習慣化でもある。
HDDは確かに腐るほど要領あるけど、
修正した差分だけをコミットする方が速い。
まるまるバックアップだと、やっぱ何分かかかるし、
どうってことないけど、やっぱりめんどかったりする。




322 :仕様書無しさん:2006/07/16(日) 01:02:31
>>310
>開発者毎に異なるネームスペースを使うとか、
それはどうやって結合するんですか?

>クラス名や関数名の頭に固有
>の名称や文字を付けるように、あらかじめコーディングルールを決めておけば
>よいのでは?
それは、「YamadaClassA」、「SuzukiClassA」とかを作って、
引継ぎの時はクラス名を全部変更するとかということですか?

>腱鞘炎の心配をしているのかしらんが
そうじゃなくて、クラス図が見難くなることとかを心配してる。
パッケージ名を出させるだけなら、ツールのプロパティちょっといじるだけだ。


323 :仕様書無しさん:2006/07/16(日) 01:02:48
図らずも否定派が馬鹿であることが証明されました

324 :仕様書無しさん:2006/07/16(日) 01:07:07
バージョン管理なんてやってるとこねーって意見もあるみたいだけど、
少なくともeclipseとかVSとか最近のIDE使ってるとこはほとんど入れてるんじゃね?
となると、バージョン管理ツール使ってるところが希少って意見は
ありえないし。
バージョン管理の有効性を各自が気にしてるかどうかは別にしてだが。

325 :仕様書無しさん:2006/07/16(日) 01:10:04
>>319
>不具合があったときは、バージョン指定してチェックアウトすれば、その時点のソースが一式得られる。
それって全部落としてくるの?
すげー長くね?
データもいっしょにバージョン管理にさせるとかなり時間かかんね?
まあ、どっちにしても、データベースの状態までは保存してないし、元に戻せないから、
手動にしても自動にしてもそんときの状態を一致させることはどっちにしろできないんだけどね。

326 :仕様書無しさん:2006/07/16(日) 01:11:38
>>324
確かにバージョン管理してないない奴は
未だにコマンドラインでコンパイル、デバッグはprintfがデフォだったりする。
要するに環境構築に手間かける時間<<<<さっさとコード書く
という風にしか頭がまわらないうんこ。

327 :仕様書無しさん:2006/07/16(日) 01:11:45
十秒もあれば完了だろ
ファイル探して解凍するほうが時間掛かる

328 :仕様書無しさん:2006/07/16(日) 01:12:08
サーバーが吹っ飛んだときにあまりにも無力だな。
どっちにしろ手動で一式保存する操作はバージョン管理を使ってても必要だな。
でもって、アクセスも頻繁で負荷も高いから一番よくあるしね。

329 :仕様書無しさん:2006/07/16(日) 01:13:40
>>327
無理だろ。
サーバーから差分だしてデータをコピーする時間は確実にかかる。
ソースはいいけどデータがでかい。

330 :仕様書無しさん:2006/07/16(日) 01:13:59
リポジトリのダンプ取るバッチ組んどけばいい話

331 :仕様書無しさん:2006/07/16(日) 01:15:47
>>330
つか普通そうするだろ。
サーバのバックアップの話とか、バージョン管理と何の関係があるのやら。。

332 :仕様書無しさん:2006/07/16(日) 01:16:46
>>325
データベースの状態まで保存していない?
テスト用のデータセットアップスクリプトとあわせて置いて置けば良いだけじゃないのか?
操作ログも取らずに思い立ったテストをだらだらやるやり方だからデータベースの状態が残せないんだよ

333 :仕様書無しさん:2006/07/16(日) 01:24:26
>>332
データベースなんてみんなが色々操作してるから中のデータなんてそれなりにめちゃくちゃになってるよ。
突然変更するとプログラムまで動かなくなってこまったもんですな。

334 :仕様書無しさん:2006/07/16(日) 01:27:54
じゃあそんなのバージョン管理しなきゃよくね?

335 :仕様書無しさん:2006/07/16(日) 01:29:42
なんにしろローカルで圧縮するくらいなら
バージョン管理に入れろって話になるね

336 :仕様書無しさん:2006/07/16(日) 01:30:55
>>334
でも、一番やってほしいのってこの辺じゃね?
実際はデータとプログラムがそろって動作するわけでさ。

337 :仕様書無しさん:2006/07/16(日) 01:37:09
>>335
まるごと保存で済むならバージョン管理なんていらないじゃん?

338 :仕様書無しさん:2006/07/16(日) 01:40:00
>>336
リグレッションテストと、その有効性と、それをやるためには何を管理しなきゃいけないか
を考えると、自ずと答えはでるんじゃね。
そんな偶発的なDBの状態をそのまま管理するのが果たして正解だと思うか?

339 :仕様書無しさん:2006/07/16(日) 01:41:41
>>338
いや、とりあえず理想はおいておいてプログラム動かすので精一杯だからw

340 :仕様書無しさん:2006/07/16(日) 01:43:36
だから、理想っつほどコストかかんねーっつうのよ。

341 :仕様書無しさん:2006/07/16(日) 01:47:13
共同作業じゃなけりゃバージョン管理ツールなんていらんだろ

342 :仕様書無しさん:2006/07/16(日) 01:49:41
だから、一度で良いから開発標準を頭に入れて来い
IDE上でステップ実行してる内はテスト工程に入っていないんだよ

343 :仕様書無しさん:2006/07/16(日) 01:49:53
いや、共同作業でも普通、作業の切り分けってのはできるもんでな。

344 :仕様書無しさん:2006/07/16(日) 01:50:39
>>342
毎回、それでリリースしてんのに、そういわれてもね。

345 :仕様書無しさん:2006/07/16(日) 01:52:07
バージョン管理ツールが要るか要らんかは、バージョン管理の必要が
あるかないかに依存する。
バージョン管理がいるかいらんかは、要件の複雑さと規模とバグがでたとき
客先に提出する紙をどこまで詳しく書かなくちゃいけないかに依存する。

346 :仕様書無しさん:2006/07/16(日) 01:54:25
>>345
そもそもちゃんと作業の切り分けができてれば、ソースがバッティングすることも
バージョン管理しなきゃならんほどのバグもでないでしょうよ。
って議論はしないんだね?

347 :仕様書無しさん:2006/07/16(日) 01:54:35
>>343
まずソースコードの共同所有あたりでググってこいや。

348 :仕様書無しさん:2006/07/16(日) 01:55:44
つか、要らねって人は収入低い仕事してる人だと思うな。
普通、要るだろ。おれはさっき書いたコードも三歩歩けば忘れるよ。

349 :仕様書無しさん:2006/07/16(日) 01:56:48
>>347
だから、関係ないって。

350 :仕様書無しさん:2006/07/16(日) 01:57:55
>>348
はいはい、都合の悪いレス>>307は見ないんだねw


351 :仕様書無しさん:2006/07/16(日) 01:58:31
バージョン管理すら使えない奴って、言語も一つだけしかできないんだろうな。
しかもオブジェクト指向も出来てないとおもう。

だって言い訳しかしねーもんw構造化プログラミングで十分とかC言語があれば他は不要とか言うんだろなwww憐れよのぅ

352 :仕様書無しさん:2006/07/16(日) 02:03:21
>>349
関係おおありだよ。
今日日の開発は、ソース単位で作業を切り分けられねーんだよ。

353 :仕様書無しさん:2006/07/16(日) 02:04:12
>>351
だって面倒くせぇんだもん。
そりゃ全部のソースが団子みたいに丸まってるなら一括管理のほうがいいけど。
折角分かれてるもんをわざわざバージョン管理に突っ込むこともねぇし。

354 :仕様書無しさん:2006/07/16(日) 02:05:30
このスレ盛り上げてるヤツって、釣りうまいよな

355 :仕様書無しさん:2006/07/16(日) 02:14:00
>>353
昔ながらの構造化プログラミングだったら、機能毎に分割されたソースをに各担当者
に割り振ることができた。
だけどそういうやり方だと各ソースに暗黙の依存関係みたいのが出来てきて、ひとつの
ソースを修正しようとすると、関係しそうなソースを全部眺めてみる必要が出てきて
しまいに請求できない間接稼動みたいのが山ほど増えて全然利益にならなくなる。

356 :仕様書無しさん:2006/07/16(日) 02:24:02
いざってときに1つのソースを二人でいじる、
それがちょちょーいと出来るのが最近いいな〜って思ったな。
同時に編集してても自動マージしてくれるし、
ミスってもすぐロールバックできるしな。

かくゆうオレは alienbrain ユーザです。希少よね・・・。

357 :仕様書無しさん:2006/07/16(日) 02:43:41
>>355
はぁ?
プログラムの基本は分割だ。
お前のは新しいとか古いとかじゃない。下手糞なだけだw

その証拠に

>だけどそういうやり方だと各ソースに暗黙の依存関係みたいのが出来てきて、ひとつの

 意 味 が わ か り ま せ ん ! (笑)

358 :!355:2006/07/16(日) 03:05:02
>>357
なんで意味がわかんないのかわかんないな。
ファイル間・・・つまりはクラスや構造体同士の依存が起こるって話じゃないの?


359 :仕様書無しさん:2006/07/16(日) 03:17:51
>>358
で?昔と今でどう違うの?

360 :仕様書無しさん:2006/07/16(日) 03:22:11
長々とまぁよくつづくねぇ…

いいじゃねぇか?「必要なら使う」「不要なら使わない」で。

老害が仕切るProjectで採用されてないのは事実だろうし、
それが無駄な手作業を強いてるのも確かだが、認めないヤツは認めないな。

まぁついで。
>307
> ちなみに派遣で松下、富士通、日立、沖、東芝、NTTまわったけどどこもそんなことしてるところねぇよ。
ダウト。10年近く前だが、富士通、NTTで使った。
今はCanonで使ってる。


361 :仕様書無しさん:2006/07/16(日) 03:24:35
>>360
はぁ?俺が言ってるのは

バグがでてもバグった箇所を修正する以上のことはどの会社でもやってない。

ってことなんだけど。

362 :!355:2006/07/16(日) 03:24:42
>>359
ああ、いまも昔も変わらないよねってツッコミだったの?
ごめんね行間読めなくて。


363 :仕様書無しさん:2006/07/16(日) 03:29:33
>>362
いや、俺がいいたいのは>>355の発言の

1 >昔ながらの構造化プログラミングだったら、機能毎に分割されたソースをに各担当者
2 >に割り振ることができた。
3 >だけどそういうやり方だと各ソースに暗黙の依存関係みたいのが出来てきて、ひとつの
4 >ソースを修正しようとすると、関係しそうなソースを全部眺めてみる必要が出てきて
5 >しまいに請求できない間接稼動みたいのが山ほど増えて全然利益にならなくなる。

機能毎に分割されたソースを各担当者に割り振るやり方だと各ソースに暗黙の依存関係みたいのが出来て〜

とかいう箇所。
これだと今と昔でやり方が違うみたいなこといってるよねぇ?
いまだと機能毎にソースってわけないもんなの?
クラスや関数なんて分けるための技術であるにもかかわらず>>355のいうことっておかしいよねぇ?

って話。
馬鹿でもわかると思うけど>>355はプログラマなんて名乗るに値しないクズ技術者。

364 :仕様書無しさん:2006/07/16(日) 03:31:25
>307
漏れの経験だと…
目立では確かに使ってなかったが、
IB○とデン○ーは使ってたYO!

365 :仕様書無しさん:2006/07/16(日) 03:39:24
>>361
君、そろそろ飽きたんで別のネタにしてくれるかな?

366 :仕様書無しさん:2006/07/16(日) 03:41:23
>>365
はぁ。じゃあ、適当なの振ってください。
1ついっておくと、君の振る話題は面白くないから私に話題をとられてしまうんですw

あ、そもそもレスがつきませんでしたっけ?w

367 :仕様書無しさん:2006/07/16(日) 03:51:16
正直さ
超大規模プロジェクト=>利用してもいい
ベンチャーの人入れ替わりまくる会社=>利用すべき
受託開発会社=>品質を保つ為利用してもいい(客先がコストダウンしろいうなら利用しないほうがいい)
その他=>好きにしろ
てか同じソース同時に弄る可能性のある振り方するな。大規模ならしょうがないが。
でも品質維持の為に利用する分にはいいんでない?

368 :仕様書無しさん:2006/07/16(日) 03:51:28
流れをぶった切って ヌル(・ω・)ポリーン 参上!

369 :仕様書無しさん:2006/07/16(日) 04:23:51
>>367
同じソースを複数人数がいじるのは、
後輩が書いたソースを先輩が直して、コメント書いておいて勉強させるとか、
プログラマの技術交流的にもやってもいいかなって思う

まあ同じソースのさらに同じ箇所を一緒に書くなんてことは
まずないと思うんで、自動マージが優秀ならイケルよ

370 :仕様書無しさん:2006/07/16(日) 04:34:30
>363
>クラスや関数なんて分けるための技術であるにもかかわらず>>355のいうことっておかしいよねぇ?

いや、少なくとも(分担するために)分ける技術では無いだろ。

まさかアンタの所じゃ、分担する事を目的として関数・クラスを設計してると?

371 :仕様書無しさん:2006/07/16(日) 07:33:31
>>370
なに、話すり替えようと必死なのw
もう、君がただの馬鹿なのは明白なんだよ。
その辺で黙っとけw

372 :仕様書無しさん:2006/07/16(日) 08:32:24
>>339
新しい道具を試す余裕もない仕事をしてるんだね
バージョン管理以前に一度立ち止まって考えてみるべきだな

373 :仕様書無しさん:2006/07/16(日) 10:05:06
このスレを読んでいて、バージョン管理ツール導入しただけで、バージョン
管理したつもりになってるクソ会社ばかりなのがよく判った。○○でも使って
いるから、ウチも導入しましょうってか?

リリース時点でバージョン番号振ったら、バージョン管理か?おめでてぇな。
で、そんな便利なツールを導入しても、程度の低いバグが一向に解消しない
のはなぜなんだい?使う道具を変えるだけで、ソフトの品質や効率が上がる
なら、世話ない。

374 :仕様書無しさん:2006/07/16(日) 10:09:45
というか、ここで議論されてるのはもっとレベルの低い
バージョン管理システムが必要がどうかって話だ。
必要って事に異論を唱えること自体信じられん・・・

375 :仕様書無しさん:2006/07/16(日) 10:19:28
否定はしないが、ここのスレでバージョン管理ツールの必要性を唱えている
プログラマ連中のレベルなら、あってもなくても成果物の品質に大差ない
(品質はとても低い)と思う。猫に小判、豚に真珠。



376 :仕様書無しさん:2006/07/16(日) 10:27:16
一番使えんのは、あれこれツールを試したとか言うけど、いざ実際に使わ
せてみると雑誌の照会記事の追検証やったことがあるレベルで、とても道具
として使いこなせていないケース。アミバ以下のレベル。

大規模プロジェクトでバージョン管理ツールが必要とか言ってる香具師に
聞きたいんだが、何を以って「大規模プロジェクト」と称しているんだ?
プロジェクトの投入人数?ソフトが扱うデータの量?コード量?

大規模プロジェクトのプログラムって、機能別にDLL化とかしないで、一本
野グソみたいに1つのexeで構成されてんの?

377 :仕様書無しさん:2006/07/16(日) 10:39:12
ゲーム屋だと、その一本グソを作ることになる=バージョン管理必須

378 :仕様書無しさん:2006/07/16(日) 10:47:35
コンシューマ系?PC系?いくらゲームでもイマドキ一本ってことはないと
思うが?もしかして、同人系?

379 :仕様書無しさん:2006/07/16(日) 10:51:24
コンシューマー。普通に一本グソだよ。

380 :355:2006/07/16(日) 11:20:57
>>363
クラスは機能毎にファイルわけてねーだろ。
当然データごとに分ける。

381 :仕様書無しさん:2006/07/16(日) 11:23:40
当然か?

382 :355:2006/07/16(日) 11:30:36
本当は当然でも無い。
意識してそうしないとならない。

構造体みてーなクラスつくって、呼び出し側の(機能を具象化する)クラスがそれを
つっつきまわすようなクラス構成を良く見かける。
だけどそれだと>>355で書いた状況と何も変わらないし、当然その状態が正しいとも思わない。

383 :仕様書無しさん:2006/07/16(日) 11:47:55
いや、でも、BCEモデルってそんな感じじゃね?

384 :仕様書無しさん:2006/07/16(日) 11:49:26
>>376
大規模プロジェクトがバージョン管理ツールを導入する必要条件って
わけじゃないんだから大規模プロジェクトの定義なんてしても
しょうがねーだろ。

>大規模プロジェクトのプログラムって、機能別にDLL化とかしないで、一本
>野グソみたいに1つのexeで構成されてんの?
DLL化してたらなんなの?なおさらバージョン管理(つか、それ含む構成管理)
する必要があるんじゃないの?

385 :355:2006/07/16(日) 11:55:40
>>383
と思ってる奴も多いと思う。
まずはここ読んでみてくれ。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

386 :仕様書無しさん:2006/07/16(日) 12:01:51
>>385
自分の理解では、その記事は、
MVC における、Cにビジネスロジックを書くことが問題だといっているような気がするんだけど。
BCE の CE って MVC の Mでしょ?
つまり、BCEのCにビジネスロジック書くのは、MVCでいえば、Mにビジネスロジックを書くことで、
その記事の内容と矛盾しない。

387 :355:2006/07/16(日) 12:37:08
>>386
MVCのCはBCEのB(の一部)だべ。
よって記事の内容は、BCEのBにビジネスロジック書くのが問題だっていってる。

388 :仕様書無しさん:2006/07/16(日) 12:56:43
分割するとかしないとかあんまり関係ないだろ
構成管理をツールで楽をするかしないかだけの話じゃないか

389 :仕様書無しさん:2006/07/16(日) 13:02:09
> DLL化してたらなんなの?なおさらバージョン管理(つか、それ含む構成管理)
> する必要があるんじゃないの?

ここまで言う >>384 のことだ。 サービスパックやセキュリティアップ
デートを適用したらシステムDLLが変更される可能性があるので、 プロジェ
クトが依存関係にあるシステムDLLやレジストリ設定を含めて、スナップ
ショットをバージョン管理ツールに登録していることだろう。(反語)

390 :仕様書無しさん:2006/07/16(日) 13:17:55
おまいら飽きねえなぁ…よく続くよ。
これだけ説明しても必要性がわからないってのは
老害か、本当にバージョン管理の必要性を感じない”ユウシュウナPG”なんだろ。
(もっとも、賢明な人は普通使ってるもんだが)
あるいは必要性のない程の小規模プロジェクトでも有り得るか。

じゃ、ひとつ実例を出しておくか。
マルチプラットフォームライブラリをコアに、
各プラットフォームで複数のプロジェクトが進行。
それと同時にライブラリ自身にも各種実験的な試みが複数平行して行われることもザラ。
直接コードに触る人数は20人〜30人以上ってとこ。
コード総量は20万行程度で200MB以上(データ含む)。ブランチ多数。

バージョン管理否定派はこれをどうやって管理するつもりなんだろうねぇ?


391 :仕様書無しさん:2006/07/16(日) 13:32:22
390の補足。
>あるいは必要性のない程の小規模プロジェクトでも有り得るか。
これは1〜2日から1週間程度で書き上がるの書き捨てコードってことな。

こんなもん(だいたい5k〜100k step程度、クラス数30未満程度か)なら
まぁバージョン管理しないでもいけるな。書き捨てだし。

が、以後機能追加を求められるようなものであれば2k stepでもバージョン管理してる。
そういう話。

392 :仕様書無しさん:2006/07/16(日) 14:34:44
ばかだな。COBOLで基幹系の大規模開発にはCSVなんかつかわねえぞ

393 :仕様書無しさん:2006/07/16(日) 14:41:37
たかだか20万行のコードを20〜30人で触るプロジェクトって、多めに見積って
も、1人あたり1万行ってことだよな。その1万行のアウトプットに何ヶ月掛け
るわけ?要件定義や設計から含めると、のべ工数見積りはざっと200〜300人月
といったところか?そりゃ、工数だけ見ればたいそうな大規模プロジェクトだ。

本チャンコードで使うライブラリで実験的な試みって、おめでてぇな。モジュ
ール単位の機能テストくらい、テスト用のプロジェクト起こして、最小コードで
動作確認してからマージするのが礼儀ってもんだぜ。

理解できない香具師がいるようなので、もう一度言っておくが、バージョン
管理ツールを導入しても、ツールは、バージョン管理の方法を提供している
に過ぎない。

10万ステップでバージョン管理が不要で、20万行程度なら必要って根拠も
判らん。そもそも、>>390>>391 が1週間で1万行すらもコードを書いた
実績があるとも思えんな。

394 :仕様書無しさん:2006/07/16(日) 14:43:55
>>390
てか、そういう前提がありえない。
さすがにそれを1本糞で組んでる状況ってのがあまりにも下手糞過ぎて笑える。
そんなに人数がおおけりゃライブラリみたいな形に分割することになるって。
分割すれば、全体で20〜30であっても個別の機能でみれば5〜6人程度におさまってしまう。
この人数であればバージョン管理はあってもなくても別にかまわない。
まず、この切り分けが出来てないような環境のほうが俺は信じられねぇよ。

395 :仕様書無しさん:2006/07/16(日) 15:12:04
工場勤務の組込ドカタが紛れ込んできたようだ。

396 :仕様書無しさん:2006/07/16(日) 15:34:59
>394
390は「マルチプラットホームライブラリをコアに」云々と言ってる。
またライブラリ自身も弄ってると言っている。
従って最低3チームには分割されているはず。
それ位読み取りなよ。

397 :仕様書無しさん:2006/07/16(日) 15:36:01
>>396
じゃあ、20〜30ってのは嘘なんだよね?

398 :仕様書無しさん:2006/07/16(日) 15:40:00
>392
使えない環境があるのは認める。てか基幹系業務コードに適用するバージョン管理ツールの存在を俺はしらん。
識者がいたら教えてくれ。

>393
>たかだか20万行のコード
まぁこれはtrunkの量だな。何個もあるブランチ合わせていくつになるかはやったことないんでシラネ。
ついでにこれは何年も続いてるプロジェクトで、年単位で成果を求められてる。

>本チャンコードで使うライブラリで実験的な試みって、おめでてぇな。
だからブランチ切ってるっつてるべ?
その実験結果が有用ならtrunkにマージするだけだ。試験期間も数ヶ月あるしな。

> 最小コードで動作確認してからマージするのが礼儀ってもんだぜ。
誰もそれをしねぇとは言ってねぇ。っつーかその最小コードの規模がそれなりにあるんだよ。

>10万ステップでバージョン管理が不要で、
これは俺が1週間で一気に書き上げた経験から。こんときは書き捨てだったからいらなかっただけ。
肝心なのは「一人が1週間程度で書き上がる書き捨てコード」ってこと。こんなもんにバージョン管理なんていらん。

> 20万行程度なら必要って根拠も判らん
こっちは長期で複数部署の複数人が触るコードだからな。バージョン管理してねぇと誰が何したか管理なんてできねぇ。
#コミットログをちゃんと書かない馬鹿も存在かもしれんが、それはツール使わなくても同じ事するから除外

>394
> そんなに人数がおおけりゃライブラリみたいな形に分割することになるって。
とっくに複数のサブコンポーネントに別れてる。各コンポーネントの担当者はおっしゃるとおり5人前後だな。
だがマルチプラットフォームの都合上、よその担当部に手を入れざるを得ないこともある。

> この人数であればバージョン管理はあってもなくても別にかまわない。
人数だけの問題ならば、なくても構わないことはあるだろうな。が、誰もそんなことは言ってねぇし。


399 :仕様書無しさん:2006/07/16(日) 15:42:25
>>398
>担当者はおっしゃるとおり5人前後だな
じゃあ、もう、話の前提が崩れてるからこの話は終ね。
それは20〜30とは表現しない。

400 :仕様書無しさん:2006/07/16(日) 15:44:46
>>399
だーかーらー。
各々のサブコンポーネントがそこまで独立してねぇんだよ。
コアやミドルのコンポーネントを利用するコンポーネントが複数あるんだって。
その上に実験コードなりそれらのマージなりがあるんだから、
手作業なんかでやってたら時間がいくらあっても足りネェっつーの。

401 :仕様書無しさん:2006/07/16(日) 15:47:03
てかさ、
手作業でコピーして更新履歴書いて定期的に圧縮してバックアップとってってのと、
ツールで差分コピーしてcommitログ書いて定期的にリボジトリバックアップとる作業に
どれだけの違いがあるんだ?
それ以外にも履歴参照なりタグ打つなり排他制御なりマージをツールが助けてくれるのに、
なぜ使わないんだ?
否定派の主張はそこんとこがわかんねぇ。

402 :仕様書無しさん:2006/07/16(日) 15:48:17
>>400
それをバージョン管理で解決しようとしてるところがすでにウンコっしょ?
なんかバージョン管理云々関係ない気が自分でもしてない?
してなかったらかなり重症だと思うぜw

403 :仕様書無しさん:2006/07/16(日) 15:49:23
つうか、それってコンポーネント間の独立性が糞で依存性があるからそんなことになるんでしょう?

404 :仕様書無しさん:2006/07/16(日) 15:49:24
>>401
>どれだけの違いがあるんだ?
大して違わないな。
じゃあ、使わなくてもいいよね?

405 :仕様書無しさん:2006/07/16(日) 15:50:17
設計が糞なだけじゃんwwwww

406 :仕様書無しさん:2006/07/16(日) 15:50:43
この不毛な論争はいつまで続くのだろうか
使いたきゃ使えば良いし、使いたくねえなら使わなかったらいいだけなのに

407 :仕様書無しさん:2006/07/16(日) 15:52:12
>402
バージョン管理ツールを、バージョン管理にしか利用できない君がウンコ。

#どちらかっつーと同期を取るために存在するモンだと思われ。

408 :仕様書無しさん:2006/07/16(日) 15:52:18
そんなものはコンポーネントとかミドルウェアとはいいませぬ。

409 :仕様書無しさん:2006/07/16(日) 15:53:29
>>407
ついにフォークでラーメンを食えといいだしたかw

410 :仕様書無しさん:2006/07/16(日) 15:58:51
Java厨にミドルの設計は無理。
終了。

411 :仕様書無しさん:2006/07/16(日) 16:03:19
なんだ。こちらにもおじゃばさまが降臨しているのかwww

412 :仕様書無しさん:2006/07/16(日) 16:11:12
ライブラリと、それを利用する 「複数の」 アプリを
複数人で平行して開発しようと思ったら、
バージョン管理ツール無しだと、ライブラリへの変更が
相当不自由になるか、破綻するかだと思うのですが。

そもそもライブラリを共有しようってのが間違い?

413 :仕様書無しさん:2006/07/16(日) 16:20:06
>>412
関係ないんじゃない?
すくなくともライブラリの版数を上げたモンを適用しなきゃいけないわけだし、
そんときにソースなりlibなりdllなりもらえばいい話だし。

414 :仕様書無しさん:2006/07/16(日) 16:24:04
古いライブラリ限定のアプリとか開発するの?

415 :仕様書無しさん:2006/07/16(日) 16:24:45
ライブラリのテスト・デバッグとリリース機構に欠点があると見た。

416 :仕様書無しさん:2006/07/16(日) 16:29:04
結合度が高い設計しかできないJava厨には無理。

417 :仕様書無しさん:2006/07/16(日) 16:32:04
あれだな、Javaの奴らってみな共通する特徴がある。

Javaはすごいよ最高のオブジェクト指向だ。、Java駄目って言う馬鹿は年寄りとかいうんだ。
それは良いとして、彼らの作ったクラスを再利用しようとすると
シンプルなmainだけのサンプルではとりあえず動くんだな。
しかしクラス間の結合関係がでてくるとあーらふしぎ。
コンパイル->エラー;エラー;エラー;エラー;エラー;エラー;
エラー;エラー;エラー;エラー;エラー;エラー;エラー;エラー;
エラー;エラー;エラー;エラー;エラー;エラー;エラー;エラー;
エラー;エラー;エラー;エラー;エラー;エラー;エラー;エラー;
エラー;エラー;エラー;エラー;エラー;エラー;エラー;エラー;
エラー;エラー;エラー;エラー;エラー;エラー;エラー;エラー;
エラー;エラー;エラー;エラー;エラー;エラー;エラー;エラー;
エラー;エラー;エラー;エラー;エラー;エラー;エラー;エラー;
大量のエラーでコンパイラが中断されました。となっちゃうんだな。


418 :仕様書無しさん:2006/07/16(日) 16:47:36
>>404
>>>401
>>どれだけの違いがあるんだ?
>大して違わないな。
じゃあ使ってもいいんだよな。
手作業に比べてヒューマンエラーの介入する余地の少ない、バージョン管理ツールをな。
わざわざ間違いを犯しやすい方法を選択する、その根拠を教えて貰えないかな?

419 :仕様書無しさん:2006/07/16(日) 16:56:49
Javaの場合はさらにJDKのバージョンとかTomcatのヴァージョンとかStrutsのバージョンとかあって、
その組み合わせが無限大に。

420 :仕様書無しさん:2006/07/16(日) 17:02:02
Java厨のCVS厨って、eclipseが無ければチェックアウトすら出来そうに無いな。

421 :仕様書無しさん:2006/07/16(日) 17:05:07
>>417
どんな使い方してるんだ?能無しアピールされても煽りにはならないって。

422 :http://ura2ch.s6.x-beat.com/ :2006/07/16(日) 17:11:51
ura2ch ura2ch

423 :仕様書無しさん:2006/07/16(日) 18:20:04
発注元(某大手キャリア)から、品質ISOの必要性からツールを
導入して欲しいと言われたことがある。
ソース管理が適切に行われていることのエビデンス(証拠)が
必要だからだそうだ。
ツールにはそういう側面もあるんじゃないの?

424 :仕様書無しさん:2006/07/16(日) 18:26:28
マージ作業程度で間違いを犯すようなら、プロジェクトから抜けてもらった
方がいい。

というか、分割コンパイルと、リンカがあるのに、なんでわざわざソースを
マージしなければならんのかが理解不能。

インポートライブラリとヘッダファイルだけでインターフェースが取れない
ダイナミックリンクライブラリの作り方もぜひ教えて欲しいものだ。

425 :仕様書無しさん:2006/07/16(日) 18:27:19
大規模がバージョン管理必要と論じてるものだけど
DLL可されていたりモジュール分けもされてるし、
ってのも踏まえた上で
1本のモジュールが長いのでチーム単位で1本のモジュール担当したりするじゃない。
多分想像してる規模の大きさが違うんだと思うけどね。
まあ1チーム1本で作業が進むからあったほうがいい。
でも優秀なPMが付いていればそうはならない。
必要ないケースもある。人によってはバージョン管理ツールが大きな障害となる場合もある。
なんでもかんでもバージョン管理するのは間違い。

426 :仕様書無しさん:2006/07/16(日) 18:35:40
分割されたモジュールが一本グソなわけ?モジュールつぅても、複数の
クラスや関数で構成されていて、ソースはクラスや機能単位で分割されて
いるのが普通だと思うが違うのか?

バージョン管理ツールを導入しているからバージョン管理してますって言い
訳は、定期的に担当者に報告書を提出させているから、プロジェクトの管理
は順調ですって言ってるようなもんで、手段が目的になっちゃってる典型
だな。


427 :仕様書無しさん:2006/07/16(日) 18:37:38
>>424
>マージ作業程度で間違いを犯すようなら、プロジェクトから抜けてもらった
方がいい。

全てのPGがそんな間違いを犯さないのであれば、
そもそもソース管理ツールなんて開発されないと思う。
それに、言うほど単純な作業であれば、むしろツールに任せて
もっと生産的な作業に時間を割り振ればいいんじゃないの?

428 :仕様書無しさん:2006/07/16(日) 18:43:44
>>398
> >10万ステップでバージョン管理が不要で、
> これは俺が1週間で一気に書き上げた経験から。
> こんときは書き捨てだったからいらなかっただけ。

ステップ数の数え方はまちまちだが、漏れは、ドキュメント作成や詳細仕様
の検討、テスト実行を並行でやって最高でも1000行/日くらいだな。実際、
いくつか過去の実績を調べても、5万行くらいのアプリ開発に要した期間が
3〜4ヶ月で、これでもかなり開発は速い方だと思うが、10万行のソースを
たった1週間でねぇ。

429 :仕様書無しさん:2006/07/16(日) 18:47:20
>424みたいな
「何を言っても自分の認識外の事象があることを認めない」人種には
何を言っても無駄。

「世の中は全て理想通りであり、またそうあるべきである。
そうならないのは個人の力量不足」としか応えない。

世の中には様々なレベルの人間が居て、使い物にならないような人材もざら。
マネージャーはそういう連中が割り振られても仕事を完遂できるように努力しなければならに義務がある。

「普通はこうだろ?できねぇのは理解不能」と切り捨てて
リスクマネジメントの意識すらないような人間ってのは
人を使うことができない=一生ドカタ仕事しかできない人間だよ。

こういう老害が一掃されれば、もうすこし業界もよくなるんだがな…

430 :仕様書無しさん:2006/07/16(日) 18:51:28
偽装派遣が専門のエンジニア売買会社からキックバックを受け取っている
現場マネージャーさんでつか?

使い物にならない人間がバージョン管理ツールで使い物になって、プロジェ
クトが成功するんだったら、どんどん未経験者を投入すりゃいいんじゃん。

アンタの懐もさぞかし潤うだろうよ。(w

431 :仕様書無しさん:2006/07/16(日) 18:53:24
>>428
1週間=7日と多めに考え、15h/day程度だったとして1000 step/hだな。
1週間=5日で15h/dayでも1500 step/hだぜ?

仕様確定してて書き捨てコードなら可能な量だと思うがね?

432 :仕様書無しさん:2006/07/16(日) 18:53:50
マネージャーの仕事は、報告書の催促と、バージョン管理ツールの導入では
ありません。第一、集めた報告書を中継して部長へ提出するだけなら、ccか
プロキシサーバーで十分じゃん。

433 :仕様書無しさん:2006/07/16(日) 18:54:26
>>430
馬鹿だな。偽装派遣人員なら速攻お帰り願えば済むだろ。
わざわざ使い続ける意味がワカンネ。

434 :仕様書無しさん:2006/07/16(日) 18:57:58
>>432
言ってることがよくわかんないんだが、
もしかして手段と目的間違えてないか?
目的:リスクマネジメント
であり、
手段:(ヒューマンエラー低減を見込んだ)ツールの導入
だろ?

まともにマネジメントできないPMしか見たことないってなら乙としか言えないが。

435 :仕様書無しさん:2006/07/16(日) 18:58:09
>430
いや、ルールがツールという形になってる点で非常に有意義。
口頭や文面でルールを伝えるより、よっぽど徹底しやすい。

もっともツールがあっても、想定外の事をやってくれる奴も居るには居るけどね。
しかしそいつが「ツールの無い環境ならまともに動く」保証は無いと思うが。

436 :仕様書無しさん:2006/07/16(日) 19:06:41
俺の場合、開発初期は爆発的にコードが増え、
後半はリファクタリングやなんやらでだんだん減少していく。

437 :仕様書無しさん:2006/07/16(日) 19:14:09
少し話題を変えるが、皆はCommitの単位をどう区切ってる?

俺は単機能追加だったり修正1つにつき1commitでやってるんだが(ログ追いやすいし)
別のプロジェクトではもう少し大きな機能単位でCommitしてるようなんだ。
後者の場合の利点は何があるんだろうが?

438 :仕様書無しさん:2006/07/16(日) 19:24:22
>431
実際、書いた経験あるの?計算上はそうだが、飯食ったり、通勤や睡眠の
時間を考えたら、とても15時間フル稼動できるとは思えんがな。

まぁ、オマエさんの言うとおり、それが可能だったとして、1000step/hは
16.6step/分。1ステップにつき、約3.6秒の早さで毎日15時間、みっちり
1週間ぶっ通しでコードを書き続けなければならん計算だな。1500step/h
なら、1ステップにつき、2.4秒。

より現実的なセンで、1週間=7日、実動10時間/日と想定すれば、1ステップ
あたり約2.5秒だな。

少なめに1ステップ平均が10文字だったと仮定したら、1秒あたり4文字キー
入力し続けなけりゃ追いつかんな。もちろん、その間は、仕様書に目を通す
ヒマも、ヘルプ調べたり、トイレで用を足したり、コーヒ飲んだりする時間
なんてのもない。


439 :仕様書無しさん:2006/07/16(日) 19:28:02
基本的には細かけりゃ細かいほどいいんじゃないか?
自分の環境で動作確認できない時に、
commit→サーバーでupdate→build→確認
って手順を踏んでたときは
コメントがDebug,Debug,Debug....って酷い状態になった。

その日の終わりにcommitしたり、その機能が完成するまで粘ったりとかはよくあるな。

あまり寝かしておくとcommitするときにコンフリクトして泣ける。

440 :仕様書無しさん:2006/07/16(日) 19:45:50
>>433
偽装派遣の会社から、『受け入れて貰えたら、派遣1人あたり1万円をマネー
ジャーさんの個人口座へお振り込みしますよ』と言われるわけだよ。

給料安くて、管理職だから残業もつかないのに、子供の教育費とか家のローン
の支払いがあって自分の自由になる小遣いも満足にない正社員にとっては、願っ
たり叶ったり。何か問題が起きれば、それこそ切ればいいからね。

コンプライアンスに熱心な会社ほど、実態としての社員のモラルや会社への
忠誠心なんて表向きだけってこった。

441 :仕様書無しさん:2006/07/16(日) 20:57:37
全てのコードをキーでタイプなんてありえないだろ。
部分的にコピペしてエディタで置換なんて普通にやるぜ。
フルスクラッチで何も無いところから全てのコードを書いてるバカがいたら教えてくれ。

442 :仕様書無しさん:2006/07/16(日) 21:30:25
コピペしないわけじゃないけど、バグまでコピペしたら嫌なので
安易にはっつけて置換で終わりということは絶対にしない

443 :仕様書無しさん:2006/07/16(日) 21:33:46
#include <stdio.h>

と書いたら、コピペして

#include <stdlib.h>

と書き換えるだろ。

444 :仕様書無しさん:2006/07/16(日) 22:11:53
コピペしたり、ペーストした行を修正するにも、カーソルを移動したり、
不要な文字を削除するために、キーボードなりマウスの操作をするだろ
うが。

あと、10万行のソースを途中で一度も、セーブしたり、コンパイルしたり、
リファクタリングしたりもせずに、神頼みで一発ビルドすんのか?おめえら
ホントにおめでてぇな。

445 :仕様書無しさん:2006/07/16(日) 22:33:44
バージョン管理ツールってさ、(バージョニングされた)リリースを管理するものじゃねえの?
つまり、コミットするのはテストが終了したコードが前提。そんなに頻繁にするものじゃない。
バージョンとバージョンの間のソースはローカルで書き、ローカルでテストしろって。

ここに巣食うCVS/SVN厨のアホどもみてると、バージョン管理ツールというよりソースコード
改編履歴記録ツールだな。よほどDQNドカタをかき集めてコードを書かせているんだろうな。
いっそのこと、キーボードロガーでも導入したらどうだ?w

446 :仕様書無しさん:2006/07/16(日) 22:39:05
>>445
つうか、CVSFSとかSVNFSとかを使うのがいいんだと思うよ

447 :仕様書無しさん:2006/07/16(日) 22:41:54
構成管理と版数管理の関係

448 :仕様書無しさん:2006/07/16(日) 22:42:26
テストも通ってないコードをコミットしないでください。

449 :仕様書無しさん:2006/07/16(日) 22:47:59
CVS/SVNを導入すると、1ファイルのサイズが大きくなる傾向がある。
どうも新しくモジュールやクラスを登録するのが微妙に億劫になるみたいで、
追加する時に既にあるファイルの隅にコードを追加する輩が多いんだよな。

450 :仕様書無しさん:2006/07/16(日) 22:55:43
>>449
そういうのはソースレビューして弾いちゃえ

451 :仕様書無しさん:2006/07/16(日) 23:07:42
>>445
>改編履歴記録ツールだな。よほどDQNドカタをかき集めてコードを書かせているんだろうな。

最近の納期圧縮や単価の買い叩きを考えると、あながち的外れではない。
そもそも、正社員自身が作業の圧迫でまともな思考能力を失っている場合もあるのだ。

452 :仕様書無しさん:2006/07/16(日) 23:17:42
>>445
改版履歴記録ツールとして使う場合はブランチを切るのが吉

453 :仕様書無しさん:2006/07/16(日) 23:51:16
>>449
CVSならまだしも、SVNでそんな馬鹿見たことねぇ

454 :仕様書無しさん:2006/07/17(月) 01:44:44
10万行のコード書くまでに
試行錯誤で100万行分のコード書いているな。

何がいいたいかっていうと、
最終的に出来たコードで
スケジュールを判断するなということだ。

455 :仕様書無しさん:2006/07/17(月) 01:47:20
>>454
コーディングだけがマの仕事だと思ってる時点で、ダメじゃん?

456 :仕様書無しさん:2006/07/17(月) 01:57:36
なぜいまだに信者論争にしかならんコトを気付かないんだ・・・
どっちもどっちだおまいら

457 :仕様書無しさん:2006/07/17(月) 07:38:38
>>454
案外、他所のソースのコピペか他人のプログラムを丸ごと拝借して、自分で
書いたと称している厚顔無恥な香具師か、厨房なのかもしれん。

試行錯誤で延べ100万行のソースを15時間/日の作業で、1週間で書き上げたと
したら、ステップあたり0.38秒という、次元大介の早撃ち並みの、もはや到底
人間業とは思えない生産性でつな。それともアレか?攻殻機動隊に出てくる
ウィリス博士みたいに、キーパンチする時に指先が枝分かれするとか。

千の位でステップ数を四捨五入して、約1万ステップを1週間で書き上げる
ってなら、なんとか可能なレベルだとは思うけどな。

458 :仕様書無しさん:2006/07/17(月) 11:42:52
正直、必要かどうかだけでここまで荒れるネタだとは思ってなかったわけだがw


459 :仕様書無しさん:2006/07/17(月) 12:35:08
この業界に入ったときからずっとcvs(最近はsvnも)を使ってきた漏れとしては、
バージョン管理ツールを使わない開発ってのが想像もできんのだが。


…と思って過去ログみたら、なんだ単なるネタスレか。

460 :仕様書無しさん:2006/07/17(月) 12:42:43
個人で作るときもCVS作るの?

461 :仕様書無しさん:2006/07/17(月) 13:05:06
>>460
1から作り始める場合、最初は普通にファイルベタ書きだな。
で、ある程度ソースツリーの枠組が固まった時点でCVSに突っ込む。
cvs init => cvs import => cvs checkout するだけだから、ほんの1,2分の作業だ。

462 :仕様書無しさん:2006/07/17(月) 13:24:42
居るんだよなぁ。入社した時からずっとこのやり方で、これがウチのやり方
ですって言う、視野狭窄な香具師。特に、世間から隔離された大手企業に
多い。

試して、必要性があれば導入するのは一向にやぶさかではないが、使って
具体的にどんな成果が上がっているのかって話はどこからも聞いたことが
ない。

費やした手間や時間に比べて、得られるメリットが圧倒的に大きければ、
作業の手間や時間それ自体はさほど問題ではない。実際、使ってもメリ
ットがほとんど感じられない。

むしろ、バージョン管理ツールを導入することで、作業責任分担の範囲が
曖昧になる一方で、他人にソースをいじられたり、上書きされたりする潜在
的リスクが高まるだけのような気がする。

463 :仕様書無しさん:2006/07/17(月) 13:26:48
何度も言われているように必要か否かという議論は既に終わっている


464 :仕様書無しさん:2006/07/17(月) 13:43:53
>>462
だから、なんで責任分担範囲が不明確になるんだよ
ツールを使う場合の構成管理担当は、適宜責任範囲外の更新して無いかチェックしたり、
正しくコンパイルできることを確認したりするのが仕事になってくるだろ

ツールを使ってない時のルールのままじゃ上手く行かないの位ちょっと考えればわかる事だろ
コスト削減で要員減らすのは良いがこういう所は手を抜くんじゃないよ

465 :仕様書無しさん:2006/07/17(月) 13:45:21
>>462はバージョン管理ツールがどういうものかわかってないと思われ

466 :仕様書無しさん:2006/07/17(月) 14:04:37
>>462
「俺様のコードは俺様のものだから、誰も汚い手を入れるんじゃねぇ」
つまりこれが拒否する心理か。
そういうのはバージョン管理ツール利用云々以前の、
さらに程度の低い問題だと思います。

467 :仕様書無しさん:2006/07/17(月) 14:05:59
でも、それでバグを入れられたらむかつくよな。

468 :仕様書無しさん:2006/07/17(月) 14:50:32
>>466
> 「俺様のコードは俺様のものだから、誰も汚い手を入れるんじゃねぇ」
ああ、たまに居るね、そんなの。
経験上、こういう香具師はたいてい、結合テスト時に動かないコードを量産するか、
簡単なモジュールの実装すら何日もかかるほど生産性が低かったりするな。

「これは俺のコード、あれは他人のコード」と完全に分けて考えてるから、
他人のコードを読んで学習しようという気にすらならないんだろうな。

469 :仕様書無しさん:2006/07/17(月) 16:15:12
>>462
プロジェクト管理やプロジェクト方法論の書籍は
世に数多出版されているわけだが、
バージョン管理を用いないほうが良い、なんて書いてあるものがあるのであれば
教えてほしい。

> 入社した時からずっとこのやり方で、これがウチのやり方
> ですって言う、視野狭窄な香具師。
お前のことだろ?


470 :仕様書無しさん:2006/07/17(月) 16:17:19
vssだけにしろや

471 :仕様書無しさん:2006/07/17(月) 16:33:41
CVSって文字コードの問題解決したの?
昔はシフトJISのファイルを食わせたらバイナリと間違ってたりしてなかったっけ?

んでWinCVSもいろんなバージョンがあってげんなりし、結局VSSを使うことにした。

472 :仕様書無しさん:2006/07/17(月) 16:34:15
subversion使わないの?

473 :仕様書無しさん:2006/07/17(月) 16:35:26
あれってJavaじゃないの?

474 :仕様書無しさん:2006/07/17(月) 16:37:23
いや?

475 :仕様書無しさん:2006/07/17(月) 16:38:28
>467
実際、漏れの友人が、金融関係のプロジェクトで、隣の席の香具師に、毎日
古いソースを上書きされて、かなりムカついてたよ。リリース直前のテスト
で直したはずのバグが露呈して、調べたら上記のような状況だったらしい。
お蔭で、2日くらい泊まり込みに近い状況だったらしい。

>468
視野狭窄なステレオタイプの典型。

>469
学生か?世の中、本に書いてあることが正しいわけではないし、多人数が言う
ことが正しいわけではない。ましてや、全てではない。

『バージョン管理ツールを導入している』状況と、『バージョン管理する』
ってことは別物だろって言ってる。プロジェクトをVSSに放り込んだだけで、
バージョン管理している気になっている複数の開発現場は見てきたよ。
酷い話だが、中にはライセンス違反と思われる会社もあったな。

476 :仕様書無しさん:2006/07/17(月) 16:38:50
いや

477 :仕様書無しさん:2006/07/17(月) 16:38:55
WinCVSごった煮版ってなんなんだよ。素人丸出しというか玩具だな。

478 :仕様書無しさん:2006/07/17(月) 16:41:19
バカが勝手にファイル名を変更したのでわけがわからなくなりますた。

479 :仕様書無しさん:2006/07/17(月) 16:42:18
ブランチ間でマージする方法を教えてください。

480 :仕様書無しさん:2006/07/17(月) 16:44:31
CVSつかってりゃ全て完璧って思ってるバカおおいよね。

481 :仕様書無しさん:2006/07/17(月) 16:45:28
だから使わないの?それこそ馬鹿

482 :仕様書無しさん:2006/07/17(月) 16:47:23
バージョン管理ツールは効率を上げるための道具に過ぎない
俺も前はzipにしてローカルに保管してたけど
今思えば随分無駄なことをしてたと思う

483 :仕様書無しさん:2006/07/17(月) 16:47:48
導入してからが大変って話。
CVS入れてデグレの増えたところ多いんだ。

484 :仕様書無しさん:2006/07/17(月) 16:49:11
しかしデグレにならなければそのまま上書きされて>>475のようになるわけで。


485 :仕様書無しさん:2006/07/17(月) 16:49:26
完璧じゃなければやらんほうがマシ



だから俺は何もしないニート

486 :仕様書無しさん:2006/07/17(月) 16:50:58
>>484
なんでCVS入れるとデグレが増えるの?

487 :仕様書無しさん:2006/07/17(月) 16:51:42
何で毎日上書きすんの?
テストしたコード以外コミットする理由がわからんわ。

488 :仕様書無しさん:2006/07/17(月) 16:52:08
知るか

489 :仕様書無しさん:2006/07/17(月) 16:52:48
>>487

何でもコミットしろっていうキチガイがCVS管理してるから

490 :仕様書無しさん:2006/07/17(月) 16:54:06
なんでもCVSで管理しろって馬鹿いるよな

491 :仕様書無しさん:2006/07/17(月) 16:54:50
常に同期を取ってリアルタイムに変更を反映するようなツールがあればいいと思われ

492 :仕様書無しさん:2006/07/17(月) 16:55:15
CVSで管理するのにふさわしくないものも有る。


ここでクイズです。
それはなんでしょう?

493 :仕様書無しさん:2006/07/17(月) 16:55:35
共有ドライブ上でコンパイル

494 :仕様書無しさん:2006/07/17(月) 16:56:19
結合テスト始めるまでは毎日上げてもいいと思うが
開発マシン壊れたら洒落にならない
まあ、コンパイルエラーで自分の作った機能以外が動かなくなるような
ソースを上げなけりゃそれで良い

495 :仕様書無しさん:2006/07/17(月) 16:56:56
だから、文字コードの問題はどうなったの?解決したの?
まさかチェックアウトするたびに変換してるの?

496 :仕様書無しさん:2006/07/17(月) 16:57:31
vssだけにしろや

497 :仕様書無しさん:2006/07/17(月) 16:57:57
subversion使わないの?

498 :仕様書無しさん:2006/07/17(月) 16:58:05
CVSはバックアップツールじゃないよ。
テストを通るまではバックアップツールの役目。
単体テスト終わり、結合テスト終わったらバージョン振ってコミット。


499 :仕様書無しさん:2006/07/17(月) 16:59:18
バージョン管理って呼び方が駄目なんだな
変更履歴管理ツール

500 :仕様書無しさん:2006/07/17(月) 17:00:18
ばかばっかし

501 :仕様書無しさん:2006/07/17(月) 17:01:35
>487
それについては、そいつも当人に問い詰めたらしいが不明。

そもそも担当決めて作業分担してるのに、自分の預かり知らんところでソース
の書き換えが行なわれちゃかなわんわな。しかも、履歴辿ってソースを復元
できない状態だったら、最悪だわな。

それならzipで丸ごと保存して履歴管理する方がナンボかまし。ちょっと
中身を覗くだけならエクスプローラでそのまま開けるし、必要ならデスク
トップに解凍すればいい。

>499
変更履歴保存ツール

ただ保存しているだけの状況を管理しているとはフツー言わない。

502 :仕様書無しさん:2006/07/17(月) 17:05:34
日々の作業のバックアップツールと勘違いしている馬鹿がいて困りますね。

503 :仕様書無しさん:2006/07/17(月) 17:13:01
そのバックアップツールとしてさえ満足に機能していないわけだが?

いざとなった時バックアップとしてすら使えない変更履歴保存ツールと、
確実なバックアップ手段があったら、選ぶのは間違いなく後者に決まって
いるだろう。

504 :仕様書無しさん:2006/07/17(月) 17:16:22
ごった煮版って何?

505 :仕様書無しさん:2006/07/17(月) 17:17:08
ぶっちゃけ、WinCVSは糞。CVSを弄るためだけにEclipseを起動し、コーディングは秀丸でって人も多いだろう。

506 :仕様書無しさん:2006/07/17(月) 17:20:07
よく判らないけど
コピーコマンドマンセー、俺以外は馬鹿だから俺のやることは正しいって事でOK?


507 :仕様書無しさん:2006/07/17(月) 17:20:40
>>505
ノシ

508 :仕様書無しさん:2006/07/17(月) 17:22:05
>>507
お前だろ、毎回エラー出したままサーバーに上げてみんなに吊るされてるのw

509 :仕様書無しさん:2006/07/17(月) 17:22:48
日本のCVSコミュニティがアホぞろいだったから、ローカライズが糞で日本語文字コードの扱いがぐだぐだになってしまったのは事実。
あれですっかりCVSに失望した人は多いよ。

510 :仕様書無しさん:2006/07/17(月) 17:23:34
>>509
バージョン管理なんて使ってる奴等はみんなアフォぞろいだからそういうことになるんだ。

511 :仕様書無しさん:2006/07/17(月) 17:24:17
CVSは糞だよ。
その糞を改良したのがSVNなのに、なんでいまだにCVSを使い続けるのかよーわからん。

512 :仕様書無しさん:2006/07/17(月) 17:24:58
リリースが頻繁で分岐の激しい業務系だけでしょ。こんなの必要なの。
リリースがきちんと管理されたパッケージには無縁だよ。

513 :仕様書無しさん:2006/07/17(月) 17:25:58
業務系ドカタ管理ツール

514 :仕様書無しさん:2006/07/17(月) 17:28:10
いいわけ大王だな。
http://subversion.bluegate.org/svn-anti-fud-ja.html

515 :仕様書無しさん:2006/07/17(月) 17:34:19
EclipseでSVNが弄れて、CVSに蓄積したソースをSVNに移行してくれたらやるよ。

516 :仕様書無しさん:2006/07/17(月) 17:36:30
> CVS は非常にすぐれた、そしてバージョン管理にふさわしいことが証明
> されたモデルである; 単にうまく実装されていないだけだ。

現実として一度もうまく実装されていないのに、証明されたと言い切れる
のだろうか。しかも、何を以って非常にすぐれたとか、ふさわしいと
言うのだ?

517 :仕様書無しさん:2006/07/17(月) 17:41:26
>>514
ツッコミどころ万歳だなw
俺、こんなアホが作ったもん使うのやだなw

518 :仕様書無しさん:2006/07/17(月) 17:41:35
SVNも糞ですが。何か?

519 :仕様書無しさん:2006/07/17(月) 17:42:06
一番まともなのはVSSとRCS

520 :仕様書無しさん:2006/07/17(月) 17:43:27
>>515 つ[cvs2svn]

521 :仕様書無しさん:2006/07/17(月) 17:47:10
> 新製品にたいして接するようにしてください。つまり、注意深く接して
> ください。Subversion を信用するなと言っているわけではありません・・・
> しかし常識的に考えるべきではない、と言っているのでもありません。
> テストなしに重要な目的に利用するのは避けて欲しいと言っているの
> です。

誰かが最初に毒見しないと食べれないモノを口に入れちゃダメだろ。

522 :仕様書無しさん:2006/07/17(月) 17:49:01
とんでもねえ話だな。
ソース管理という極めて重要なツールで人柱を要求してやがる。

523 :仕様書無しさん:2006/07/17(月) 17:49:47
SVN厨とJava厨って同じ臭いがするよね。

524 :仕様書無しさん:2006/07/17(月) 17:50:29
CVS厨ほどではないと思うよwwwww

525 :仕様書無しさん:2006/07/17(月) 17:51:22
もはやCVSがスタンダードだろ。お前らアホか。

526 :仕様書無しさん:2006/07/17(月) 17:53:04
必要性の次は信者論争かwwwwおまいら楽しいな

527 :仕様書無しさん:2006/07/17(月) 17:53:49
>>525
こんなボケの作ったSVNでもCVSよりはましな状態なんだ・・・orz

528 :仕様書無しさん:2006/07/17(月) 19:09:49
Team Foundation Server を使ってるところは、まだあまりないのかな?

529 :仕様書無しさん:2006/07/17(月) 19:39:33
信者論争に入ってきて、ドカタ罵倒要素が入ってきたら、3年くらいは続くな。。。



Javaスレのように。

530 :仕様書無しさん:2006/07/17(月) 20:05:39
基本的に賛成派で、バージョン管理の好きなところはいろいろあるけど、
>>17で説明している「コードにゴミコメントを残さなくて良い」と
いうのが一番好きな部分。

新人で入社以来、4年間目立関連案件部署で働いているが、
P票番号やら本当に見苦しいソースばっか・・・

531 :仕様書無しさん:2006/07/17(月) 20:16:15
CVSで管理していても、DELとかADDってコメントを残させるところって無い?

532 :仕様書無しさん:2006/07/17(月) 23:11:00
高々道具なんだから、使いよう。
だがいかなる道具も、使わないより使いこなした方が便利になり、
使いこなせない場合は、使わない場合より不便になる。


533 :仕様書無しさん:2006/07/17(月) 23:39:30
バージョン管理ツールの一番の利点はバージョン管理のやり方をツールのルールで統一できるところ。
逆にツールのルールに縛られる部分もあるので、不便になる状況も確かにある。

>>530
ごみコメントっていうかIFDEFブロックコメントが最悪。
エディタも色分けしてくれないしね。

534 :69式フリーPG ◆hND3Lufios :2006/07/17(月) 23:57:41
何がむかつくって#ifdef 0でコードを残す奴だな。
コメントで残してくれたほうがマシ。

535 :仕様書無しさん:2006/07/18(火) 00:36:11
> ごみコメントっていうかIFDEFブロックコメントが最悪。
> エディタも色分けしてくれないしね。
> 何がむかつくって#ifdef 0でコードを残す奴だな。
> コメントで残してくれたほうがマシ。

あーそれ、漏れ。

エディタの色分けに頼っている時点で、おまいらのダメさ加減がよくわか
るよ。#ifdef/#endifすら読み飛ばせないようだと、コード中にコメントが
多いと逆切れしたり、モノクロモニタやグリーンモニタだと作業できません
ってか?

漏れは、非論理的なコード、冗長なコードを引き継ぐ方がずっとむかつくな。
無意識にコードをタレ流している証拠だと思うが、すべてのコードには理由が
あるべきって漏れから見れば、コードがそう書かれた理由を無駄に深読みさせ
られてかえって疲れる。

536 :仕様書無しさん:2006/07/18(火) 00:38:32
>>535
もちろんバージョン管理ツールは使わないんだよな?

537 :仕様書無しさん:2006/07/18(火) 00:49:20
>>535
だから、「なぜこのコードが残されたのか?」って思わせないために
#ifdef 0
は勘弁してくれ

538 :仕様書無しさん:2006/07/18(火) 00:52:06
C言語使ってると馬鹿になるという典型だな

539 :仕様書無しさん:2006/07/18(火) 01:01:25
デバッグ用、もしくは、単体チック用のコードです。

540 :仕様書無しさん:2006/07/18(火) 01:13:48
だったら

#ifdef _DEBUG

だろ。ゴミ

541 :仕様書無しさん:2006/07/18(火) 01:19:12
#ifdef〜#endif で囲まれた範囲に色付けできる
エディタも普通にあるのだが。

542 :仕様書無しさん:2006/07/18(火) 01:21:14
俺、C言語大好きだけどそれ使ったこと無い
ド低能が使ってるの見たことはあるけど

543 :仕様書無しさん:2006/07/18(火) 01:21:56
>>540
勝手にデファイン切らないで下さい。

544 :仕様書無しさん:2006/07/18(火) 01:23:18
>540
あの〜。C++(Cは知らん)標準は NDEBUG ですよ。
ttp://donguri.sakura.ne.jp/~shock8/wisper/debug_release.html

545 :544:2006/07/18(火) 01:25:30
CもNDEBUGが標準みたいですね。(assert.hの項参照)
ttp://ja.wikipedia.org/wiki/%E6%A8%99%E6%BA%96C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA

546 :535:2006/07/18(火) 01:38:53
>537
残されていないコードだから、#if 0なんだよ。ところで、#ifdef 0は常に
TRUEか未定義動作になるんじゃないのか?

あと、細かいツッコミとして、#ifdef HOGE/#ifndef HOGEは互換性のために
残されてて、#if defined(HOGE)、#if !defined(HOGE)が推奨だと思った。

547 :仕様書無しさん:2006/07/18(火) 01:42:51
>>546
じゃあなんで消さないの?

548 :仕様書無しさん:2006/07/18(火) 01:47:13
#if 0 でコメントアウトって、>535の言う「冗長なコード」には
当てはまらないのだろうか。

549 :535:2006/07/18(火) 01:53:46
>547
使わなくなった機能で、また復活させる可能性があるとか、プログラム途中
で試行錯誤の中で何か不具合があった場合など、どういうコードでどう
いう問題が起きたという記録のため。後者の場合、コメントは残してあるよ。

不要という理由で丸ごと消したら、そういうノウハウ情報も消えるし、後で
誰か(他人かあるいは自分かも)が書き直してデグレする潜在的可能性が残る
から。

550 :仕様書無しさん:2006/07/18(火) 01:57:55
>>549
なるほど。じゃあバージョン管理ツールについてはどう思う?

551 :535:2006/07/18(火) 01:59:18
>548
余分なバイナリ生成されない#if0 〜 #endifは漏れ的にはソースコードじゃ
ないから。

漏れが言う冗長なコードとは、volatile宣言されていない変数がループ内
比較されていたり、ループ内で書き換えられない変数への代入が、ループ
内で毎回代入されていたりするコード。

552 :仕様書無しさん:2006/07/18(火) 02:02:49
>余分なバイナリ生成されない#if0 〜 #endifは漏れ的にはソースコードじゃ
>ないから。

死ねよお前w


553 :仕様書無しさん:2006/07/18(火) 02:05:04
俺ルールが全てって言ってるだけの厨じゃんw

554 :仕様書無しさん:2006/07/18(火) 02:19:03
>551
無茶言うな

555 :仕様書無しさん:2006/07/18(火) 02:26:25
>>553
>>506


556 :仕様書無しさん:2006/07/18(火) 02:59:07
何人もの人の手を経たソースで#if 0 が複雑にネストしてると#elseを探すのが大変だ
勝手に消したらまずいだろうし、てわけでネストが増えていくw
この話題はそろそろスレ違いかの

557 :535:2006/07/18(火) 04:19:07

#if 0〜#endifブロックが増えるなら判るが、なんで#if 0がネストしていく
んだよ。 #elseが増えるのが大変っていうヤツは、/* */のコメントがネスト
しても、確認するわずかの手間を惜しんで、勝手にコード消すやつだろう。

>553
#if 0 〜 #endifで、勝手にコードを生成するコンパイラがあったら教えて
くれ。コーディング規約で、//コメント禁止って言ってるレベルと同じくらい
馬鹿らしいな。

それと、#ifdef 0って言ってたやつ、何とか言えよ。オマエら、そんなコード
書いてうごかねぇとか言ってんじゃねぇのか?

558 :仕様書無しさん:2006/07/18(火) 04:26:24
なんでこんなに粘着なの?
しつこいのにも程があるよね

559 :535:2006/07/18(火) 04:28:50
クソは叩いておかないと、世界中がクソまみれのコードであふれかえるから。

560 :仕様書無しさん:2006/07/18(火) 07:43:26
バージョン管理使うんならいらんコードは全部消していいじゃん。


561 :仕様書無しさん:2006/07/18(火) 08:46:54
>>559
んじゃ、鏡に向かって罵声浴びせるといいよw

562 :仕様書無しさん:2006/07/18(火) 09:15:24
つーか、#if 0とかじゃまくせーコードをバッサリ消せるのが
バージョン管理ツールのメリットだろ・・・って釣りなんだろうな。

563 :535:2006/07/18(火) 09:23:00
んで、一度消されたコードを引き継いだ別の香具師や、3歩歩いたら自分で
書いたコードも忘れちゃうような香具師が、見事に消されたコードを再現
してデスマになるわけだ。

でも変更履歴保存ツールがあるから、いつエンバグしたかトレースできる
から、安心ってか?

564 :535:2006/07/18(火) 09:26:32
#if 0〜#endif程度を邪魔臭いコードって言うような香具師は、小雨が降って
る時でさえ、常にワイパーが動いてないと前が見えなくて運転できないって
ヤツだろ。

そういう連中は、プログラミングも車の運転もやめた方がいいと思うぞ。

565 :仕様書無しさん:2006/07/18(火) 09:31:42
おまえ絶対仕事できねぇだろw

566 :仕様書無しさん:2006/07/18(火) 09:54:32
またしてもバージョン管理否定派は馬鹿であることが証明されました

567 :535:2006/07/18(火) 09:55:00
>565
おまえの言う仕事とは、日々ステップ数を増やした分だけバグを埋め込ん
で、いたずらに納期を遅らせ、テスト工数と残業時間を増やすことか?
そりゃ、漏れにはマネできんわ。

568 :仕様書無しさん:2006/07/18(火) 09:56:37
共同作業を理解出来ない奴が仕事でコード書くなよw


569 :535:2006/07/18(火) 09:59:51
おまえらキモイ連中と合体するような、依存関係の高いコードなんて書ける
かよ。オブジェクト指向とか、モジュール化って言ってるのが、表面的で、
言葉尻だけなのがよくわかるよ。

570 :仕様書無しさん:2006/07/18(火) 10:00:52
な?こんな奴ばっかだ。

571 :仕様書無しさん:2006/07/18(火) 10:09:09
そんなに今やってるプロジェクトで嫌なことがあったのか?
そんな君にはバージョン管理ツールの導入をおすすめするよwwwww

572 :仕様書無しさん:2006/07/18(火) 10:17:20
こいつ(535)バージョン管理否定派なのか
どっちでもいいけどこいつとはいっしょに仕事したくないなというのが率直な感想

573 :535:2006/07/18(火) 10:23:08
漏れも、1行blog機能付き変更履歴保存ツールを導入しているだけで、
バージョン管理しているつもりで居られる連中とは、仕事したくないな。


574 :仕様書無しさん:2006/07/18(火) 10:45:10
とりあえず、Ignoreファイルに535追加。
俺のリポジトリが汚れる。

575 :仕様書無しさん:2006/07/18(火) 10:53:46
流石に名前欄に全角数字書いちゃうような子とは一緒に仕事したくないな

576 :仕様書無しさん:2006/07/18(火) 13:06:54
ageていこうぜ

577 :仕様書無しさん:2006/07/18(火) 19:28:50
同じエンバグ繰り返すとか言ってるがソースレビューやペアプロとかやらんのかこいつ
教育しても同じバグを繰り返す奴は適正がないってだけの話だから首にすれば良いだけ

578 :仕様書無しさん:2006/07/18(火) 21:15:47
えーっと

#ifdef DEBUG

#endif

はダメっすか?

579 :仕様書無しさん:2006/07/18(火) 22:24:02
>>577

% vi 577
:% s/適正/適性/
:wq

% cvs commit -m "typo"


580 :仕様書無しさん:2006/07/18(火) 22:48:36
CVSの何がむかつくって、勝手にviを起動するところだな。
あんな前時代の遺物を使えってのか!

581 :仕様書無しさん:2006/07/18(火) 23:40:54
>>580

環境変数 EDITOR を設定するだけじゃないのか?

582 :仕様書無しさん:2006/07/18(火) 23:42:56
あ。俺は Emacs + pcl-cvs だが。cvsweb は w3m で見る。
コーディングからデバッグ、バージョン管理まで Emacs で完結。

VSSのように使いづらいインタフェースに縛られることなく、
CVSやSVNは自由に自分の使いやすいのが選べるのは良いね。


583 :仕様書無しさん:2006/07/19(水) 00:28:28
>>541
それはmakefileのコンパイルスイッチも解析して色分けしてくれるの

584 :仕様書無しさん:2006/07/19(水) 00:39:40
>557
ネストしないならコメントでいいじゃん。
つうか再発防止の為なら、コメントにして「コレじゃダメだった」とでも書いとこうよ。

あと>535で #ifdef 0 を華麗にスルーしてたのが恥ずかしいからって、
責任なすり付けるのはイクナイ。
というかみんなスルーしてるのに、自分で掘り返してどうするw

585 :仕様書無しさん:2006/07/19(水) 00:44:07
あげ

586 :69式フリーPG ◆hND3Lufios :2006/07/19(水) 00:45:44
オイラが余計なことを書いたばっかりに・・・。すまん

587 :仕様書無しさん:2006/07/19(水) 00:46:34
/* ----------- 仕様変更のため、ここから削除 ------------
  for (i=0;i<num;i++) {
    printf("test result(%d)\n",i);
    if (result[i]) {
      /* 結果が入ってるときのみ表示 */
      printf("...%s\n",result[i]);
    } else {
      printf("..nothing\n");
    }
  }
-------------- ここまで削除 -------------------------- */

ってならないように#if 0〜#endifのネストが増えていく。

588 :仕様書無しさん:2006/07/19(水) 00:48:13
しつこいぞ

589 :仕様書無しさん:2006/07/19(水) 00:51:55
まとめてみますた。(何を?)
>535 00:36:11
>546 01:38:53
>549 01:53:46
>551 01:59:18
>557 04:19:07
>559 04:28:50
>563 09:23:00
>564 09:26:32
>567 09:55:00
>569 09:59:51
>573 10:23:08


590 :仕様書無しさん:2006/07/19(水) 00:52:15
>586
刑: トリップ剥奪
半年名無しに戻ってろ

591 :仕様書無しさん:2006/07/19(水) 00:54:30
つーかソースコード論は他でやってくれないか

ぱっと見て「ヘタだなぁ」と思うコード その4
ttp://pc8.2ch.net/test/read.cgi/prog/1152383007/

とか

592 :仕様書無しさん:2006/07/19(水) 00:55:23
さあさあ、ageていこうぜ。

593 :否定派への質問:2006/07/19(水) 04:59:11
あなた達はそんなにも愚かなのに、バージョン管理を使わないことに対する
ヘタクソな言い訳だけは湯水のようにあふれ出てくるんですか?


ああわかった。
普段から言い訳にばっか頭を使ってるから、大事な思考能力が欠けてるんだなwwww

594 :仕様書無しさん:2006/07/19(水) 05:02:26
確かに。こんなことでグズグズ言ってるやつはまあダメだな。

595 :仕様書無しさん:2006/07/19(水) 08:00:51
69式のおっさんが悪いんだよ

596 :おじゃばさま:2006/07/19(水) 09:15:47
いや、69式のおっさんは悪くない。
「#if 0」や「/* */」でコメントアウトする人が悪い。
閉じ忘れを防ぐのと、差分を見るために「//」を使うのがスタンダードです。

597 :仕様書無しさん:2006/07/19(水) 09:35:04
69式のおっさんはそれなりに技術はあるが
最近は酒の飲みすぎで脳のシナプスが溶け出しているふしが見受けられる

598 :仕様書無しさん:2006/07/19(水) 09:38:14
大体チーム開発でコードを共有するなんて嫌だな
Java厨あがりの糞コードなんてメンテできんわ
かってに動かないソースをいつまでもいじっとけ
という俺はVSSで細かくラベルをつけている。
おいVSS使うときは動作したタイミングで必ずラベルつけとけよ!

599 :仕様書無しさん:2006/07/19(水) 09:58:55
糞コテ氏ね

600 :仕様書無しさん:2006/07/19(水) 10:06:25
if(糞コテ == 69式 || 糞コテ == おじゃばさま){
 goto abone;
}

601 :仕様書無しさん:2006/07/19(水) 10:12:53
Cソースでは「//」によるコメントが使えないから、 >>596 のような
おじゃば様は、自分で理解できないという理由で、必要なコードを
ばっさり消してしまうのですね。


602 :仕様書無しさん:2006/07/19(水) 10:16:05
C99準拠のコンパイラ使えよ。カス

603 :仕様書無しさん:2006/07/19(水) 11:17:40
>>600 よりによってgotoかよ。さすがは低スキルだな(プ 
goto論者も死んでいいよ。
gotoを言語仕様からはずしたJavaは神

604 :仕様書無しさん:2006/07/19(水) 11:19:43
Cの悲劇

#include <stdio.h>

int main(void)
{
 int a = 5;
 int b = 2;
 int *p = &a;
 int c = b/*p; ←あ、ここに、ここに…
 printf("%d\n", c);
 return 0;
}


605 :仕様書無しさん:2006/07/19(水) 11:22:40
>>603
しかし何故か Java の予約語には goto が存在する。


606 :仕様書無しさん:2006/07/19(水) 11:28:33
それはgotoという名前を関数名や変数名からすら排除するため

607 :仕様書無しさん:2006/07/19(水) 11:48:55
class goto {
 private String goto;
 public goto(String goto) {
  this.goto = goto;
 }
 public String toString() {
  return goto;
 }
}


608 :仕様書無しさん:2006/07/19(水) 12:56:04
> int c = b/*p; ←あ、ここに、ここに…
それって、
1. b 割る *p
2. b の後からコメント開始
のどっち?

609 :仕様書無しさん:2006/07/19(水) 13:06:51
>>608 2になる

610 :仕様書無しさん:2006/07/19(水) 13:07:43
なぜならば
コメントはプリプロセスの時点でなくなる予定だから

611 :仕様書無しさん:2006/07/19(水) 13:59:45
ミドルでは常識なgoto
ifでハンドルするとくそくどいコードになる。
Java厨はミドル経験ゼロだからgotoを叩くw
void handler()
{
 //メモリ割付
 //エラー発生
 goto unko;
 //メモリ割付
 //エラー発生
 goto unko;
 //処理
 //エラー発生
 goto unko;

 return;
unko:
//メモリのクリーンアップ
 return;
}

612 :仕様書無しさん:2006/07/19(水) 14:02:11
Java厨きえてくれ。
自分のいる狭い箱庭ワールドの常識しか見えないんだから。

613 :仕様書無しさん:2006/07/19(水) 14:08:48
バージョン管理マンドクセ

使わないほうが無能

使うメリットあんの?フォルダコピーでいいじゃん

はいはいわろすわろす

バージョン管理について誤解したまま叩きはじめる

CVS対SVNの信者論争

そもそもソースを整理すれば必要なし

そもそもバージョン管理使えない奴はコーディング能力も(プ

goto論争

Java厨叩き ← いまここ

614 :仕様書無しさん:2006/07/19(水) 14:28:17
>>611
Java の場合そういうのは try 〜 catch とか使うから goto 不要。
C はないから goto 使った方がそのように見易くなる。


615 :仕様書無しさん:2006/07/19(水) 15:11:40
try catchがネストしまくり
醜いコードでも満足な馬鹿なJava厨
シンプルにはどうしてもなれないのだ。

616 :仕様書無しさん:2006/07/19(水) 18:22:32
goto sentai boukenger

617 :仕様書無しさん:2006/07/19(水) 19:18:48
goto Java叩きスレ

618 :おじゃばさま:2006/07/19(水) 21:34:57
>601
言いたいことを長々とクドクド書こうかと思ったら、
602と603に的確に簡潔に言われてしまったので、今回は出番無し。

619 :仕様書無しさん:2006/07/19(水) 22:54:59
コードを簡潔にかけない時点で無能

620 :仕様書無しさん:2006/07/19(水) 23:10:29
>>613
何のスレなんだよ、ここはw

621 :仕様書無しさん:2006/07/19(水) 23:16:07
大丈夫。バージョン管理してあるので

>CVS対SVNの信者論争

この辺りまで戻れます。

622 :仕様書無しさん:2006/07/20(木) 00:26:58
goto+行番号
これ最強。食わず嫌いはよくないね。

623 :69式フリーPG ◆hND3Lufios :2006/07/20(木) 00:27:54
関数内でのgotoなら別にいいだろ。

624 :仕様書無しさん:2006/07/20(木) 00:35:56
C++で、例外使えない環境ではgotoを、こんな風に使ったり・・・

〜雑多な処理〜
if (isError) {
result = ERR1;
goto error;
}
〜雑多な処理〜
if (isError) {
result = ERR2;
goto error;
}
〜雑多な処理〜
goto finally;

error:
〜エラー処理〜
finally:
〜最後にすべき処理〜
return result;

625 :仕様書無しさん:2006/07/20(木) 01:01:48
素人に使わせたくないものは、「使わない」をデフォにしておくべきだ。
素人にこそ使わせたいものは、「使う」をデフォにしておくべきだ。

漏れ的にgotoは前者、バージョン管理ツールは後者

626 :仕様書無しさん:2006/07/20(木) 09:48:35
で?主観に基づく>>625の内容のどこに合理性と普遍性があるの?


627 :仕様書無しさん:2006/07/20(木) 09:59:54
>611
そんな常識一度も聞いたことがないぞ。ifネストが深くなってしまう部分の
処理は、大抵別の関数として独立させることが可能なものだ。

しかし、コードの再利用とか、モジュール化といった概念と無縁のケツ穴
野郎は、一本グソがお好みなので、あちこちにクソをまき散らすのだ。

そもそも、returnが2箇所あるのが、糞コードであることを証明している。
そんな厨房は、メモリだけ解放して、関数内でオープンしたハンドルを
閉じるのを忘れたコードを書いてリソースリークを発生されるのだ。

そして、じゃば房は、C/C++にはガーベージコレクションがないから悪いと
言い。VB房は、わざわざ代入コードを書かないと変数が初期値されないのが
悪いと、決まり文句の言い訳をする。>611
そんな常識一度も聞いたことがないぞ。ifネストが深くなってしまう部分の
処理は、大抵別の関数として独立させることが可能なものだ。

しかし、コードの再利用とか、モジュール化といった概念と無縁のケツ穴
野郎は、一本グソがお好みなので、あちこちにクソをまき散らすのだ。

そもそも、returnが2箇所あるのが、糞コードであることを証明している。
そんな厨房は、メモリだけ解放して、関数内でオープンしたハンドルを
閉じるのを忘れたコードを書いてリソースリークを発生されるのだ。

そして、じゃば房は、C/C++にはガーベージコレクションがないから悪いと
言い。VB房は、わざわざ代入コードを書かないと変数が初期値されないのが
悪いと、決まり文句の言い訳をする。

628 :仕様書無しさん:2006/07/20(木) 10:17:42
出口は一つでないといけないてのは今は流行らないらしい

629 :611:2006/07/20(木) 10:21:11
メモリ割付のケースによるんだけどね
出口ひとつも可能かな
void handler()
{
 //メモリ割付
 //エラー発生
 goto unko;
 //メモリ割付
 //エラー発生
 goto unko;
 //処理
 //エラー発生
 goto unko;

unko:
//メモリのクリーンアップ
//確保したものだけを開放する
 return;
}


630 :611:2006/07/20(木) 10:26:35
ようはソース管理ツール使うのを議論する前に
ソース管理ツールにチェックインする品質のソースじゃないと
いれても意味がないよ。金庫にごみをいれるようなもの。

631 :仕様書無しさん:2006/07/20(木) 10:38:18
フェラーリにDQNが乗ってるようなもんかw

632 :仕様書無しさん:2006/07/20(木) 11:23:22
returnを一つにするテクニック
その1
void foo(void) {
 if(...) { goto end; }
 if(...) { goto end; }
end:
 return;
}
その2
void foo(void) {
 while(1) {
  if(...) { break; }
  if(...) { break; }
 }
 return;
}

633 :仕様書無しさん:2006/07/20(木) 11:26:40
それフル >>632

いまはどのコンパイラにも、try __finallyがあるお。

634 :仕様書無しさん:2006/07/20(木) 13:34:55
>628
プログラミングスタイルは流行を追いかけるような性質のものではない。
出口が増えたら、トレースの際のブレークポイント設定も面倒だし、何より
それだけバグがテストケースをすり抜けてしまう潜在的可能性が増えるん
だけどな。

おまえら、テストファーストとか言ったり、目視デバッグで済む様なコード
にCppUnitとか使ってコンパイラにバグがないことを追証してないよな。

>630
言ってることが正しくても、説得力がない。

635 :仕様書無しさん:2006/07/20(木) 13:38:14
きれいなコードでも実行時に「どろろ」ってなるのもだめ。

636 :仕様書無しさん:2006/07/20(木) 13:39:57
百鬼丸 sage!

637 :仕様書無しさん:2006/07/20(木) 13:43:39
バージョン管理の必要性とソースの書き方は全く意味が違うと思うんだが。

汚いソースはバージョン管理する意味がないのか?
細分化されPG毎に完璧に管理されたソースはバージョン管理する必要がないのか?
オブジェクト指向で書かれたソースはバージョン管理してそうでないものは管理する価値がないのか?

意味のない議論をするなよ。これじゃただの信者論争だろ。
使いたきゃ使え、いらんと思うならやめとけ、使っても使わなくても痛い目見るのは自分だ。

638 :仕様書無しさん:2006/07/20(木) 14:26:27
使ってるさ。当たり前だろう。
動作もしないアーカイブにラベルつけて保存するのは
やめてくれと言っているんだ。
そしてそういう馬鹿は100%Java厨だ。

639 :仕様書無しさん:2006/07/20(木) 14:30:26
漏れ「チェックアウトしても動かないんだけど」
Java厨「んなことないはずっす」
漏れ「ほれっ」
 どろろろろろろろろろ、そして500番
Java厨「これは漏れさんがなにかXMLの設定を間違えてるんすね」
漏れ「やってみてよ」
Java厨「しゃこしゃこ」
 どろろろろろろろろろ、Out of Memory!
漏れ「いつまでも糞アプリいじってろ!」

640 :仕様書無しさん:2006/07/20(木) 15:01:22
ここでぬるぽ

641 :仕様書無しさん:2006/07/20(木) 20:52:49
>>633
VC8でエラー出たぞ・・・try, __finallyの組み合わせ

642 :おじゃばさま:2006/07/20(木) 21:34:29
>639
アーカイブをバージョン管理?テスト中に?あまりやらんな。
それをやるのは、むしろコンパイルオプションによって動作が変わるのC方だろう。
それどころか、ヘッダーファイルがあるCの方が、全体コンパイル時にコンパイルが通らないと、
毎回大騒ぎしてるぞ。

100%Javaとか言うならせめて根拠を示してくれ。C厨は妄想家が多いのかな。


643 :おじゃばさま:2006/07/20(木) 21:58:49
月曜からの結合試験
Java使い「さあ、結合試験やりましょう。準備はいいですか?」
C厨1「ちょっと待って下さい。コンパイルエラーが...。おい、○○さんはどうした。」
C厨2「○○さんは休日出勤して、今日は遅刻みたいです。日曜日にヘッダを変更していますね。」
C厨1「仕方ない、ヘッダだけ戻すか...。こんどは別のエラーが。いったいどのヘッダーを戻せばいいんだ。
   誰か分かる人はいないのか。」
C厨2「チーム全員いません。昨日で力尽きたのかもしれません。ああ、新人さんが来ました。」
新人さん「ああ、それはちょっと○○さんに聞いてみないと。あ、電話してみます。」
C厨2「コンパイルエラーで結合試験どころか、他の単体試験をやってる人も困っています。」
新人さん「○○さん、今から来るそうです。...寝ていたみたいです。」
C厨3「おいおい、どうなってんだよ。コンパイルエラーじゃ、試験も進まねーぞ。
   やってらんねーな、タバコでも吸ってくるか。今日は仕事にならねーな。」
C厨1「とりあえず、コンパイル通るバージョンまで戻すよ。少し待ってくれ。」
C厨2「どうですか?C厨1さん。」
C厨1「...先週の月曜まで戻った。」


644 :仕様書無しさん:2006/07/20(木) 22:14:24
>>639
javaのEJBとかいうの弄ってたときに悪夢のような数と質のエラーが出まくった。
(しかも、俺が出したわけじゃない。でも、動かないままにして帰る糞野郎が多かったから仕方なく直した)
EJBは俺の人生で1番か2番目ぐらいにブチキレた瞬間だったかもしれん。
俺のわけがわからん仕様ライブラリランキングで1か2位、
少なくとも3位には確実に食い込んでくるほどのわけのわからなさだった。

MSのOLE/ATLに並ぶぐらいわけがわからなかった。
ちなみにSwingは5位ぐらい。

645 :仕様書無しさん:2006/07/20(木) 22:15:11
あほか

646 :仕様書無しさん:2006/07/20(木) 22:16:39
>>645
てめぇのほうだろ!
死んでろ!

647 :仕様書無しさん:2006/07/20(木) 22:17:43
ガキの喧嘩か

648 :仕様書無しさん:2006/07/20(木) 22:19:33
>>647
はぁ?つまんねぇんだよ!消えろ!

649 :仕様書無しさん:2006/07/20(木) 22:40:38
おじゃばさまは以前のJavaスレで、maven等を長文で熱く語るJava厨様に比べると随分と小物だな。

650 :仕様書無しさん:2006/07/21(金) 01:10:55
>642
>それどころか、ヘッダーファイルがあるCの方が、全体コンパイル時にコンパイルが通らないと、
>毎回大騒ぎしてるぞ。

「ヘッダーがあるから」っつーのはおかしい。
ヘッダの扱い方が間違っているだけだと思われ。
さもなきゃ個別にコンパイルが通るものを寄せ集めたら通らなくなった、
なんて事はありえん。(リンクエラーは起こりうるが)

651 :仕様書無しさん:2006/07/21(金) 01:45:04
C言語が小規模、少人数の開発にしか向いて無いのは20年前から既出だろ

↓バージョン管理ツールの話題に復帰

652 :仕様書無しさん:2006/07/21(金) 01:47:41
antもmavenも糞だよ。
どれぐらい糞かっつーと、makeと同じぐらい糞。

653 :仕様書無しさん:2006/07/21(金) 03:32:08
mavenはともかくantはmakeより使いやすいだろ

654 :仕様書無しさん:2006/07/21(金) 09:29:53
>650
自分で理解できないエラーをすべてコンパイルエラーと称しているんでは
ないかな? あるいは#pragma onceに対応していないコンパイラ用のソース
でよく見かける

#ifndef __xxx_INCLUDED__
#define __xxx_INCLUDED__

// ヘッダ本体

#endif

の意図を理解していなくて、複数のヘッダで同じ「__xxx_INCLUDED__」を
使っていて、インクルードの順序や親子関係によって、特定のヘッダが
読み込まれない状況が発生しているとか。

そもそも、全体結合だからといって、全コンパイルの必要な理由もわか
らん。

仮に、各ソースに、単体テスト用に

#ifdef UNIT_TEST
int main(int argc,char **argv)
{
  // 単体テスト用のコード
}
#endif

みたいなソースが含まれていたとしても、コンパイルスイッチを変更して
各モジュールをコンパイルすればいいだけ。

655 :仕様書無しさん:2006/07/21(金) 10:44:01
アーカイブを全チェックアウトして環境が再現できないような
使い方しかできない低スキルならさ
ソース管理ツールなんて使うなよJava厨。

656 :仕様書無しさん:2006/07/21(金) 11:39:24
どろろろろろろろろろろろろろろろろ〜

657 :仕様書無しさん:2006/07/21(金) 11:57:55
>>653 antはやりたい機能ごとにいちいちタスクの使い方を覚えなきゃならんのが面倒
しかも痒いところに手がとどかな一つーか、ちょっと凝った事をやらせようとすると
結局自分でantタスクを書かなきゃならんので余計に手間がかかる気がする

makeは依存の仕組みが変態すぎてついていけん。

mavenは単なるオナニー

結論、どれも糞。シェルスクリプト書いたほうが何ぼかまし


658 :仕様書無しさん:2006/07/21(金) 12:06:27
その気持ちはわかる。まーJavaならantでいいけど。

659 :仕様書無しさん:2006/07/21(金) 12:28:45
まー


昼飯でもくおうぜ

660 :仕様書無しさん:2006/07/21(金) 12:56:01
どろろ定食たべてきた

661 :おじゃばさま:2006/07/21(金) 21:51:55
>644
俺もEJB被害者で、EJBは不要だと思っている。あれはEJB考えた奴が悪い。
だからJavaの問題じゃなくて、EJB考えた奴らの脳が腐ってたためだから、参考にしてはいけない。

>649
それは是非とも見てみたいな。
コピペしてみて。

>650
システムやサブシステム「共通のヘッダファイル」が修正になった場合だよ。
システムが大きくなると、共通ヘッダを修正した人が毎回コンパイルを全部やり直す事をしなくなったり、
チェックインタイミングのずれによって使用するヘッダが変わるから、
「コンパイルが通らなくなっているのに気が付かない」って事だよ。


662 :仕様書無しさん:2006/07/21(金) 22:56:06
>>661
>EJB考えた奴らの脳が腐ってたためだから
やっぱ、そうだよな。こんなガラクタ早く捨てなきゃ駄目だ。
せめてJSPにしようぜ。

663 :おじゃばさま:2006/07/21(金) 22:58:53
>654
誰に言っているのかよく分からないが、内容的におかしいので言っておこう。
「自分で理解できないエラーをコンパイルエラーと称している」?
理解も何もmakeが途中で止まるのがコンパイルエラーだろ?誰でも分かるんじゃないか?

コンパイルエラーが自分で解消できないのが問題だって言いたいのかな?よくわからんな。
次の内容の「2重インクルード防止を理解していない」ってのだが、
さすがに共通関数を作っている人はある程度技術のある人だから、そんな事はないだろう。
ライブラリにmain()を入れてしまうなんて事もないだろう。
素人じゃないんだから、さすがにそれは失礼なんじゃないか?

結局、共通ライブラリを修正している人達の中で、数人が同時期に修正したため、
それそれの持っていたヘッダファイルにバージョンの差があって、相互に相手の古いヘッダを
使用していたため、全て最新にするとコンパイルが通らなくなるって事だったらしい。
分かった?

>655
俺に言っているの?
客先リリース後ならともかく、アーカイブをバージョン管理なんてしないって言っているんだけど。
何言っているのかわからんな。
ソースからアーカイブが再現できないのは、コンパイルオプションがあるCだろ?
あと、高スキルしか使えないソース管理ソフトの方が意味がないだろう?
いまいち意味がわからん。日本人じゃないのか?


664 :仕様書無しさん:2006/07/21(金) 23:11:58
EJBってなんて楽なんだろうと思える糞フレームワークに関わったことがある

665 :仕様書無しさん:2006/07/22(土) 01:06:26
>>663
くずなJava厨が大勢集まり、糞コードを書いては
チェックインするのか。それじゃあ全体でびしっと動作するバージョンって
作れないからラベルもつけられないよね。

666 :非常に大雑把かつ重箱の隅な説明:2006/07/22(土) 01:33:43
>663
>理解も何もmakeが途中で止まるのがコンパイルエラーだろ?誰でも分かるんじゃないか?

(1)ソースファイルをオブジェクトファイルに翻訳する処理 (コンパイル)
(2)オブジェクトファイルをライブラリにまとめる処理
(3)オブジェクトファイルやライブラリから、 実行可能なファイルを生成する処理 (リンク)
(4)(1)〜(3)で生成したファイルを、補助記憶装置に配置する処理 (インストール)
(5)(4)で配置したファイルを削除する処理
(6)(1)〜(4)で生成した一時ファイルを削除する処理 (クリーンアップ)

makeは(1)〜(6)の処理の実施を補助するためのツールです。
つまり「makeが途中で止まるのがコンパイルエラー」は不適切です。

まァ、おじゃばさまは大人しくJavaでも使ってて下さい。

667 :仕様書無しさん:2006/07/22(土) 01:37:06
えーと、結論は

お前ら好きなツール使えや

でOK?

668 :仕様書無しさん:2006/07/22(土) 01:47:48
>667
いや、「身の丈に合ったツールを使えや」ですかね。
不相応なツールを使う or 適切なツールを使わない
がイクナイ。

669 :仕様書無しさん:2006/07/22(土) 11:35:23
>>668
最初は誰でも身の丈を越えたツールを使う事になるんだよ。
そんな事言ってたら何も使えない

670 :仕様書無しさん:2006/07/22(土) 14:09:16
VSSでの出来事
C++プロジェクト フルチェックアウト25Mバイト
チェックアウト−カシッ−>シャコシャコ−>完了

Javaプロジェクト フルチェックアウト 528Mバイト
チェックアウト−カシッ−>どろろろろろろろろろろろろろろろ
ろろろろろろろろろろろろろろろろろろろろろろろろろろろろろ
ろろろろろろろろろろろろろろろろろろろろろろろろろろろ
この間10分−>やっと完了


671 :仕様書無しさん:2006/07/22(土) 14:11:30
自分でバイト数書いておいて何言ってんだ?

672 :仕様書無しさん:2006/07/22(土) 14:51:18
おなじ機能を実現するのにも
これだけファイルサイズの違いが出ることを言いたかったのだが
それを気づいてくれないとはおぬしJava厨だな。

673 :仕様書無しさん:2006/07/22(土) 15:10:51
出ねーよ、Javaのほうがコード量少ないだろ

674 :仕様書無しさん:2006/07/22(土) 15:14:14
Javaでサイズが大きいのは、ほとんど外部依存jarのせいだろう。
C++でサイズが小さいのは、OSに最初から入ってるor別インストール済みの
外部依存dllをチェックインしてないからだろう。

675 :仕様書無しさん:2006/07/22(土) 15:31:59
外部依存のjarは、動作検証したものをすべていっしょに固めて
おかないと動作しないのがJava

C++はOSのパッチレベル程度の差分しかないので無問題

676 :仕様書無しさん:2006/07/22(土) 15:33:17
> 外部依存のjarは、動作検証したものをすべていっしょに固めて
> おかないと動作しないのがJava

こいつ頭おかしいだろ?夏郎が煽ってんじゃねーよ

677 :仕様書無しさん:2006/07/22(土) 15:36:32
どろろが怒っているぞw
Java厨は本当の事言われるとすぐに切れるのが特徴。

678 :仕様書無しさん:2006/07/22(土) 15:37:08
> 本当の事言われると

だから夏郎は知ったかしてんじゃねーって

679 :仕様書無しさん:2006/07/22(土) 15:39:02
StringBuilderを実装したマイ外部依存jar
チェックアウトした環境がjdk1.4.xだった

680 :仕様書無しさん:2006/07/22(土) 15:41:10
Oracle 8i(Linux)をインストールしようと思ったが
IBM jkd1.1.8をいっしょにかためておかなかったから
インストールできないとか

681 :仕様書無しさん:2006/07/22(土) 15:41:50
で?

682 :仕様書無しさん:2006/07/22(土) 15:42:37
ちょいと古い環境にチェックアウトしたら
推奨されていませんの嵐になったとか

UNICODEが化けるとか

でないはずの500番がでるとか
いろいろあるでしょう。

683 :仕様書無しさん:2006/07/22(土) 15:47:36
> 古い環境にチェックアウト
古いコードをじゃなくて?

Unicodeって何だよ、絞れよ
エンディアンに依存するのはJavaの話じゃない

> でないはずの500番がでるとか
コードが悪いんだろ

いろいろ無いから。

684 :仕様書無しさん:2006/07/22(土) 15:49:16
Javaは重いスレに帰ったら?
レベルが低すぎて話にならん

685 :仕様書無しさん:2006/07/22(土) 15:54:51
>>475
> 学生か?世の中、本に書いてあることが正しいわけではないし、多人数が言う
> ことが正しいわけではない。ましてや、全てではない。

で、前例から何も学ばす自分の経験だけのオレオレ手法で行くわけか。

686 :仕様書無しさん:2006/07/22(土) 16:04:16
おじゃばさまに変わる人気者
それは>>684

687 :仕様書無しさん:2006/07/22(土) 16:06:27
無知のまま居座れるって怖いな
2ちゃんねるそのもの

688 :仕様書無しさん:2006/07/22(土) 16:59:07
>685
前例じゃなくて、マスコミをはじめとする文献や世間一般、著名人といった
権威に弱いだけだろ。

689 :おじゃばさま:2006/07/24(月) 22:04:48
>666
タイトル見ると、多分俺の言いたいことも分かっていて、無意味知りつつ書いているようなので、
その潔さに敬意を表してそれなりのリアクションを取らせてもらおう。
「ふーーーん」

>675
俺も676と678に同意。
そういえば夏休みだな。オマエラ休みは何日?

>688
いやマスコミと権力に弱いのが学生、実績と経験に弱いのが社会人。


690 :仕様書無しさん:2006/07/24(月) 22:18:42
>>689
>実績と経験に弱いのが社会人
これ普通に弱いだけじゃん・・・

691 :仕様書無しさん:2006/07/24(月) 22:32:42
元は何を話すスレだか知らないけど、随分レベルの低いスレだね
恥ずかしくないの?

692 :仕様書無しさん:2006/07/24(月) 22:41:38
バージョン管理ツールは余裕がないならやめといた方がいい
なぜなら管理ミスで逆にわけがわからなくなることがあるからだ・・

俺は治したソースは毎日フォルダを日付名にして保存している
それを後でdiffで比べるほうがよっぽど安全、完璧だよキミ

693 :仕様書無しさん:2006/07/24(月) 23:40:36
>>692
しつこいな身の丈にあったツールを使えって事でFA出てるだろ

694 :仕様書無しさん:2006/07/24(月) 23:42:51
誰も同意してないw

695 :仕様書無しさん:2006/07/24(月) 23:50:02
だが誰も反論してないな。

696 :バージョン桜:2006/07/24(月) 23:59:13
おまえら!バカとブサイクこそバージョン管理使え!

697 :仕様書無しさん:2006/07/25(火) 00:06:56
>>695
別にバージョン管理つったって、バージョン管理してる奴が納得できる状態のソースでないと
上げると起こられるから結局、自分でソースのバックアップとって管理してるから俺んところだと意味無し。
上げるときだけチェックアウト→手動でマージ→チェックイン。ハイハイ。ウンコウンコ。

698 :仕様書無しさん:2006/07/25(火) 00:08:10
>なぜなら管理ミスで逆にわけがわからなくなることがあるからだ・・
それはあんたが間抜けなだけじゃん

699 :仕様書無しさん:2006/07/25(火) 00:48:53
間抜けなJava厨兵隊たちがデグレードしたソースを無造作にチェックインする。
管理したくともできない。それはPGの責任。
馬鹿なJava厨兵隊は戦う気がないヘタレばかり。

700 :仕様書無しさん:2006/07/25(火) 00:54:46
デグレードする前のソースや、
どこが変更されたかわかるのが
バージョン管理ツールの利点。

デグレードしたことにぜんぜん気づかず
気づいたときには、手遅れになるのが
バージョン管理ツールを使わなかったやつの運命

701 :仕様書無しさん:2006/07/25(火) 01:00:50
>>699
病院に帰ろうな

702 :仕様書無しさん:2006/07/25(火) 01:07:36
おまえら早く寝て明日の仕事にそなえとけよ

703 :仕様書無しさん:2006/07/25(火) 01:10:11
>>702
テキトーでいいんだよ。
仕事なんてどうせ良し悪しもわからん奴が上司なんだからw
アホかw真面目にやんな。疲れるだけだぞw

704 :仕様書無しさん:2006/07/25(火) 01:15:05
>>700 まあ、それが結論だな

705 :仕様書無しさん:2006/07/25(火) 01:25:54
>>699
チェックインする前にレビューしろよww

706 :仕様書無しさん:2006/07/25(火) 01:28:18
>>692
お前学生だろ? もしくは超小プロジェクト?
5人以上で、同一ソースツリーいじるなら、普通に使おうよ。
20人超のプロジェクトで、バージョン管理システムなしとか、成立不可能だろ。

707 :仕様書無しさん:2006/07/25(火) 01:47:06
色んな香具師が書いたソースを集めてリリース版をビルドする人の身にも成ってみろい

708 :仕様書無しさん:2006/07/25(火) 09:50:55
バージョン管理ツールを使うのは当たり前。
こんなもの使ってえばりちらしているここの主Java厨は
ほんとに低レベルだな。

709 :おじゃばさま:2006/07/25(火) 19:10:17
2人でもバージョン管理ソフトはあった方がいい。
自分のスキルに合ったってのは間違いで、みんなバージョン管理ソフト使うのが正解。
問題なのは使い方を間違っている場合と、手順を守らない人がいる事。
たとえばVSSの場合は、必ず守らなければいけないのは以下の通り。
・アカウントは必ず個人毎に作成する。
・編集する時は必ずチェックアウトする。
・コンパイルの通らないソースはチェックインしない。

ただしこれでもチェックアウトせずに編集して、上書きでチェックインする人が最初は何人か出る。
これを見過ごしてはいけない。アカウントを個人毎に作成すれば誰がやったか分かるので、
その人は見せしめになってもらう。
「あなたのチェックインした所は全部差分がないかチェックしてください。
 差分があったら修正して、関係する試験を全部やり直してください。明日までに。」
大体これで2度と違反しなくなる。
こっそり直したり、うやむやにしてはいけない。手順を守らない人が1人いるだけでみんなが迷惑する。




710 :仕様書無しさん:2006/07/25(火) 19:32:23
そもそもチェックアウトしてなくて、書き込み禁止属性の共有ファイルに
エクスプローラなどで強制上書きするんだから、チェックインなんてする
わけないし、チェックイン操作できないだろ。

しかも大抵の場合、VSSへのログインの手間を省くため、ネットワークのファ
イル共有のアカウント/パスワードと、VSSのアカウント設定が同じだったり
するんだから、始末が悪い。

というより、これでバージョン管理してるだって?低レベルのJava房が笑わ
せてくれるわ。Java房をプロジェクトから排除するのが、品質向上の解法。

711 :仕様書無しさん:2006/07/25(火) 20:17:28
>710
日本語で頼む。

712 :仕様書無しさん:2006/07/25(火) 21:15:20
>>709
VSSやCVS使っていても、しっかりとした管理者が目を光らせていないと、まったく意味がないということだな。
なんか入れることがほとんど目的になっている部署があるし。


713 :仕様書無しさん:2006/07/26(水) 00:01:26
>なんか入れることがほとんど目的になっている部署があるし。
それは、バージョン管理ツールの問題じゃなくて、あなたの会社の問題だから
ここに持ち出してきても解決しないと思うよ。

714 :仕様書無しさん:2006/07/26(水) 00:05:20
>>713
だいたいが絡んでるんだけどなw

715 :仕様書無しさん:2006/07/26(水) 00:12:52
だから、Subversion使えって。重いけど。

CVSとかVSSとか、簡単な抜け道があるようなバージョン管理ツールは管理能力が低い

716 :仕様書無しさん:2006/07/26(水) 00:26:12
CVSじゃもはやスタンダード。
SVNの付け入る隙は無い。

717 :仕様書無しさん:2006/07/26(水) 00:33:52
ディレクトリ移動、ファイルの削除が出来なくて何がスタンダードか…。

718 :仕様書無しさん:2006/07/26(水) 01:22:05
うちは毎日帰る前にチェックインが義務付けられてるな
各個人以前に管理のルール自体がクソだとアレだな

719 :仕様書無しさん:2006/07/26(水) 02:14:13
バグが残ってたら帰れませんね、大変そう

720 :仕様書無しさん:2006/07/26(水) 05:22:10
その場合、1日で終わらない修正はbranchする、ってルールをつけくわえるだけでいいんだよな。
でも、なぜかbranchするのを妙に臆病になってるトコが多い気がする。

721 :仕様書無しさん:2006/07/26(水) 06:10:55
てか、毎日チェックインはなんのためにやるのかわからない。
他の奴に触らせたくないからチェックアウトしてるのに、他の奴に触らせたくない状態でチェックインさせるなよ。

722 :仕様書無しさん:2006/07/26(水) 09:12:51
でも同期は細かく取ったほうがいいわけで。
単に作業状態を保存するチェックインと
完成したコードのチェックインという二段構えの構造があればいいんだけどなあ

723 :おじゃばさま:2006/07/26(水) 09:50:20
>710
俺も711の言う通りを希望なのだが、同じ事を言っても仕方ないので少し説明する。
「編集する時は必ずチェックアウトする」ってのは、
「チェックアウトせずに、エクスプローラーで書き込み禁止を解除して編集し、そのファイルをチェックイン」
したり、
「自分のローカルで手動バージョン管理(ファイル名変更)とかしていたやつを、戻してチェックイン」
する人が最初は少なからず存在するって事だ。こういう事をするなって事。

ネットワークアカウントとVSSアカウントが同じ?
なんだかしらんが、俺が言っているのはVSSアカウントの方で、それを個人毎につけろって事。
Windowsのネットワークアカウントは好きなの使え。Administratorでもいいんじゃね?
ネットワークログインが面倒なら「ネットワークドライブの割り当て」でも使えば?

>712
管理者が必要というより、最初に手順の説明と文章化が必要と言う方が近いかな。
最初に全員集めて、チェックアウト、チェックイン、チェックアウト取り消しの説明を
実際に誰かにやらせて説明する必要があるって事。面倒だと省略する所が多い。
実際にやれば説明には10分もかからないのだから。
あと文章化しておいて後から入った人にも徹底させる事も必要。
それとしくじった人を見せしめとしてさらすことも。


724 :おじゃばさま:2006/07/26(水) 21:25:44
>718
「編集の必要ないファイルは帰る前にチェックインしておく」ってルールが、
「編集の必要のない」と言うのが抜け落ちて、変な風に残ったんじゃないか?
開発者の中には朝に必要と思われるファイルを大量にチェックアウトして作業する人もいて、
そのまま忘れて帰る場合があるので、それに対する警告だと思う。

基本的に編集が必要になったファイルだけチェックアウトすべきだが、
作業量が多い人はそんな面倒な事はやってられないって人もいるからな。

編集中のファイルは無理にチェックインしてはいけない。ブランチなんて不要。
チェックアウトしたまま帰るべきだ。

725 :仕様書無しさん:2006/07/27(木) 00:35:37
前にいた馬鹿なJava厨の話
プロジェクトにないクラスを勝手に作った。
こいつはVSSにこのクラスを追加しなかった。
リーダはVSSを使っているので不足なファイルは無いと信じていた。
Java厨のローカルディクスをフォーマットした。
依存関係のあるソースのコンパイルが通らなくなった。

726 :仕様書無しさん:2006/07/27(木) 00:55:59
Java厨Java厨っていうけど、ただの厨なだけじゃないかな。

727 :仕様書無しさん:2006/07/27(木) 00:59:52
>>725
それはJAVAじゃなくても・・・

728 :仕様書無しさん:2006/07/27(木) 01:02:58
CSVの使い方知らない奴にCSV使わせると碌な事にならん
ライブラリとか文字コード変換されてプロジェクト全体が一時麻痺したときはあせった

729 :仕様書無しさん:2006/07/27(木) 01:31:11
>>725
そのバカをつるしあげて全員にバージョン管理を徹底させるのは当然のこととして、それでもバカを使うためにはまだ検討の余地があると思う。

1.定期的にまっさらな環境で全コンかければもうちょっと早いタイミングでわかったんじゃないか?
2.クライアントツールで追加漏れファイルがある事を容易にわかるようにできないか?

オレのところではビルド専用PCを立てることで1の問題は解消した。

2についてはVSSからsubversionに移行することで解決したが、これはチーム全員がVSSに強い不満もってたからできた話。大概はそんなホイホイ移行できるわきゃないわな。うーん、VSS2005なら回避策あんのかな?

730 :仕様書無しさん:2006/07/27(木) 06:24:26
全コンっていうか、Java厨くんしか持ってないんじゃもともとJava厨くんしかビルドできないじゃん
そもそもディスクをフォーマットするっていうのがバカだし

731 :仕様書無しさん:2006/07/27(木) 07:49:29
>>4
> この手のツールは結局
> 人がルール守らないから強制させる為の物
> 無くても出来るではなくさせる為の物だから必要
> ただその運用も守らないからあっても意味無い所が多いのには同意

お前はなにもわかってない。
まずはSubversionを使ってから発言しろ。

強制されるものではない。開発効率があがる。
むしろ、バージョン管理システムがやるべきことを人間に強制させる
ことのほうが意味がないどころか非常に非効率でミスが多い。

人間とは、機械と比べ信用できない存在なのだよ。


732 :仕様書無しさん:2006/07/27(木) 07:53:18
>>9みたいな時代遅れなオッサンってまだいるんだな。
そのローテクさ加減には驚くばかりだ。


733 :仕様書無しさん:2006/07/27(木) 09:38:33
>全コンっていうか、Java厨くんしか持ってないんじゃもともとJava厨くんしかビルドできないじゃん
問題なのは、それを誰も認識できていなかったこと。
定期的にまっさらな環境にexport->全コンしてれば、必ず気付く。

どんなプロジェクトにもバカは紛れ込むが、事前に対策をしておけば他のメンバーへの被害は最小限に抑えられる。

734 :仕様書無しさん:2006/07/27(木) 10:05:53
と、ニートが申しております

735 :おじゃばさま:2006/07/27(木) 10:11:19
確かにクラスの入れ忘れなら他の人がコンパイルすれば、ほとんどの場合はコンパイルエラーで気が付く。
ただインスタンス作成して呼び出すような場合は、コンパイルでは分からないから、
入れ忘れを完全に防ぐのは困難だろう。まあ、上の例はコンパイルで見つかる一般的な物だったようだが。

この場合は無理にシステムでどうにかしようとする必要はない。
単に入れ忘れた人を見せしめに、
「ではまた作って、試験をやりなおして、チェックインして下さい。明日までに。」
と言えばいい。これで入れ忘れも減るだろう。
それまではダミーのクラスでも作ってコンパイルを通るようにしておけばいい。

736 :仕様書無しさん:2006/07/27(木) 10:30:28
>735
> ただインスタンス作成して呼び出すような場合は、コンパイルでは分からないから、
> 入れ忘れを完全に防ぐのは困難だろう。

またまた、おじゃばさまの馬鹿っぷり炸裂。

インスタンス作成ってことは、そのクラス定義のヘッダをインポートして
いるはずだから、まずコンパイル時に「インクルードファイルが見つから
ない」エラーが起きる。仮にヘッダのみがあって単体でのコンパイルでは
エラーが起こらなくても、リンクエラーで判る。

> それまではダミーのクラスでも作ってコンパイルを通るようにしておけばいい。

こういう馬鹿が一匹でも混じっていると、全体ビルドでクラスの整合性が
とれなくなるわけだな。(w

737 :仕様書無しさん:2006/07/27(木) 13:00:32
>736
つ Class.forName


738 :仕様書無しさん:2006/07/27(木) 13:10:48
>737
そのクラスが、引数を必要とするコンストラクタしか定義されていない
場合や、コンストラクタがprotectedで、シリアライズ機能からオブジェ
クト構築することし許されていない場合もあるわけだが?

739 :仕様書無しさん:2006/07/27(木) 14:07:26
前にいた馬鹿なJava厨の話2
漏れ「Java厨太くん、ここではVSSでプロジェクト管理しているから
動作バージョンはラベルつけてもいいですのでしっかり管理して下さい。」
Java厨太「え・僕はEclipseのプラグインがサポートされていないものは
使う気がしませんので使いません。」
漏れ「あのこれはここの業務仕様なので厳守してくださいね。」
Java厨太「動作バージョンができたらjarにしますのであとはそちらで」
なんていうやりにくい馬鹿もいたっけな。

740 :仕様書無しさん:2006/07/27(木) 14:57:38
「これは業務命令なんだよ!
従えないならその腐れエディタごと窓から放り投げて
キモいJava厨同士でXPでアジャイルなペアプロごっこでもしてろや、ゴるぁ!!!」

でFAじゃね?

741 :仕様書無しさん:2006/07/27(木) 14:59:43
>>739
つ[http://sourceforge.net/projects/vssplugin]

742 :仕様書無しさん:2006/07/27(木) 15:37:36
>>741
Error!
Invalid Project
だそうです。

743 :仕様書無しさん:2006/07/27(木) 17:37:12
>741
Bugs : (48 open / 296 total)
Bug Tracking System

744 :仕様書無しさん:2006/07/27(木) 17:49:45
ページを表示できませんw
ああ、絵栗糞低品質プラグイン地獄

745 :仕様書無しさん:2006/07/27(木) 21:54:14
なぁ、バージョン管理ツールってバックアップとれるの?

746 :仕様書無しさん:2006/07/27(木) 22:00:51
とれるよ。アーカイブもできるし
VSSだったらルートフォルダごと別の場所にコピーしておいても
バックアップになる。

747 :仕様書無しさん:2006/07/27(木) 23:17:36
>>736
>> それまではダミーのクラスでも作ってコンパイルを通るようにしておけばいい。
>
>こういう馬鹿が一匹でも混じっていると、全体ビルドでクラスの整合性が
>とれなくなるわけだな。(w
「無能な働き者は銃殺刑」という言葉を思い出すな。
こんなことされるくらいなら、コミットのやりかたをしらない「無能な怠け者」のほうがまだマシ。


748 :仕様書無しさん:2006/07/28(金) 01:25:21
ゲーテは「活動的な馬鹿より恐ろしいものはない。」と言っているな。

749 :仕様書無しさん:2006/07/28(金) 01:49:59
>748
耳が痛い…
勝手に関数の並び順変えて怒られた事がある。

んで、元に戻せと言われたけど、そのソースはバージョン管理もしてなかったし、
元の並び順も憶えてなかったんで、素直に「無理」と言ったら1時間も押し問答になった。
漏れが悪いのは分かるがどうしろと。

皆はこんな事にならんよう、バージョン管理ツール使うか
こまめにバックアップ取っておこうな!

750 :仕様書無しさん:2006/07/28(金) 07:01:23
>>746
その程度だったらSubversionでも可能どころか
SubversionではVSSよりももっと高度なことができる。


751 :仕様書無しさん:2006/07/28(金) 07:03:36
頭の悪そうなC言語厨くんが暴れているスレか。
いや、バージョン管理システムもろくに使いこなせない
時代遅れな頭が悪いC言語厨くんが暴れていると。


752 :仕様書無しさん:2006/07/28(金) 07:06:42
>>725
C言語厨馬鹿であるお前は頭が悪いから気づいていないようだが、
Javaに限った問題じゃないな。

VSSなんてチェックアウトするとロックされてしまうような
古臭いバージョン管理システムを使ってるからそういうことになるわけだが。

そこでJava言語にせいにして2chでしか愚痴をこぼせない馬鹿を演じてないで
バージョン管理システムもちゃんと選べないお前の組織を恨め。



753 :仕様書無しさん:2006/07/28(金) 07:09:10
>>721
VSSみたいなチェックアウトするとロックされる糞システムでも使ってるんだろ。
で、ロックされたまま長期海外旅行されると困るのでチェックインしておけ
っていってるんだろ。

バグのこしたままチェックインされたほうが迷惑なんだがな。


754 :仕様書無しさん:2006/07/28(金) 07:11:20
>>712
> >>709
> VSSやCVS使っていても、しっかりとした管理者が目を光らせていないと、まったく意味がないということだな。
> なんか入れることがほとんど目的になっている部署があるし。

そこでSubversionを使えっていってるわけだが。

VSSなんぞ論外。

Subversionならバイナリ差分アルゴリズムによりバイナリファイルの差分も取れるし
ファイル名の変更、移動をしてもちゃんとバージョン管理されている。

CVSはそれができないから糞。

755 :仕様書無しさん:2006/07/28(金) 07:13:49
>>692
お前みたいな馬鹿個人はつかわないほうがいいな。

俺様のチームに加わるならSubversionは徹底的に
使わせて貰うが。


756 :仕様書無しさん:2006/07/28(金) 07:19:03
>>679
JVMバージョンも明記されたMavenのpom.xmlもリポジトリに
一緒に追加しておけ。

ただし、settings.xmlはリポジトリには一切追加するなよ。
あれはそれぞれ個人で保有しておくものだからな。



757 :仕様書無しさん:2006/07/28(金) 07:19:42
>>675
FatJarでも使っておけ。


758 :仕様書無しさん:2006/07/28(金) 07:19:58
>>674
Jarsでも使っておけ

759 :仕様書無しさん:2006/07/28(金) 07:22:50
>>670
VSSしか使えないお前のプロジェクトに問題があるようだな。
Subversionのように差分だけチェックアウト(というより"Update"だが)
されるならそうはならんのだが。


おっと、VSSのチェックアウトとSubversionのチェックアウトは意味が違ったか。

VSSだとプロジェクト全体をチェックアウトするとすべてチェックアウトした奴の
権限になって他者にはロックされるからなw



760 :仕様書無しさん:2006/07/28(金) 07:25:06
>>667
いや組織でそんな考えで
バージョン管理システムを使われては困る。
自分のソースコードを自分専用に
管理するときだけ使うなら解るが。

それでも使い方がわからないやつに使わせると

プロジェクトに.vssというファイルやCVS、_svnというディレクトリができて
かなり迷惑だが。

それでパッケージ名にCVSや_svnと名が付くものができたりしてな。

ANtやMaven, Eclipseなどを使っていれば問題ないことだが。

761 :仕様書無しさん:2006/07/28(金) 07:26:27
>>662
お前の脳みそはもっと腐っとるよ

762 :仕様書無しさん:2006/07/28(金) 07:27:38
>>661
EJB3.0でお前は幸せになれる。
代わりにHIbernateやSpringやSeasar2で幸せになれるかもしれないが。


763 :仕様書無しさん:2006/07/28(金) 07:28:49
>>657
> >>653 antはやりたい機能ごとにいちいちタスクの使い方を覚えなきゃならんのが面倒
> しかも痒いところに手がとどかな一つーか、ちょっと凝った事をやらせようとすると
> 結局自分でantタスクを書かなきゃならんので余計に手間がかかる気がする
> mavenは単なるオナニー

お前が使いこなしてないだけだよ。


764 :仕様書無しさん:2006/07/28(金) 07:30:40
>>639
VSSなんか使ってるからそうなるんだよ。
CVSかSubversionに切り替えろ。
無駄な作業が減るぞ。

765 :仕様書無しさん:2006/07/28(金) 07:32:56
>>625
まるでコンピュータを使う者は素人で
そろばんを使う者が玄人だと主張してるかのような
愚かな発言だな。

766 :仕様書無しさん:2006/07/28(金) 07:37:28
>>613
お前がJava嫌いなことはわかった。
だがこのスレはJavaスレじゃないんだよ。
お前はVSSの話題を持ち上げようとしてるようだが
VSSなんぞバージョン管理ツールとして最低のブツなんだよ。

バージョン管理ツールの評価
Subversion >>>>>>>> CVS >>>>>>>> VSS

この構図に変わりは無い。

お前のレスを見ていると、
Javaのあら探しをしようとしてお前は
VSSの欠点を露呈してばかりでかえってお前を不利な立場に追い込んでいる。

お前は間抜けだよ。

767 :仕様書無しさん:2006/07/28(金) 07:39:26
>>598
VSS厨あがりの糞厨にSubversionを
使わせてもプロジェクトの管理でろくなことがないな。

悪いけどお前みたいなのは即クビだわ


768 :仕様書無しさん:2006/07/28(金) 07:42:18
>>564
お前なんぞ、ワイパーを壊して
かわりに蠅叩きでもつけてる馬鹿だろw

769 :仕様書無しさん:2006/07/28(金) 07:50:00
VSSが糞なのは同意
CVS使いはじめて8年くらいになるがそろそろSubversionに移ろうかな

770 :仕様書無しさん:2006/07/28(金) 08:20:22
スレを流し読みしてみると
バージョン管理ツールを否定してる奴が
未だにいることが信じられないな。

以前書いたソースコードをどこかにとっておいて
無駄に重複したコードが増えてしまうやり方でもしてるんだろうか。

ソースコードを修正するたびに毎日毎日圧縮保存を繰り返すなんて
アホ臭い作業でもしているんだろうか。



771 :仕様書無しさん:2006/07/28(金) 12:31:39
>>364
IBMはDeveloper Worksでバージョン管理の記事を書いてるくらいだから
使わないと恥だろw

772 :仕様書無しさん:2006/07/28(金) 12:34:36
>>308みたいは香ばしい馬鹿は始めて見た

773 :仕様書無しさん:2006/07/28(金) 12:36:07
>>298
リポジトリをDBみたいにdumpで差分バックアップを
とっておけば無問題。

それでも怖いならミラーリングなりしておけばいい


774 :仕様書無しさん:2006/07/28(金) 12:48:31
>>121
最近じゃ種種のオープンソースのプロジェクトも
CVSからSubversionに移行しているところが増えている。
Apacheのプロジェクトとか


775 :仕様書無しさん:2006/07/28(金) 12:51:01
>>87
Bugzillaのようなバグトラッキングのことか。
それはバージョン管理とはまた別。


776 :仕様書無しさん:2006/07/28(金) 12:52:33
>>76
だからCVSやSVN使うときは
まず最初にUpdateを必ず実行してから
Commitする。

マニュアルにもまず先にUpdateを実行しろと書いてある。

777 :仕様書無しさん:2006/07/28(金) 12:53:05
>>71
Fedora Coreを使えばyumだけで簡単にインストールできる。

778 :仕様書無しさん:2006/07/28(金) 12:58:06
>>745
とれないでどうする。
バックアップできないとかどんな糞システムなのか。

SubversionではまるでDBのようにリポジトリを差分dumpできるぞ。


779 :仕様書無しさん:2006/07/28(金) 13:01:58
>>749
そもそも並び順変えられても困るようなプロジェクト管理してる
逆ギレしてる奴の管理能力に問題があると思うんだが。

関数の並び順変えたらわけわからんって
関数にちゃんとコメント書いてないか
無駄な似て非なるゴミ関数が乱立してるか何かだろ。
関数の名前も変なわかりにくい名前にしているとかな。

クラスやパッケージの中にまとめて分割統治してしまえば
そんな混乱も避けられるだろうに。

780 :仕様書無しさん:2006/07/28(金) 13:03:05
>>769
cvs2svnでさっさと移行汁

781 :仕様書無しさん:2006/07/28(金) 13:11:11
Subversionってだいじょうぶか?
オプンの得意技で動作不安定デグレしまくりとかないだろうな。

782 :仕様書無しさん:2006/07/28(金) 13:15:19
おい、はやくパンチングの作業に戻るんだ!

783 :仕様書無しさん:2006/07/28(金) 13:17:18
すでにかなり安定してるよ。
BDB使ってる頃はリポジトリが壊れる事も多かったがFSFSにしてからは
うちの会社で今のところそういう不具合は起きていない。

つーか既にリリースしてからだいぶたつし、バージョンも1.3.2まで進んで
その間も継続して改良&バグフィックスがなされている。

もうそろそろ、かなり用心深い人にも勧められるぐらいになってきたと思うけど。

784 :仕様書無しさん:2006/07/28(金) 13:35:49
>>781
CVSと比べたら全然いいんだけど。


そんなことより、
動作不安定がオープン系の得意技?
何言ってんだこいつ?

785 :仕様書無しさん:2006/07/28(金) 13:41:57
>>752
>>753
VSSは多重チェックアウトが出来るわけだが

786 :仕様書無しさん:2006/07/28(金) 14:20:08
正直VSSは使い方がよくわからん
Subversionのほうが直感的だと思う

787 :仕様書無しさん:2006/07/28(金) 15:00:11
VSSはVisualStudio統合で使って初めて真価を発揮する

788 :仕様書無しさん:2006/07/28(金) 16:31:46
MS製品はMS製品で固めないと使いづらいってのはあるよなあ。
781みたいにオプソをやたら敵視する人がいるけど、オプソだと
使い勝手のいいのを自分で組み合わせられるってのは
ものすごい利点だと思うんだがな。
MS製品だけでなく、他の売りもんでも
動作が不安定なものはいくらでもあるわけだし。

789 :仕様書無しさん:2006/07/28(金) 16:34:17
MS製品はとりあえずポン入れするだけで全部揃うから楽っちゃ楽

790 :仕様書無しさん:2006/07/28(金) 16:39:53
VSSを本格的に使いたかったら
いくらかコストをかけないと逝けなくなる。
組織内でのアップグレード費用も馬鹿にならん


791 :仕様書無しさん:2006/07/28(金) 21:45:02
Java屋はライセンス費を払えない貧乏会社が多いのか。。。

792 :仕様書無しさん:2006/07/28(金) 21:53:34
単に費用対効果の問題だろ

793 :仕様書無しさん:2006/07/28(金) 23:06:52
バージョン管理ツールなら、NeoSteel社製のものが最高
https://www.neosteel.com/neosteelshop/shop/extras/index.cfm?fuseaction=start

あっ、バージン管理ツールの間違いだった。 てへっ!

794 :仕様書無しさん:2006/07/29(土) 07:56:40
>>791
今どきそんな煽りをする奴は
演歌歌手のコンサートに行く金も無いのかと
言ってるようなほど格好悪いぞ。

795 :仕様書無しさん:2006/07/29(土) 08:09:59
同様の効果が得られるなら安い方がいいよね
それをわざわざ高い方を購入するのは無駄遣いでしかないじゃん

796 :仕様書無しさん:2006/07/29(土) 09:18:22
■Java屋はソフトウエアはみんなただという恐るべき感覚
私の取引先のJava屋さんなんですけど、秀丸、Windows98
(アクティベーションがないからいまだに利用),Office2000
(同)のライセンスが必要な製品までフルコピーで使っています。
ソフトウエアはみんなJDKやEclipseと同じと思っているようで
正直恐ろしいです。

797 :仕様書無しさん:2006/07/29(土) 10:10:30
一部を見ただけで全てがそうだと決め込む考えは
確かに恐ろしいですね。

798 :仕様書無しさん:2006/07/29(土) 10:12:33
java屋だってそのまわりのDBは金がかかるのが多いからあんまり安いって感覚はないだろうな。

799 :仕様書無しさん:2006/07/29(土) 10:50:45
秀丸をフリーソフトと呼ぶ奴はむしろPHP坊だろw

800 :仕様書無しさん:2006/07/29(土) 11:51:32
つpostgreSQL

801 :おじゃばさま:2006/07/29(土) 16:58:08
>736

>インスタンス作成ってことは、そのクラス定義のヘッダをインポートして
>いるはずだから、まずコンパイル時に「インクルードファイルが見つから
>ない」エラーが起きる。仮にヘッダのみがあって単体でのコンパイルでは
>エラーが起こらなくても、リンクエラーで判る。

何言っているかいまいち分からないけど、Javaの話でいいんだよな。
で、クラス定義のヘッダって何?あとインクルードファイルって何?あとリンクエラーって何?
C++と間違えたのかな?

で、737が言うように「JavaでインタフェースとClass.forName」を使った場合の事なんだけど、
738がまた何か言っているんだけど、「736=738」なのかな?
738は「引き数なしや、シリアライズされたクラスは、Class.forName」が使えないとか言っているのかな?
言っている意味が分からないので、できれば説明して欲しいのだが。


802 :仕様書無しさん:2006/07/29(土) 20:19:37
XMLを修正するためにJava屋にある秀丸を起動すると
「わたしは相当つかいこんでいます・・・」のダイアログが出る。

803 :仕様書無しさん:2006/07/29(土) 20:27:51
>>802
秀丸だけどフリーソフト公開して作者にメール出せば無料でライセンスとれるよ
なんでそうしないの?

804 :仕様書無しさん:2006/07/29(土) 20:43:56
そのJava屋とやらに言わんと話にならんでしょうに
なんで>802にレスするの?

805 :仕様書無しさん:2006/07/29(土) 20:48:23
ネタだから

806 :仕様書無しさん:2006/07/29(土) 21:05:10
>801
> 言っている意味が分からないので、できれば説明して欲しいのだが。

こういう馬鹿が一匹でも混じっていると、全体ビルドでクラスの整合性が
とれなくなるわけだな。(w


807 :仕様書無しさん:2006/07/29(土) 21:26:23
>>796
Javaを使う者全員がそうだと言い切る根拠を示してから
そういう断定的表現を使うんだな。

そのOfficeはOffice2.0の間違いかね。
OpenOffice2.0はタダで使える。
今どきWindows98を使って開発するくらいだったら
Fedora Coreで開発した方が効率が良い。
秀丸もそれこそEclipseやEmacsで十分だろう。



808 :仕様書無しさん:2006/07/29(土) 21:28:09
>>802
学生なら>>803のいうように、学生の特権として
作者にメール送れば
送金免除できる方法を教えてくれる。
非常に簡単だがな。

809 :仕様書無しさん:2006/07/29(土) 21:28:57
さて、バージョン管理とは関係ない話題で話を
そらそうとする馬鹿が現れたが、話を戻すとするか。

810 :仕様書無しさん:2006/07/29(土) 21:29:27
Subversionの隠しファイルは.svnから_svnに変更された。
これはドトネト厨の都合を考慮してのことらしいな

811 :仕様書無しさん:2006/07/29(土) 22:17:49
>>810 変更じゃない。選択可能。デフォルトは .svn 。

812 :仕様書無しさん:2006/07/30(日) 00:59:16
Java屋がWindows98SEにこだわるのには理由がある。
ファイルサーバに使うのだ。10接続しかできない
Win2K, XPではだめなのだ。セコイヨナJava屋。

813 :仕様書無しさん:2006/07/30(日) 01:03:22
わざわざWinを使う理由が不明

814 :仕様書無しさん:2006/07/30(日) 02:10:29
ところで、今職場でJavaの開発にcvs使ってて、
subversionの導入を検討してるんだけど、
subversionの積極的な導入メリット/デメリットってなにかある?

ソース管理だけなら今のところはcvsでも困ってないんだけど、
仕様書の管理を始めるとバイナリに強いsubversionを、
って話なんだけど。

ちなみにcvsでも更新せずにコミットとか、
チェックアウトじゃなくてエクスポートして作業とか
そう言うのは割と頻度高し、な職場です。

815 :仕様書無しさん:2006/07/30(日) 02:12:38
そんな話はこっちじゃなくてsubversionスレ@プログラム板

816 :仕様書無しさん:2006/07/30(日) 02:35:36
ちっ、やくにたたねーな。

ちなみにWordやExcelは機能限定的だが、
subversionで版管理して、diffったりもできるぞ。
仕様書の版管理に悩んでる人にお薦め。
ってか誰か人柱になれ。


817 :仕様書無しさん:2006/07/30(日) 02:59:56
>>814 book 嫁

818 :仕様書無しさん:2006/07/30(日) 07:44:03
>>812
アホか。そんな糞OSをファイルサーバに使うなら
LinuxにSamba入れてファイルサーバとしてつかったほうが
セキュリティ上安全だ。

819 :仕様書無しさん:2006/07/30(日) 07:49:36
>>814
過去ログにもちゃんと書いてあるぞ。良く嫁

CVSや糞VSSと違って優位性が決定的なのは

ファイル名変更やディレクトリ変更/移動しても差分情報をバージョン管理できること
つまりプロジェクト単位で管理できることだ。
他にもバイナリ差分アルゴリズムによりバイナリファイルもバージョン管理できることだ。
しかもテキストファイルは行単位ではなく文字単位でバージョン管理できる。


それぞれのディレクトリやファイルにアクセス権限を与えることもできる。



820 :仕様書無しさん:2006/07/30(日) 09:33:32
>>818
漏れもそう思うしそう言ったよ。
彼らの言い分はLinuxにスキルが無いからこれが一番と言っていた。(Win98SE)

821 :仕様書無しさん:2006/07/30(日) 09:41:11
Java房ではないが、Windowsだと通るファイル名が、Sambaで通らない(ファ
イルが作れない)ことがあるんだけど?

822 :仕様書無しさん:2006/07/30(日) 09:43:35
Sambaのマルチバイト変換がおかしく成ることが昔よくあったな。
漏れが愛用しているRedHat8.xはWinのドメインコントローラとの
連携もばっちりだし問題ないけどな。
どのディストリビューション使ってる?

823 :仕様書無しさん:2006/07/30(日) 09:48:19
>822
登録商標記号(丸で囲ったRを使った文字)のファイル名とか通らんよ。


824 :仕様書無しさん:2006/07/30(日) 09:53:44
>>823
それか。その手のはファイル名として使っちゃいかんと思うが。
おぬしはどう思う。

825 :仕様書無しさん:2006/07/30(日) 09:54:56
そういやあ管理ツールに話を戻すがVSSに登録するファイル名に
$文字とか使えない制限があったような気がする。

826 :仕様書無しさん:2006/07/30(日) 09:56:00
使ったらいけないというのなら、
エラーで使えないようになるべき。

827 :仕様書無しさん:2006/07/30(日) 09:56:39
それはオープンソースクオリティ
文句があるならおぬしが直して公開するのが筋。

828 :仕様書無しさん:2006/07/30(日) 10:23:45
文句は無いよw
いつまでもバグが残るだけ。

お前も文句無いんだろ?
こうやって存知のバグが残りつづけるw

829 :仕様書無しさん:2006/07/30(日) 10:26:59
無いよw
ならば見て見ぬふりしれ

830 :仕様書無しさん:2006/07/30(日) 10:28:17
つうような事がオープンソースソース管理プロダクトにも
存在する可能性が高いと言う事を自己責任の元に使いましょうね。

831 :仕様書無しさん:2006/07/30(日) 11:03:11
バグ報告を聞いた人が
直さないからいつまでもバグが残る。
これがオープンソース。

832 :仕様書無しさん:2006/07/30(日) 11:21:51
gyaoでリナックスのドキュメンタリーやってるからお前らもみろ

833 :仕様書無しさん:2006/07/30(日) 11:35:26
>>831
なぜかバグが多発するのにそれをよろこんで使う
Java厨たち。やっぱり貧乏なのが使う理由なんだろうな。

834 :仕様書無しさん:2006/07/30(日) 12:56:49
結局win98seを選んだ奴は正しかったのか。

835 :仕様書無しさん:2006/07/30(日) 13:26:22
>>834
Yes ワラタ

836 :仕様書無しさん:2006/07/30(日) 15:51:03
>>820
JavaができるやつでそんなLinuxできない奴を
Javaアーキテクトとは言わせない。
そういうのはドトネト厨やC言語厨っていうんだよ。

837 :仕様書無しさん:2006/07/30(日) 15:51:49
>>825
絶対パスの先頭に$がついてるから
そういう制限があるのか。

アホくさいな。

838 :仕様書無しさん:2006/07/30(日) 15:53:25
>>827
>>827という返答が>>826に対するもので
>>826という返答が>>825に対するものであるという
リンクがあるなら、お前はVSSはオープンソース製品だと
主張しているということになるが、どうみてもそれはおかしいな。


839 :仕様書無しさん:2006/07/30(日) 15:54:47
>>828
オープンソースだったら目につくバグはすぐ治せる。
むしろM$のほうが自社製品のバグを治せない。

ま、M$もGoogle勢力によって落日を迎えようとしているが。
あのGoogleですらオープンソース製品を続々と出しているからな。

840 :仕様書無しさん:2006/07/30(日) 15:59:51
>>832
おい、どこのカテゴリでどういうキーワードなのか説明しろ。
動画探すのが大変だからURLかキーワードかタイトルか何かで
示せ。



841 :仕様書無しさん:2006/07/30(日) 16:01:43
Win98SE最強説。

842 :仕様書無しさん:2006/07/30(日) 16:02:00
>>831
いや、それはWindowsやM$ Officeを手がけるM$のことだろう。
バグがなかっらウィルスにやられることもないだろうに。



843 :仕様書無しさん:2006/07/30(日) 16:02:30
$とか使う奴とGoogle信仰してる奴って未だに居たんだな
同一レスから抽出できるとはおもわなんだ

844 :仕様書無しさん:2006/07/30(日) 16:02:45
>>833
ドトネト厨が使うドトネト製品群M$製品群のほうが遙かにバグが多いのだが。
どいつもこいつもウィルスに弱いしな。


845 :仕様書無しさん:2006/07/30(日) 16:03:53
>>843
$を使う奴とGoogleを信仰ではなく指示しているのがどういう関係にあるんだと。
Googleを使う奴は皆全員が$を使う奴だとでもいいたいのか?

いっておくが、PerlやPHPを使うと嫌でも$を使うことになるんだが。

846 :仕様書無しさん:2006/07/30(日) 16:05:19
win98se >>>>>>>>>>>> Linux + Samba

847 :仕様書無しさん:2006/07/30(日) 16:07:20
>>845
日本語でおk

848 :仕様書無しさん:2006/07/30(日) 16:10:57
>>846-847は小学生か?

849 :仕様書無しさん:2006/07/30(日) 16:11:07
そう、彼はデブ小学生


850 :仕様書無しさん:2006/07/30(日) 16:11:15
レスが早い

851 :仕様書無しさん:2006/07/30(日) 16:11:28
VSSしか知らないって痛いな

852 :仕様書無しさん:2006/07/30(日) 16:11:49
>>845はファビョりすぎて内容が支離滅裂になってると理解できんらしい

853 :仕様書無しさん:2006/07/30(日) 17:26:15
>>814
Tracが使える

854 :おじゃばさま:2006/07/30(日) 18:59:55
>806
うるせー馬鹿。氏ね。

855 :おじゃばさま :2006/07/30(日) 19:08:35
>>854
偽物乙。

856 :おじゃばさま:2006/07/30(日) 19:32:45
>>855
偽者乙。

857 :仕様書無しさん:2006/07/30(日) 20:26:01
>>852
おまえのほうがファビョッてるとしか思えないんだが

858 :仕様書無しさん:2006/07/30(日) 20:28:10
>>857が本人だからね

859 :仕様書無しさん:2006/07/30(日) 20:48:13
今時M$だなんてUNIX板でも使わんだろw

860 :仕様書無しさん:2006/07/30(日) 21:35:01
「がんばれゲイツ君」とか喜んで読んでそうだな w

861 :仕様書無しさん:2006/07/30(日) 21:53:58
>>859
そりゃそうだ。UNIX信者はMSという企業を使うことはないんだからw


862 :仕様書無しさん:2006/07/30(日) 21:54:22
>>860
今だったらウェブ進化論を読むのがお勧めだぞ

863 :仕様書無しさん:2006/07/30(日) 23:45:18
オープンソースアプリがバグ直すの早いのって
まともにテストしてないからだよね。

864 :仕様書無しさん:2006/07/31(月) 00:58:22
                           /i          │
            ,r ''''' -、_,.. -- ..,,__ ,ノ ノ_,.::--、_      │
           i' r''⌒ >`      ´ ミ+ィ-‐-、 ヘ     │
            i !、 /             `ヽ、,},|.     J >>863
             /'` `´      !         Y ,!
            /       i  ,r'ヘ ,!  l  i   ,i   i
         i   ,i'   i | {_ノ /、 l! ,/,i  /}i|   i
          {/  /   i ,/i ,rァ=、,,`ァ/|,i-''´ ノi | |
         /_,. //  i//λ代ツ!l V |トァェ< i //
       ´ ̄| ''´   | ''´.::::.`´   、f代)Vノイ
         /ノ} | |、i !、 ,i  !,___,.、′´::"ク |
          /イノ !|.!ノ`` i l  .i'  i"´ ノ,,イヘ
              ,| ヽ、 U ∧!-‐、ノ    人!
           _,-'' .!  `ー /`ヾャー'__,,.-ニ_
       ,.:-''´  -...,_   /    ̄  `メ、
       /          `''-/        '}>__\


865 :仕様書無しさん:2006/07/31(月) 01:19:14
>>864
なんかそのツールでこさえたAAってごちゃごちゃしててなんの絵かさっぱりわからん。

866 :仕様書無しさん:2006/07/31(月) 01:23:24
       ,.:-''´  -...,_   /    ̄  `メ、
       /          `''-/        '}>__\
      /      /    /   -、 i フ'´ ´   ̄` '' ー- 、
    i      /.;'   ./      `i"`-、_            `ヽ、
    !        レ   /        i   `ヽ、       :::::f'' ェ_
     !       /    .!イレv,_   ,、ノ!}       \         ::::::ゞ ,!
      \   |     "|   `´fV/)         ',           ::::::::i
       i   !      'i   ,!:;:::;.:.          ;            l
         !   !      ノ  r';:ソ、:i::.:           :             !
          !   ヽ、_ _ノ'   ゞ' ノ:::          ;             ,!
        !     r       /              !         /
           \       、-!             ,ム_       /
             !\ r-、,,___V^''ー--.....,,_    ノ  `'' ー-‐''´ !
          ヘ 「入i'´     `      `"ヾ´         /
            ヘ\ `ヽ、__,,      _ ヽ二_        _ノ
              〉 `ー----――-=、 ヽ三ヽ  ̄`''ー-‐''T"
          /                 `ヾ          i
         /                           i、
          /                       _,         ヘ
        /                        /"゙`       ヽ
      /                                   ヘ
    /                                   i

867 :仕様書無しさん:2006/07/31(月) 11:31:45
>863
新たなバグが埋め込まれるのも早い。そして、完成前に飽きられてプロジェ
クトが放棄されるのも早い。オープンソースと称して、実用に耐えない
シロモノに税金を投入して溶かすのも早い。

868 :仕様書無しさん:2006/07/31(月) 13:10:58
>>863
そういうことを「オープンソース」でひとくくりにすると簡単に論破されるぞw

M$はM$という一組織とはいえ、オープンソースには様々な組織があるわけで。
まともにテストしてないところや頻繁にテストしてるEclipseやApacheなんてものがある。
まともにテストしてる組織のほうがバグ修正は早いぞ。
M$と違って開発者やテスターが何倍もいるんだからな。




869 :仕様書無しさん:2006/07/31(月) 13:12:32
>>866
よくわからない絵だ。
首無し人間か?

870 :仕様書無しさん:2006/07/31(月) 13:15:13
>>867
それはオープンソースではなくM$のことだね。

ま、そのM$もオープンソース製品を作っているわけだがw

それに気づかずにVSSマンセーしてオープンソース批判するのは
恥ずかしいぞw

871 :仕様書無しさん:2006/07/31(月) 17:46:31
>870
一言も、VSSマンセーなどと言っていないのに、自意識過剰のオープン
ソース房はこれだから始末が悪い。第一、オープンソースと違って、
マイクロソフトは税金を一銭も溶かしたりしていないわけだが?

872 :おじゃばさま:2006/07/31(月) 19:18:14
854が本物です。
リンク厨の技法を真似て書いてみました。
あまり面白くなかったので、次回からは普通に戻します。


873 :仕様書無しさん:2006/07/31(月) 21:39:33
うっせー どうでもいい

874 :仕様書無しさん:2006/07/31(月) 22:21:49
M$工作員ウザイ

875 :仕様書無しさん:2006/08/01(火) 00:36:16
何十年前の人間かと思うぐらいレガシーなのが湧いてるなw

876 :仕様書無しさん:2006/08/01(火) 01:15:17
「M$」という文字列を見るだけで、
そのレスを読む気が失せるよな。

877 :仕様書無しさん:2006/08/01(火) 11:54:01
ファイルロック少人数ベースのRCS ← V$$の今ここ!
 ↓
多人数同時編集のCVS
 ↓
フォルダの変更追尾のSVN

878 :仕様書無しさん:2006/08/01(火) 11:57:06
>>871
今までのお前のレスを見ていると、VSSマンセーの匂いがするんだがなw

まだ何もわかってないな。
マイクロソフトがとある自社製品をsourceforgeに
公開したことを知らないとはおめでたいなw

879 :仕様書無しさん:2006/08/01(火) 11:57:44
>>876
臆病だな
VSSでファイル名に$が使えないからとそう僻むなよw


880 :仕様書無しさん:2006/08/01(火) 11:58:27
>>877
V$$ワロタ
ファイル名やディレクトリ名に$が使えないだけのことはあるわなw

881 :仕様書無しさん:2006/08/01(火) 12:04:48
おまいら、ここにも遠征してやってくれ。

>Visual Source Safeに萌える香具師の集い
>ttp://pc8.2ch.net/test/read.cgi/tech/1091615427/l50


882 :仕様書無しさん:2006/08/01(火) 12:22:28
M$ドトネト厨はエロ画像管理にVSSを使ってるのか(嘲笑


883 :仕様書無しさん:2006/08/01(火) 12:22:54
しかもバイナリファイルの差分も取れない癖にVSSでエロ画像管理してるw

884 :仕様書無しさん:2006/08/01(火) 13:38:54
エロ画像をバージョン管理する必要性がよくわからん俺ってやっぱDQN?

885 :仕様書無しさん:2006/08/01(火) 14:01:22
童貞

886 :おじゃばさま:2006/08/01(火) 21:03:49
つまり「バージョン管理ツールは必要」って事で決着か。
きれいに収まったな。

887 :仕様書無しさん:2006/08/01(火) 21:39:01
画像の比較ツール程度なら簡単に作れそうなんだけどな。

複数バージョンのファイルを読み込む

エンコードして単なるビットマップ形式に変換

ピクセルごとに比較して差分の表示

実は、既にウチのグラフィックチームから要望が上がってるんだが
面倒なので無視し続けてる俺ガイル・・・

888 :仕様書無しさん:2006/08/01(火) 21:41:15
少しでも拡大縮小移動してたらダメじゃん

889 :仕様書無しさん:2006/08/01(火) 21:50:42
比較して何を差分としてだしてほしいのかで難易度が大幅にかわるな。
α要素の有無だけを判断するとか画像の拡大縮小は無視とか、
圧縮形式の違いも無視とか、正直詰めるとっていうかアリガチなフォーマットに対応するだけで
ゲーム1本作るより面倒そうで嫌。
アドビ社でも入れてもらえるんじゃねぇの?

890 :仕様書無しさん:2006/08/01(火) 23:47:45
>>887
その画像比較ツールならすでにTortoiseSVNにはついているぞ。

891 :仕様書無しさん:2006/08/02(水) 00:04:10
>>890
1.4.0 からね。まだリリースされてない。 Nightly Build で見れる。
比較できるのは Windows で普通に見れるファイルだけね。

892 :仕様書無しさん:2006/08/02(水) 12:41:30
やっぱり昨日見たおっぱいと今日見たおっぱいが同じものか分かるようじゃないと嫌だな

893 :仕様書無しさん:2006/08/02(水) 14:42:56
エロ画像なんて一期一会なわけですよ
エロ動画なんてDLすることに意義があるわけですよ

894 :仕様書無しさん:2006/08/03(木) 00:05:48
あー確かに。画像の移動や回転、拡大縮小はだめだな。
そもそも、それを比較できるツールなんて存在するのか?
画像の特徴を調べて基準点を算出し、それらの位置の変化を読み取って
元の画像からどのように変更されたかを計算で求めるんだろ。

あ゛ー、俺の頭じゃ無理だわ。
つーかこれ作ったら、かなりの値段で売れるんじゃね?

895 :仕様書無しさん:2006/08/03(木) 00:18:58
二次元の静止画像ごときでなぜそんなに必死なんだか。

動画じゃないとつまらんだろ。

いつも同じ向き、いつも同じ髪型、いつも同じポーズ、
いつも同じ恰好の女なんてつまらんだろ。

896 :仕様書無しさん:2006/08/03(木) 00:19:45
>>894
その程度なら画像工学の分野で研究が進んでいる。
なにせ、犯罪捜査に使われているくらいだからな。


897 :仕様書無しさん:2006/08/05(土) 00:20:24
>896
でも、捜査の決め手はいつも密室の取調室での自白だったりする罠。

898 :仕様書無しさん:2006/08/05(土) 00:52:53
自白は重要証拠にはならないよ。
自白どおりのモノが見つかったらそれが証拠になるだけで。

899 :仕様書無しさん:2006/08/08(火) 14:21:48
>>898
モノが見つかってから無理矢理自白させて終わり、なんてこともあったなあ。


900 :仕様書無しさん:2006/08/08(火) 20:14:05
>>899
モノが見つかってその事実を明かさずにモノのあった場所を吐かせたらそれはかなり黒だろ
どこどこにあるのか?Yes/Noだと意味無いが

901 :仕様書無しさん:2006/08/09(水) 15:19:09
今、青果物を日付フォルダ毎に格納するというダサいルールの下で作業している訳だが。
すげーストレス。
バージョン管理ツールがこれほど恋しいとは思わなかった。

902 :仕様書無しさん:2006/08/09(水) 16:47:16
あおくだもの

903 :仕様書無しさん:2006/08/09(水) 23:15:39
それにしてもこの手のツールを頑なに拒絶する人がいるのはなんでだろ?
便利なのに・・・

904 :仕様書無しさん:2006/08/09(水) 23:26:49
>>903
なんでもできるようにしてあるぶん肝心なことをやるのが面倒臭いってのが大きいな。
例えば>>901の例だと昨日の青果物をその前の日の青果物を比べてみたいわけだけど
バージョン管理だと昨日とかその前の日の状態のものを見るのって上げる奴と
見る奴と双方がバージョン管理ツールを使い慣れてないと結構面倒じゃね?

まあ、できないわけじゃないのはわかるけど、ちょっと面倒でしょ?
ソースやクラスの構造を変えてる場合とか具体的にどこがどう変わったのかわかりずらいよね?
データとかを格納する位置とかそのとき使ってたlibやdllのバージョンとかもみなきゃいけないしね。
フォルダに丸々入れてもらったほうが全体的にどうかわったのか見やすい。
必要なものが必要なだけ固まってるってところがいいっしょ。

まあ、俺はバージョン管理にも入れておいてもらってフォルダでもまとめてもらってるけど、
自分でやるの面倒だから。

905 :仕様書無しさん:2006/08/09(水) 23:29:31
シナショウ青果

906 :仕様書無しさん:2006/08/09(水) 23:33:46
せいか ―くわ 1 【青果】
野菜と果物の総称。


907 :仕様書無しさん:2006/08/09(水) 23:52:19
性化物

908 :仕様書無しさん:2006/08/10(木) 00:10:20
>>904
君が知らないなら爆笑だが、知っているなら教えてしまえよ、こんなもんVSSだろうがCVSだろうがSubversionだろうが半日あれば余裕で仕込めるだろ。

909 :仕様書無しさん:2006/08/10(木) 01:11:19
>>904
>ソースやクラスの構造を変えてる場合とか具体的にどこがどう変わったのかわかりずらいよね?
>データとかを格納する位置とかそのとき使ってたlibやdllのバージョンとかもみなきゃいけないしね。
>フォルダに丸々入れてもらったほうが全体的にどうかわったのか見やすい。

フォルダに丸々入ってるほうが差分が見づらいと思うんだが?
もし差分比較ツール使ってるんならバージョン管理ツール使うのと大差ないし。

そもそもバージョン管理ツールだとその都度任意の時点でのを取り出せるんだから、
いちいち全部丸々とっておかなくてもいいってのはわかってんのかな。
もしフォルダでまとめておくとしても cron で回しておけば自動化できるし。

910 :仕様書無しさん:2006/08/10(木) 05:57:55
>>909
>そもそもバージョン管理ツールだとその都度任意の時点でのを取り出せるんだから
これって、そう簡単でもないじゃん。
手間もかかるし。

911 :仕様書無しさん:2006/08/10(木) 06:06:47
毎日フォルダーに入れてるくらいなら、毎日タグ打ちすれば?
全然手間じゃないよ
タグの命名ルールだけはちゃんと決めとけばOK
たとえばB-20060810-01とかね

912 :仕様書無しさん:2006/08/10(木) 06:51:22
>>911
>毎日タグ打ちすれば?
だれがやんの?じゃあ、5人分よろしく

913 :仕様書無しさん:2006/08/10(木) 06:55:32
タグ5人分ですってよ、奥さん キイタ?( ゚д゚)オクサン(゚д゚ )アラヤダワァ

914 :仕様書無しさん:2006/08/10(木) 07:06:38
>>912
5人分って何?
構成全体に対して1回やるだけだぜw

915 :仕様書無しさん:2006/08/10(木) 07:25:27
>>914
5人の作業を見る必要があって、1人1人の状態をとっておきたいんだけど?
構成全体じゃなくて1人分の差分が必要なんだけど。
で、他の人間の更新状態をこっち側で管理できるなにかがあるの?
それともやっぱり1人1人に指示出さなきゃ駄目なの?

916 :仕様書無しさん:2006/08/10(木) 07:31:58
>>915
5人分フォルダーで管理してんの?
共有コードはどうしてんの?
ちなみに全く分かれているならタグ打ちすら不要だけど?

917 :仕様書無しさん:2006/08/10(木) 07:34:08
>>916
いや、5人分わかれてるわけじゃない。
ソースはそれぞれ散りばめられてる。
その中から5人それぞれの更新状態が知りたい。

918 :仕様書無しさん:2006/08/10(木) 07:42:12
他は知らねーけどCVSはコマンド一発でユーザが特定の日に更新したソースの履歴はとれるよ
マニュアル見ねーとここじゃ書けねーけど

919 :仕様書無しさん:2006/08/10(木) 10:02:58
流石はコンマ区切り、こんなことも出来るんだぁ〜φ(・_・。 ) メモメモ

920 :仕様書無しさん:2006/08/10(木) 10:32:41
>919
CSV

921 :仕様書無しさん:2006/08/10(木) 12:28:49
CSV CVS SCV SVC VCS VSC

922 :仕様書無しさん:2006/08/10(木) 13:22:56
V\V フォフォフォ

923 :仕様書無しさん:2006/08/10(木) 19:32:37
各個の作業実績をコード量で把握してるのか?
それ自体が激しく無駄な行為だろ

924 :仕様書無しさん:2006/08/10(木) 22:48:20
>912=915=917
そういう状況で現在フォルダで管理されている5人の更新状況を
お前が的確に把握できているのか激しく疑問。

バージョン管理ツールの必要性を論破しようとして
無理やりありもしない状況をでっち上げてるだろ?

それかぜんぜん管理できてないのに管理できてる気になってるだろ?

925 :仕様書無しさん:2006/08/11(金) 00:32:45
俺は障害票の消しこみしてる時は日付ごとの受け入れフォルダ作るけどな
やっちゃいけないの判ってるが多重分岐をリポジトリに放り込むと直に破綻する

926 :仕様書無しさん:2006/08/11(金) 04:40:40
>>925
多重分岐の意味するところが正確にはわからないが、それはバージョン管理ツールの問題では
ないだろう? バージョン管理ツール使ってなくたって破綻する。むしろより早く。

927 :仕様書無しさん:2006/08/11(金) 09:52:15
この前バージョン管理ツールを使っているやつの
プログラムを見たんだけど、バグばっかりで
まともに動かなかったよ。
これだからバージョン管理ツールはダメなんだ。

928 :仕様書無しさん:2006/08/11(金) 20:20:47





929 :仕様書無しさん:2006/08/11(金) 20:30:07
   バ
  グ
 と
 れ

930 :仕様書無しさん:2006/08/11(金) 20:49:47
駄目なのはお前の頭だよ

931 :仕様書無しさん:2006/08/11(金) 23:06:37
>930

     ,-'"ヽ    
      /   i、       / ̄ ̄ ヽ,      _/\/\/\/|_  
      { ノ   "' ゝ    /        ',     \          /
      /       "' ゝノ {0}  /¨`ヽ{0}     <  ガーン!! >
      /              ヽ._.ノ  ',    /          \       
     i                `ー'′  '.     ̄|/\/\/\/ ̄       
    /                       }.          
    i'    /、                 ,i..          
    い _/  `-、.,,     、_       i          
   /' /     _/  \`i   "   /゙   ./          
  (,,/     , '  _,,-'" i  ヾi__,,,...--t'"  ,|           
       ,/ /     \  ヽ、   i  |           
       (、,,/       〉、 、,}    |  .i          
                `` `     ! 、、\          
                       !、_n_,〉>


932 :仕様書無しさん:2006/08/12(土) 10:54:21
              ツ
           ん             で

 れ

933 :仕様書無しさん:2006/08/18(金) 20:07:22
やぁ、程度の低い香具師が悦び勇んでカキコしてるところはここでつか?

バージョン管理ツールすら使いこなせないなんて...プププ(w

934 :仕様書無しさん:2006/08/18(金) 22:10:58
ファイル共有原理主義者みたいなのは永久に絶滅しない

935 :仕様書無しさん:2006/08/19(土) 01:09:45
で、バージョン管理ツールの導入を促すと、
しつこいくらいに排他制御のこととか、共有ロックとかについて
説明を求められるんだよな。
他所様でもコレ使って上手く行ってるんだから使おうぜ、って思うんだが。

バージョン管理ツールを普及するためには、
イタリア人の場合、さっき美女がCVS使ってますた。
ドイツ人の場合、CVSを使うのが決まりになっています。
アメリカ人の場合、ここでCVSを使えばヒーローになれますよ。
日本人の場合、隣の会社もCVS使ってますよ。

936 :仕様書無しさん:2006/08/19(土) 01:29:34
>>935
前にも書いたけど、このツールって機能を限定してない分、
使いたい機能を使うのがすごく面倒なんだよ。

937 :仕様書無しさん:2006/08/19(土) 07:39:24
>>901
ならば、今すぐ導入すればいいじゃん。

会社でやってなくても自分のマシンにリポジトリ
作って自分だけでやればいい

938 :仕様書無しさん:2006/08/19(土) 07:40:12
>>903
ただの食わず嫌いな連中だよ。
新しいものに対する抵抗。

つまり、連中は変化を恐れている共産主義者どもだからだよ。

939 :仕様書無しさん:2006/08/19(土) 07:41:56
>>904
> >>903
> バージョン管理だと昨日とかその前の日の状態のものを見るのって上げる奴と
> 見る奴と双方がバージョン管理ツールを使い慣れてないと結構面倒じゃね?

んなもん、みんな有名なバージョン管理システムにすでに同梱されているよ。



940 :仕様書無しさん:2006/08/19(土) 07:45:06
>912=915=917みたいな痛い奴久しぶりに見たよ。

941 :仕様書無しさん:2006/08/19(土) 11:41:56
>>935
フランス人の場合、CVSなんて誰も使ってませんよ。
ブラジル人の場合、CVSを使うとサッカーがうまくなりますよ。
中国人の場合、CVSは食べることができますよ。
韓国人の場合、CVSは韓国が起源ですよ。

とでも言えばいいのか?

942 :仕様書無しさん:2006/08/19(土) 13:00:56
>>941のセンスの無さに感動した

943 :仕様書無しさん:2006/08/19(土) 20:41:56
>>904=910=936(=912=915=917)みたいなのが
使いこなせない香具師
っていうんだよな

もしかして、気付いてない?(プゲラッチョ

944 :仕様書無しさん:2006/08/19(土) 20:50:52
>>943
いや、できるのはわかるんだけど面倒にもほどがあるよ。
コンパイラ渡されて「これでなんでもできますよ」って言われてるのといっしょ。
バージョン管理ツールってのは本来どうあるべきなのか?
って議論が全くなされていない不完全な状態がいまなんだよ。

例えば、チェックアウトしたまま帰るのがいいのか悪いのかとかそういうのな。

945 :仕様書無しさん:2006/08/19(土) 20:59:48
>>944
具体的な話をしてみないとツールの導入を頑なに拒むバカと同じにしか見えん。

946 :仕様書無しさん:2006/08/19(土) 21:08:01
>>944
チェックアウトしたままかえるのがどうかの問題を気にするのはVSSのほうだろ。

文句を言う前に、まずはSubversionをよく使ってみてからものを言うんだな。
とりあえずTortoiseSVNを使って見れ、ほれ。


947 :仕様書無しさん:2006/08/19(土) 21:30:51
>>946
はぁ?そういう問題じゃねぇだろ。
お前こそわかっていってるのか?

948 :仕様書無しさん:2006/08/19(土) 21:34:29
とりあえず
- CVS
- Subversion
- VSS
なんかを使い込んでみてから
面倒
とか言えばいいと思う
何もやってみないで/上っ面だけ掠って文句だけ言ってるのは非常に見苦しい
それとも、手取り足とりで教えて貰えないと何もできない、ってか?

949 :仕様書無しさん:2006/08/19(土) 21:49:39
>>948
VSSとCVSを使ったことがあるけど別に俺がいった問題に対して答えが見つかるわけじゃないじゃん。
自分の脳内だけで何を考えてるのか知らんけど、相手のいい分もろくに理解しようとせずに
的外れなレスつけまくってウザイよ。

950 :仕様書無しさん:2006/08/19(土) 21:57:17
>>949
やっぱり Subversion (および同時期に開発されたシステム)は使ったことが無いんだな。
数年ほど古い認識で止まってるんだろ、あんた。

951 :仕様書無しさん:2006/08/19(土) 22:17:35
>>944は運用の問題をいってると思われ
対して>>946機能があるってだけの話
ちょっとは>>944について議論してもいいと思うぞ

チェックインしないで帰る香具師は
次の日もチェックインしないで帰る可能性が高いね
そうすると他の開発者とのソースの乖離がだんだん大きくなって
チェックイン時にコンフリクトを起こす可能性も高まる
このコンフリクトの解消工数も結構馬鹿にならないだろう
そしてこのような行衝突くらいならわかるからいいが
ロジック的に破たんしたりしてバグを埋め込んでしまったりな
そういう様々な可能性を考えると運用の問題は無視できない

一時俺のプロジェクトではCVS変更時に他の開発者に
メールが送られるようにカスタマイズしたことがあったが結構うざい
バージョン管理ツールだけでなく他のコミュニケーションツールの
併用が必要な部分もあると思う
チェックインに関しては基本一日一回
チェックインする前にアップデートしてコンフリクトを解消してから
チェックインするようにした
コンフリクトの解消に時間がかかるようなら
その日のチェックインはあきらめるという運用も必要かもな
それと全体動作を維持管理する体制が必要だろう
一日の最初か最後でテストコードを流すとか
動作確認担当者を決めるとかいろいろあるだろう
>>944はおそらくその辺りを聞きたいのだろうと思うね

952 :仕様書無しさん:2006/08/19(土) 22:18:06
>>949
理解されようとしてるの?

953 :仕様書無しさん:2006/08/19(土) 22:23:50
>>951
そんな問題があっても、バージョン管理ツールを使うか使わないかについては
悪く見ても「使う」≧「使わない」だろ。拒絶する理由としては無理がある。

954 :仕様書無しさん:2006/08/19(土) 22:29:04
>>953
そんなところで思考停止してるからいつまで経っても
万人が使えるツールにまで昇華しない。

955 :仕様書無しさん:2006/08/19(土) 22:31:21
>>953
まあそれには同意
コンフリクトだけでも自動検出できるってのは
バージョン管理ツールの大きなアドバンテージ
ただのフォルダー管理では上書きで潰してしまうからな

それはそれとしてそろそろ運用についても話し合ってみないか

956 :仕様書無しさん:2006/08/19(土) 22:31:57
>>954
Subversion や TortoiseSVN の開発が停止しているとでも思ってるの?
だいたい(以下 >>953 と同文)

957 :仕様書無しさん:2006/08/19(土) 22:34:11
>>956
いや、だから何もわかってないな。
機能があるかどうかの問題じゃないんだよ。

958 :仕様書無しさん:2006/08/19(土) 22:35:17
>>955
運用については各ツールの専用スレでいいだろ。このスレももう終わりだしな。

CVS導入スレ〜 Rev.3
http://pc8.2ch.net/test/read.cgi/tech/1113141518/

Subversion r5
http://pc8.2ch.net/test/read.cgi/tech/1145841405/

959 :仕様書無しさん:2006/08/19(土) 22:37:36
つか、いまのままのバージョン管理ツールなら使いにくいしいらないよ。

960 :仕様書無しさん:2006/08/19(土) 22:37:51
>>957
システムの話なら Subversion, GNU arch, bitkeeper の比較とか。そこらへんの話を追え。
それ見て思考停止してると思うんなら、開発 ML に投稿でもしろ。
もしくは自分でシステムの草案でも挙げろ。それにしても(以下 >>953 と同文)

961 :仕様書無しさん:2006/08/19(土) 22:41:21
>>960は単なるSubversion厨だったか
時間の無駄だったな

962 :仕様書無しさん:2006/08/19(土) 22:42:39
>>951
> チェックインする前にアップデートしてコンフリクトを解消してから
> チェックインするようにした

これって当然のことじゃねーの?

> チェックインに関しては基本一日一回
って制限する必要ないんじゃね?

あと、なるべくコンフリクトしないような開発体制を敷くべき
同一コードを複数人で捏ね繰り回す愚は犯すべきでない

963 :仕様書無しさん:2006/08/19(土) 22:48:35
>>962
君にとっての当然は住人にとっての当然とは限らない
まずは意見を出し合ってみなければね

コンフリクトしない開発体制についてkwsk

964 :仕様書無しさん:2006/08/19(土) 23:29:37
>963
> 君にとっての当然は住人にとっての当然とは限らない
えぇっ、マヂでそれ言ってる?
...ってゆーか、あなた「マ」ではないでしょ?

> コンフリクトしない開発体制についてkwsk
きちんと分業すればいい、って話しでしょ
で、他人の担当箇所で追加/修正が必要な場合はそいつに依頼する、と

...う〜ん、なんか、単なる論客と話してる気がしてきた(汗

965 :仕様書無しさん:2006/08/19(土) 23:38:00
>>964
てか、お前の脳内の常識は俺にもわからんし、
現に開発の中でチェックインは毎日するべきかしないべきかで揉めたこともあるし、
自分の常識が一般の常識とは思わないほうがいい。

966 :仕様書無しさん:2006/08/19(土) 23:59:05
>>965
チェックイン前のアップデートなんてちょっと説明すれば必要性が納得できるだろ。
それが納得できないやつは共同作業自体を否定していることになる。

「チェックインは毎日するべきか」という問題には根拠がないから揉めるのも当たり前。
同じに考えるのはおかしい。

967 :仕様書無しさん:2006/08/20(日) 00:11:20
>>964
もちろんまじでいってる
いろんなレベルの香具師がいるわけだから提示することに意味がある

ではお互いに担当を知ってないといけないということかい
依頼するにしても手順があるだろう
そこで実質作業が停止してしまうわけだしな
その辺りの具体的な手法はどうしてる?

968 :仕様書無しさん:2006/08/20(日) 00:13:36
ちなみに「マ」じゃないといわれたのははじめてだよ

969 :仕様書無しさん:2006/08/20(日) 00:39:30
おめでとう
ついでだしオレからも言ってあげようか?

970 :仕様書無しさん:2006/08/20(日) 00:51:21
>>967
バージョン管理ツールがコミュニケーションまで自動化してくれないと使いたくないってことか。
無理っぽいなぁ。

971 :仕様書無しさん:2006/08/20(日) 08:23:35
>>951
バージョン管理システムをつかうとかえってバグを埋め込みやすいから
使わない方がいいと主張しているのか?
それもどうかね。バグが埋め込まれやすいかどうかはバージョン管理システムを
使うか使わないかの可否には全く関係ない。

チェックインというより、CVSやSubversionの用語にあわせてここでは「コミット」と
言わせて貰うが。

まさかコンパイルが通らないコードをコミットしているわけではあるまい。
XUnitなどのツールでテストが通ったものだけコミットすればなおよい。


剥離、コンフリクト問題を気にしているようだが、
ブランチを知っているか?

行の衝突もマージ機能がある。二つのソースコードを並べて比較するツールもある。


ようは、コミットはこまめにしておけ。ということだ。
最低でも一日に10回はやってるだろう。
XPのプラクティス、ペアプログラミングという概念に倣うならこまめなコミットは当たり前。


972 :仕様書無しさん:2006/08/20(日) 08:25:23
>>968
うむ、おれもとてもおまいがプログラマだとは思えない。

973 :仕様書無しさん:2006/08/20(日) 09:05:03
>>971
そんなのてめぇの勝手な使い方じゃねぇかよ。
実際はコンパイル通るソースだろうが、通らないソースだろうが、
バージョン管理ツールは通しちまうだろうがよ。

974 :仕様書無しさん:2006/08/20(日) 09:05:21
一日中チェックアウトしっぱなしの馬鹿はマに向いていない。
チェックアウトしたまま帰る馬鹿は共同作業に向いていない。

975 :仕様書無しさん:2006/08/20(日) 09:06:23
>>974
それができてしまうバージョン管理ツールってどうなの?

976 :仕様書無しさん:2006/08/20(日) 09:08:41
>>973
致命的なバグくらいはチェックインする前に単体テストで見つけろよ。
それが出来ないなら一人で出来るプロジェクトだけやってたほうがいいよ。
他人に迷惑掛けずに済むよ。


977 :仕様書無しさん:2006/08/20(日) 09:09:13
>>975
そんな常識も徹底できない職場ってどうなの?
猿しかいないの?

978 :仕様書無しさん:2006/08/20(日) 09:14:51
じゃあ、将来的にはバージョン管理ツールはチェックインする前に
それがソースコードならコンパイルを通ったものでないならエラーを出してチェックインできないように
なるのが正しい方向だと言ってる?

979 :仕様書無しさん:2006/08/20(日) 09:16:59
チェックアウトしたままの馬鹿なんて、管理者権限で取り消すだけだろ?
そいつの作業はコミットしてないんだから、別に問題なし。

一番の問題はコンパイル通らないものをコミットして帰るレベルだと思うが。


980 :仕様書無しさん:2006/08/20(日) 09:17:10
>>973,975
そうできないような仕組みを実現する手段はある。
コミット前フックでビルド〜テストケース全パスを条件にするとかね。
現実的ではないから誰もやらないだけ。だれも考えていないわけではない。

現実的なコストで実現可能だというのなら、そういうシステムを提言すればいい。
それができないなら現場の判断に従いやがれ。

981 :仕様書無しさん:2006/08/20(日) 09:21:35
>>980
現状できないことをさもできるように言うなよ。
そんなこと言ったら、コンパイラが入ってるマシンはなんでもできるって言えるじゃん。

982 :仕様書無しさん:2006/08/20(日) 09:23:43
それに修正途中のソースをコミットできないなんて使いにくいだろ。
設定でできるようにしたら今度は人によって設定がバラバラになるわけだから無意味だしね。

983 :仕様書無しさん:2006/08/20(日) 09:31:48
>>982
修正途中のソースをコミット?その考えが矛盾してる。
ファイルのセーブじゃないんだから。
セーブだけなら別にコミットは不要だろ?ローカルPCのHDDには存在するんだから。

984 :仕様書無しさん:2006/08/20(日) 09:58:54
なんか、バージョン管理ツールの使い方を(ワザと?)履き違えてる香具師がいるみたいね

運用については
- コミット逃げ厳禁
- コンパイルエラー等の明白なエラーが存在するコードのコミット禁止
- コミット前に必ず最新コードとのコンフリクトを解消
ってのが最低限のマナー(常識と言ってよい)かな

985 :仕様書無しさん:2006/08/20(日) 10:03:07
>>984
だから、それを強制できるか否かの議論じゃないのか?


986 :仕様書無しさん:2006/08/20(日) 10:14:05
>>981
できるのが理想だというのに、できると言うと否定するのは、何かおかしくないか?

987 :仕様書無しさん:2006/08/20(日) 10:16:54
C が嫌いなアセンブラ使い。
C++ が嫌いな C 使い。
似たような人はどこにでも沸くねぇ。

988 :仕様書無しさん:2006/08/20(日) 10:29:02
なんつうか、結果が大事じゃなく、自分で作った感、やった感が大事な人っているよね。
言葉を選べば職人肌、普通に言えばおなにい。


989 :仕様書無しさん:2006/08/20(日) 10:40:02
いきなり話の腰を折るねぇ(w

990 :仕様書無しさん:2006/08/20(日) 11:20:18
>>984は正論だな。
バージョン管理ツールはお前の日記帳入れるための机の引き出し
じゃないと言う事


991 :仕様書無しさん:2006/08/20(日) 12:19:35
日曜だというのに自演乙
このまま1000まで逝っちまいな

992 :仕様書無しさん:2006/08/20(日) 14:15:22
>>1は真性Java厨ですからw

993 :仕様書無しさん:2006/08/20(日) 14:42:02
でも実際バージョン管理使ってても
バグ修正した個所を残してたり
ここ修正とかをコードに書きまくってる現状は…



994 :仕様書無しさん:2006/08/20(日) 14:43:35
コードにわざと残す場合はある。
ここをこうやって間違ったら駄目だよとか、ここをこう変えたというのを明示したい場合。
同じミスというか、類似ミスをなくすためにわざとコメントで残す。


995 :仕様書無しさん:2006/08/20(日) 14:45:24
それが大量にあるのもいいのか…

996 :仕様書無しさん:2006/08/20(日) 15:17:35
うちの上司に言わせれば、どんなに便利なツールも、その必要性や使い方の理解が出来ないやつらが大半で、
その教育のためのコストを払うことができないから、ツール使用禁止だそうだ。



997 :仕様書無しさん:2006/08/20(日) 15:27:27
>>996
じゃあPC使うのやめちゃえよ。

998 :仕様書無しさん:2006/08/20(日) 16:07:54
PCはともかく、コンパイラはおろかIDEも禁止だな。

999 :996:2006/08/20(日) 16:33:31
いや実際、とあるプロジェクトでおいらが開発環境作ることになって、
CVS+eclipsな環境と使い方のマニュアル用意したんだが、
上司をはじめとした全メンバーの拒絶にあったのさ。
でも鯖上のマスターソースを上書きデグレ(もちろん復帰できない)するのは当然だし、コンパイル通らないソースばっか。

幸い漏れはスポットのヘルプだったからとっととにげたけどな。

1000 :仕様書無しさん:2006/08/20(日) 16:34:10
1000

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

251 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)