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

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

>>1　SVNが入っていない時点で終了。
いまどきCVSとかVSSなんてありえね（ﾌﾟｹﾞﾗｯﾁｮ

ツールがどうこうの前に人間系のルールを決めないと意味がない

この手のツールは結局
人がルール守らないから強制させる為の物

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

>>2のレスで思い出したけど、
そういやプロジェクトがSVNに変わるんだった。

良スレage

チーム開発じゃなくても十分に役立つんだけど、
一人でやってるからそういうの無意味だよ、とかって言う人、
たまに居るよね。

一度も使ったこと無い人ね。

ソースコードにもよるんだろうね。
１つのソースをみんなで突かない限りバッティングすることは無いわけだから
いらないっていう現場があってもおかしくないでしょ。

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

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

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

>>9
そりゃ、実験的なことをするためにブランチ切ったり、バグフィックスと機能強化を並行して
行ったりしない単純な開発だけやってりゃいらないかもな。

まだ必要性を論じている段階なんですか、って感じがする。

>>10
別にそんなの当り前の話で単純とか複雑とかいう話にはならない。

ソース1本ならバージョン管理ツール要らないって・・
バッティング解決のためだけのツールじゃないんだけど・・。
もしかしてソフト改修の度に修正箇所をコメント化して残したり
丸ごとファイルコピーしたりしてるの？

>>13
いや、そもそも改修作業に対するドキュメントの整備が義務化されてないから
そんな手間はいらない。

改修作業をコードの書き直しだけと思ってる奴も居るくらいだからな
テスト位やれよ

>>15
でも、前との差分とってどうにかなる改修なんて結局前の差分なんていらんし。
そういう既存のソースをいつまでもとっておく会社って糞コードになってるところ多いじゃん。

#if 0
/* 元が酷いので修正 */
（コード…）
#endif

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

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

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

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

一人であっても、普通に「どの時点にでも安心して戻れるアンドゥ」のためのツールとして
便利だよな。

VSS何とかして欲しい点

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

>>18
アンドゥ自体そんなしないし。
するとしてもエディタのアンドゥ以上の機能必要ないし。

>>19
ＶＳＳ何とかして欲しい点：追記

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

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

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

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

>>22
てか、昔のソースなんて残しておく必要ないよ。
昔、どうなってたか、なんて確認する必要ないって。
いつ確認する必要がでるの？
それって誰かが「あのときは動いた」って主張してるときだけでしょ？
そんなのつい最近のことじゃん。
しかも、差分比較してわかるような内容なら昔のソースなんてみなくたって原因特定できるって。

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

>>22
で？
君がバージョン管理ツールが必要だと主張する理由がかかれてないのは叩かれたくないからかな？ｗ

>>23 君みたいな人のためだよ

>>20
リファクタリングしてるうちに訳わかめになって、
前に戻すときには非常に便利。

>>26
そこまで戻す必要に迫られないｗ

>>24
22の文章だけでも、バージョン管理の利点が理解できないPGがいるとは思わなかった。
ちょっとこのスレのレベルを甘く見てたな、すまなかった。

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

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

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

逆になぜバージョン管理を拒む人がいるのか、わからない。

>>23
仮に、一週間以上前のバージョンを残す必要がないと仮定して。
一週間あれば、内容にもよるけど延べ10〜100ファイルぐらいは
コミットすることが出来ると思うんだけど、
その間のバージョン管理はどうするんだ？　手で頑張るのか？

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

>>29
ネタ

>>27
過去に安心して戻れることが保証されていると、派手にリファクタリングしまくれる。

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

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

フロッピーディスク持って各担当者のプログラムをかき集めて再構築してた頃に比べりゃ、天国だろ。

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

ヴァージン管理ツール

>>34
ガードは堅いですか？

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

>36
仕様変更されてAさんが修正した。Aさんは契約切れでいなくなった。
2週間後に「やっぱりこの前の仕様変更はなし。元に戻して。」って言われたらどうする？
ちなみにAさんはその仕様変更以外にも修正してるし、連絡は取れない。

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

古いソースをコメントで残す事がなくなった
思い切った改修が出来るようになった
動作がおかしくなったら正常に動くリビジョンまで戻ればいいし
本当に便利

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

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

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

A -> B -> C -> D

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

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

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

つまり、

A -> C

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

って可能でしょうか？

そりゃ、CVSなんてリビジョン間の差分情報で管理してるし、
サーバーからローカルにチェックアウトするときは、
ローカルの変更生かしたままで差分情報をローカルに加えて最新ソースにするお。

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

>41が言ってることはいまいちわからないが

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

B が機能追加じゃなくて機能削除だったとしても大丈夫かなぁ

>>40
Bでの修正の中に間違いが発見されて、それを修正してCにした場合は、どうしたらいいんだ?

>>44
どうしたらいいですか？

どのリビジョンにも行ったり来たりできなかったっけ？
俺はやってたつもりだったんだが

>>46
どのリビジョンでも行き来出来るのはもちろんだけど、
特定のリビジョンだけ取り消して、その後の変更は残すなんてのは
人力が必要か、という話ではないのか。

それは確か無理だよね
履歴を取り消す行為自体がバージョン管理に反する

>>48
ツール上の履歴を取り消したいという話ではないから
バージョン管理には反しないのでは？
もう一回>>40読んで話の流れをつかんでくれ。

BとCが独立かどうかによる
と言ってしまうと元も子もないが
そもそも独立かどうかが分からないことが多いかな

普通に、Ａ→Ｂ　の変更点とＢ→Ｃ　の変更部分を見ながら手で修正だろ。
WinMergeのようなビジュアル差分エディタがあれば変更点を色付きで表示してくれる。
あとはソースを見比べながら「ここは必要」「ここは不要」と選んでいくだけで作業完了。

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

できるか、できないかを聞きたいだけなのに、
いきなり頼まれもしてないのに、わざわざやり方を披露しはじめる人って馬鹿に見えませんか？

しかも、わかってることを。

劣等感丸出し

もし B と C が独立なら、そもそも
A -> B -> D
A -> C -> D
というパスが可能なはずで
そういう管理が可能かどうかという話が出来るんだけど

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

SCM知らない奴って、拒否反応を示すか逆にへんな幻想を抱くかのどっちかだよな。

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

んなわきゃねーだろ！！

つか、Ａの上にＢがあって、Ｂの上にＣがあって、Ｃの上にＤがある構造なのがバージョン管理。
だからＢを抜いてＣが存在すること自体不可能だと思われ。

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

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

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

まあ普通に考えればどだい無理な話だわな

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

ここ10年のCSで一番進化が遅れているのがCVSかも試練

よく言えば枯れてる
それが不満ならSVNがあるだろうに

SubVersion（SVN）いいね。
と言っても、自分はちゃんといろんな機能使ったことはないけど。

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

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

clear case はどう？

ドキュメント関係はVSS、ソースはCVSかSVNが良いと最近思う
ワードやエクセル等の差分を見れるツールってないのだろうか

ありますよ

>>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
ようは一旦テキストにしてその差分を表示するツール。
まぁ、これで事足りる人は使えば？ていう程度のものだが。

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

>>66
そんな微妙な動作ごちゃごちゃ覚えなきゃいけない時点で返って手間が増えてる希ガス。
なんかもう１週間ごとにみんなのもってるソース丸ごとコピーでいいよ。

原始人あらわる

毎日、バックアップしてます。
ソース入ったフォルダごと。

OSのファイルシステムが進化してくれれば、まるごとバックアップでいいんだよな。
とりあえず、コピーしても時間がかからなけりゃいいし、
もうちょっとすすんで、何からコピーされたか情報がのこってくれるといい。

SubVersionをLinuxにインストールする段階でくじけた

>>70

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

手作業で行うとミスがあるし
060709.zipとかのファイルが延々と増えていくのも馬鹿らしい

>>73
そうはいってもあんまりでかいとＶＳＳとかってハードディスクに入りきらないとき面倒なんじゃね？
小さいプロジェクトとかソースだけとかならハードディスクにはいるだろうけど。

そんならなおのこと丸ごと保存するのは馬鹿らしいだろうに
バージョン管理ツールは差分で管理するからサイズも小さいよ

CVS、SVNで競合無視してオーバーライドとかする奴がいると泣きたくなる

>>75
いや、丸ごと保存の場合はzipにまとめて日付だけ気をつければいいけど、
ＶＳＳの場合ハードディスクってわけて使えるっけ？
つまり、片方のハードディスクが一杯になったら、別のハードディスクも取り付けて使用可能かどうかだけど・・・。

使用可能です

>>78
マジで？
どういう仕組みなんだ？
ハードディスク３つ目に突入したとして、始めの１つ目が死んだら、
他の２つも平行して死亡なんではないだろうか？実はｗ
なんつーか、ソースとデータでわけたいな。
ソースはハードディスク１つあれば十分過ぎるけどデータがでかい。無駄にデカイ。
差分を保存とか効かないし。
始めにわけなかったから共倒れ状態だな。

そうはいってもzipで丸ごと保存する方法を取った場合は
バージョン管理の場合に比べて何十倍もの容量が必要になるわけで
そもそもの比較が不適切ではないか？

>>80
いや、そうでもない。
１ヶ月単位でまとめて圧縮かけたりすると圧縮率が結構高くなる。（そりゃ同じプロジェクトだしねぇ）

>>80

0709.zip
0710.zip
0711.zip

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


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

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

>>82
構成管理って保存だけが目的じゃないだろ。
効率悪すぎなんだよ。死ねよ。

あらら、差分管理もできないJavaプロジェクトの厨が暴れてるのか

丸ごと馬鹿な丸ごとzip厨が暴れていると聞いて
駆けつけました。

>>83
いや、保存だけだろ。
他にあるなら上げてみろ。

>>86
トラッキング

>>87
はぁ？

使ったこと無い連中に何言っても判らんよ＞バージョン管理

>>86
バージョン管理という言葉の意味を考えてみ

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

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

……面白すぎるｗ

>>91
え？君、なんか頭悪いだけじゃない？

バージン管理ならやってみたいかも

>>92
ん？　自分はバージョン管理ツールで使ってる機能を思い浮かべて
単にファイルサーバに上げて日付別でバックアップ、となると
実際にどう自分の作業が変化するのか考えただけだけど？
実際かなり不便になりそうに思えるけど、どこがおかしいかなｗ

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

>>80
今時のストレージの大容量化低価格化を考えたら、さして障害になるとも
思えないが。何十ギガバイトもソースがあるわけでもないだろうし。

前の会社でバージョン管理導入して
不便になったという人居なかったけどな

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

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

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

>>94
馬鹿か？
そういう時は変更点も台帳とか作って別途管理するだろ普通

>>96
いや、別にあってもいいけど細かいルール付けばっかりこだわってそれの整備を理由に仕事しない奴がいるのよ。
で、そいつの決めるルールがまたうざくて、正直、もうバージョン管理なんてしなくていいよ。って感じ。

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

>>97
台帳つけるぐらいなら最初からバージョン管理使えよｗ

変更するたびに台帳の奪い合いになるのか〜。
そんな仕事、俺はごめんだし「普通」ではないとおもう。

>>98
それは確かにウザイね、同情するよ

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

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

そんな台帳もつけないでしょ。
ただ、日付があってそれに対応するプロジェクトが保存してあるだけ。
そもそも解凍すること自体ありえないけど。

>>102
てか、そういう決める事項があるだけで奴等のいい口実になっちゃうの。

でも少々うざいのは仕方ないよ
そうやって「啓蒙」してかないと慣れたことしかしないんだし。
否定派は個人目的で良いからまずsubversion入れることを勧める。

スレ違いかもしれんが、今はバージョン管理や構成管理って言うと何があるの？

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

>>105
御利益が「過去のソースがどうなってたか？」ってのが見れるだけじゃん。
見ないよ。
見たいと思ったことないもん。
やっぱり、会社で作業してて「昔はこうだった」って言われたときぐらいしか開くことないって。

>>107
見ないのかよｗ

製品としてリリースしているプログラムで不具合が発生したときに、どのバージョンのものかで再現性が変わるからなぁ。
既知の不具合ならサポセンで完結するからどうでもいいけどさ。

そりゃバージョン管理自体してないなら意味ないわな

うちの会社だと
複数の人間が、同じソースを触ることがあるから更新ミスを防ぐだけでも効果あったよな

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

CVS入れたらデグレが増えるケースってあるよな。
分岐の激しい場合とか特に。

>>112
分岐はつかったことないけど
CVSとかバージョン管理ソフトというより
開発ルールとかの問題と思うなあ

>>97
ヒューマンエラーの事を考えない馬鹿発見ｗ
「他の奴が台帳つかんでるから後にしよう」
とか言って、そのまま更新し忘れる奴が絶対出るだろｗ
バグ発生自体を隠したいとかで、意図的に台帳記入しない奴もいるだろうし。

>>111
バージョン管理システムの最大の利点は、そういう「劇的なミス」を
防ぐことだから、「俺はそんなミスはしない」と思ってる人を説得するのは
ホント難しいんだよね。一度痛い目にあってもわらないと。
（しかしそういう人は痛い目にあっても相変わらず学ばないのだが）

>>115
そうなのよ
「そんなの無くても各人が”注意”してやればいい」
って発想だよな

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

バージョン管理目的で圧縮ファイル残してる奴は
四の五の言わずsubversionインスコするべき

>>115
なんでそんなほとんど問題にならないことに力入れてるの？
こんなとこ問題にならねぇよ。

>>112
自分も分岐はマトモに使ったことはないな。
どういう時に使って、どう管理するもの？

開発してて昔のバージョンのソースをそんなに頻繁に見るのか？

ぶっちゃけ、業務システムみたいに何とか版何とか版ってひたすら分岐していく奴には
SVNのほうが向いている。
CVSはｵﾌﾟｿのように大人数で一つのバージョンに向かって作りこんでいく場合に向いている。

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

>>118
そんなこと言ってると

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

てことになる

>>120

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

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

機械的に管理されるということは人為的なミスを減らすということ
バージョン管理なんて場合によっては致命的なことになるんだし。

その万が一なんてときっていつくるの？
俺は普通に納期に間に合わねぇ自体のがよっぽど多いけど。
一生懸命導入して決めごと確立してメンバーに徹底させるほどの意味ねぇじゃん。

作りっぱなでメンテしないならいらないんじゃね

バージョン管理しつつ、サーバがお亡くなりになった場合にそなえて定期的に
cron等を使ってバックアップを取る。これでいんじゃないか？

なぜか強く抵抗を示す人がいるんだよな。不思議。

>>128
それ（バージョン管理）を仕事にされてたまるか。以上。

仕事はツールがやるもんじゃね

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

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

>>131
はぁ・・・無駄・・・
何をそんなに恐れているのか全くわかんね。
もっと優先度の高いリスクはほかにもたくさんあるだろうに・・・。
自己満足通りこしてキチガイだな。

>>126 俺はまさにそうしている。
ところで、バージョン管理を嫌がる奴ってどんな奴が多い？
俺のところでは、確かめもせずに「〜のはずです」「できません」を
連発して、バグだらけのものをリリースする奴です。

>>129
バージョン管理ツール云々より
おたくんところの導入旗振り役の奴の問題じゃなかろか

>>129の意味がわからない。
バージョン管理ツールを使ったほうが、制作効率が上がるわけだが。

>>132
正直導入すれば幸せになれるものをどうしてそこまで拒むのか判らん

マージうざい。
俺のソースにゴミをまぜるな

○月×日以降にこのバグ出てるみたいなんですけど・・・
⇒そんな時には？

バグなんてなおせばよくね？

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

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

>>135
効率は上がらないでしょ。
バッティングなんて普通しないもの。
過去のソースを見ることも普通はそれほど頻繁にはない。

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

規模も決めずに議論しても仕方ないから必要になる基準を作ればいいんじゃね？

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

>>139
そんなときに○月×日以前と以降の差分を比較してバグの原因を探るんだろ？

>>142
そういう基準を作るのにまたくだらない会議をするのがいる・・・すげーむかつく。

>>141
なら自分で管理すれば問題ないのでは？

>>132　別に、優先度がどうって程難しくないよ。
空いてるPCにLinux＋Apache+SSH+SVN入れてるだけで
cron用の定期バックアップスクリプトも単純だし。

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

パーのためのツールだろ。

>>145
いや、そいつがやりたがるし、「時間とらないでね」っていってるのに
「うーん」とかなんかよくわからんこと悩んでて（おそらくフリ）いつもサボり出す。
いっとくけど仕事割り振ってるの俺じゃないし、自分が勝手にやるとかできないから。
会社に勤めたことあるの？

>>146
その作業に導入と毎日の動作で何分かけた？

>>148
中小なんだよ
悪いかコラ

>>150
てめぇのところはバージョン管理なんてしてる場合じゃねぇだろ。タコ。

>>151
バージョン管理で地獄見たから忠告してるんだろボケ茄子

EUCとSJISが混在してるとうざい。

>>152
はぁ？バックアップなら手動で十分だよね？
あくまで「バージョン管理を使わなきゃどうにもならない」理由なんだろうね？

>>152
っていうのはね。
そういううさんくさいものをもってきては自分の仕事にして
毎回それしかやらない奴がいるから。
それを実績にして仕事やったきになられると非常にむかつくんだよね。

一回サーバ構築してしまえば複数のプロジェクトも管理できるし
１，２日程度割り当てても損はしないと思うけどな〜
それ以上かかるようなら別対策立てればいいと思われ
まあ、バージョン管理が嫌いならそれは仕方ない

>>122が実際に起きて
客先はこちらに報告なしでそのバージョンを売ってた
でそのときの納入ソースだと言い張るCDがどう見ても何ヶ月かずれてる

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

>>156
は？なんで３日もかかんの？
１ヶ月２０日しかねぇのになんで３日も使うんだよ。死ねよ。
お前もおれんとこのプロジェクトにいる詐欺師といっしょだろ。

>>149　導入には3日。
メンバーにTortoiseSVNインスコさせて教えるのに1日。
あとは各自が毎日の作業でコミット。右クリックメニューから選ぶだけなので数秒〜数十秒程度。
まぁ一日に10回もコミットすれば多い方だから、せいぜいが２〜３分程度だな。

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

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

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

RCSで十分。CVSは糞。とうか、業務系にはむかない。
オプソで使われてるってだけの理由で新しもの好きのバカが音頭とって踊り出す

>>155
それは特殊な例だと思うんだ。
バージョン管理ツールに罪は無いよね？

>>159
なんだそりゃ、人増えるたびに教えるのに１日使うの？
３ヶ月のプロジェクトがあったとしてトータルで何日使う気？

>>161
でも、導入に３日、その管理でトータル１週間もかけられたんじゃ困るなぁ。

>>150-151
お前ら仲良くしろボケ

>>162
累積すれば毎日のタイムロスのほうがどう考えても大きいだろ
もうお前みたいな分からず屋は勝手にzipでバックアップとってろ

まあ、CVSマンセーな奴もエクリプス無しでは何も出来なかったり

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

>>167
はぁ？どうせそういう強引な理論になるならはじめっから意味ありそうにいうなよ。
どうせ、バージョン管理なんてたいして役に立ってねぇよ。

CVSって、シフトJIS使えたっけ？

結論は必要なしでok？

馬鹿には見えないツールでFA

バージョン管理ツールを使わないで、複数人で作業する場合、
他の人が作業した分の更新の確認とかマージとか、どうしてるの？

>>168
そりゃ、おまえんところの作りっぱなしプロジェクトならそうだろうよ。
そんなとこの引継ぎなんざやりたくねーがな。

>>172
してねぇだろ？ｗ
そんなことｗ
重要でないことをさも重要そうにいうな。ボケ。

>>174
おまえ、しねｗ
この馬鹿

>>173
バージョン管理ツールがあると引継ぎが楽になるんだｗ
はじめて聞いたよｗ
あることないこと言い放題だなｗ

空気読まずに質問。
個人ユーザでも入れとくと便利なもの？
開発機がWindows機1台のみなんだがcvsとsvnってどっちがいいの？
外部に公開する気は無い環境で利用するつもりです。
どっちがどんな利点があるのかとかわかんないから入れたいけど入れれないorz

>>114
そういうプロジェクトだとライブラリアンとか言ってそれ専門の奴が１〜２名付くんだよ
障害管理と一体化されて管理される物なんだ

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

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

>>170
うん、必要なしと思ってる人には必要なしでok

>>177
無条件で死ねｗ

嫌われる原因の一つにWinCVSの糞さと文字コードの問題がある。

>>177
TortoiseSVN
詳しくはぐぐれ

>>177
便利。
今からWindowsで使うならsvnがおすすめ。

>>180
だが断る

>>174 は仕事してないの？

日本語の書籍があるかどうかだろ。

>>177　今からならSVNでおｋ。
とりあえずTortoiseSVNをいれて、適当なフォルダをリポジトリにして使ってみるといいと思うよ。
それで気に入れば使い続けりゃ良いんじゃね？

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

>>182,>>183
おｋ
ありがと。
挑戦してくる。

>>187
>失敗してもコミットしたとこまで戻せる安心感があるのは相当でかい。
重要でないことをさも重要であるかのようにいう奴が多くてやだね。

>>187
安心感はでかいね。おかげでざくざく先に進める。

>>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入れた後にインスコすれば日本語化できる。

>>189 はトリップつけてみたら？ （つけないでもだいたいわかるけど・・・）

tarballにしとけば確実に戻せる。

プログラマなら自分のコードぐらい覚えてるのが常識だよな。
いつでも自分の記憶を元に復旧できるのでバージョン管理なんて無駄。

>>192
君が付けたらそうしようか。

>>194
まあ、すくなくとも２週間以上前のソースに戻すことはないね。

いつどの様な理由でコミットしたのか台帳に書いてください。

>>197
そんなのバージョン管理ツール使ってたってコメントなんてつけねぇだろｗ
普段やらねぇことやってるようにいうな。ボケ。

コメント変えただけでコミットするバカがいてうんざり

バイナリを登録したら怒りだした管理者がいました。

>>199
javadocでエラーが出ててたらしょうがないな。

否定派：作業履歴が残るとまずい人
肯定派：履歴を次の作業に活用できる人

緑の人はなんでここまでスパークしていたんだろうかｗ

日曜だからじゃないの？

バージョン管理ツールを導入したら癌が治りました。おまけに彼女も
できるし給料もあがるし昇進するしで、もうえらいことです。

このスレを見ただけでも、バージョン管理を使ったことがない職場、
特に技術レベルの低い中堅ＰＧがいるところで導入が進まないのが納得できるな。

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

全くなんでだろうね。
未知への恐怖？
自分の糞コードが記録されてしまうことに抵抗あるとか？

昔のはひどかったからな
途中でソースがなくなるとか普通に有ったよ

>>206に書いてる様な無意味に保守的な会社はコケてくれればそれでいい。
だだしそういうPGが書いたコメントアウトだらけのソースさえ
こちらに回ってこなければ。

ごめん。CVS、SVNは未だに使い方が良く分からん。
VSSは使ってるんだけど。

初めてVSS使ったのが大規模プロジェクトで、ソースアップするのに半日から一日がかり
VSSうぜーとか思ってたけど
十数人規模のプロジェクトに移ってからは便利だわ、これ

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

CVS、SVNも競合は管理してるでしょ

管理はしてる。解決するのは人間

それは逆。

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

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

>>215
マージが手動じゃ意味ねぇじゃんｗ

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

ソースレベルでマージする必要がないように、分割コンパイルと、リンカ
やライブラリアンが存在するわけだろ。　なんで、「一杯のかけそば」
のように、複数で同一ソースを触んなきゃならんのよ。

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

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

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

>>216
バージョン管理という概念としては
ファイル更新が衝突するかどうかなんてのは、瑣末な問題でしかないんだろう。
マージが手動であっても、手動で解決できるなら問題ない。
バージョンはちゃんと管理できるんだから。

ソースのマージはうざいよな。
大体、デグレがおこるのはそこ。ヒューマンエラーが介入してしまう。

おみゃーらに習って入れてみた。けど、孤独は解決されん罠...orz

マージする時にCVSが全自動で仕様の妥当性チェックまでしてくれたら、ﾏﾝｾｰするよｗ

おー、こんなレベルの低いスレがあるとは。
バージョン管理ツールってのはどこの会社も当たり前のように使っているものだと思ってた。

CVSでもロックを掛けることはできるし、
他人による変更を通知してもらうこともできる。

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

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

修正前の行を全てコメント文で残しておけば、ファイルの一元管理ができるだろ？
メジャーで5回も改版されたソースは、スパゲッティどころの状態ではない。
もはや、ゲージツ品に値する。ああ、頭痛ぇーーー！

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

コードの共同所有

>>226
ソースは分割して作業するからそもそも衝突が起こりにくい
でももし起こってしまった時の保険だろ

VSSみたいなチェックイン／チェックアウト方式だとデグレは発生しないの？
ソース管理を使わないほうがデグレが発生しないの？　ちがうだろ。
バグの発生とバージョン管理は別の問題だと思うぞ。
かえって、マージのときにツールを使ってビジュアルに変更点を確認しながら修正する方がミスが少ないんじゃないだろうか。

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

つxUnit

同じコンパイル単位でも別々の人間が同時に作業することはよくある
そういうときにVSSは大変使いにくい

>>229
TortoiseSVNには割と使いやすいマージツールが付属する罠

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

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

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

ロックする戦略の方がマージする戦略より昔からあった訳だが。

VSS使ってても、修正の時にチェックアウトせずに書き込み付加属性をはずして修正して、
修正終わったらチェックアウト→上書き→チェックイン するキチガイがたまにいるけどな。
ぶん殴ればよかったかも。

零細企業は大変ですね。

基本的な質問で申し訳ないのですが
ソースの書き方で気に入らないのがあって

for(hoge; fuga; hage)
    {

aho;
boke;
kasu;

  }

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

そうして、元々書いた奴との熱いコミット合戦が。

>>234

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

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

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

>>238

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

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

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

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

ttp://www.banbanban.jp/zero/men.html
メンズＺＥＲＯ

激白！男のニオイ

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


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

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

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

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

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


＊場面が切り替わり、男性へインタビュー（？）

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


パソコンテレビＧＹＡＯで映画の途中に挿入されていたＣＭです。

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

>>239 >>241

参考になりました。

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

>>241 うむ。
SVNならprecommitフックにastyle（ttp://astyle.sourceforge.net/）実行スクリプトかまして
コミット時には強制的にプロジェクト標準のコーディングスタイルに
整形フォーマットすると幸せになれるかもしれんな。

こんなツールはどこの馬の骨かわからない人がよってたかってソースをいじり倒すオプソ用。

＞216
＞>>215 マージが手動じゃ意味ねぇじゃんｗ

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

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

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

>>247
実験は本リポジトリに接続していないところでやる方が安全じゃないのか？

>>248
本リポジトリじゃないところにファイルコピーして？


ヴぁかじゃん、おまい。

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

コミットしなけりゃ何してもOK
やばくなったら実験コードを捨てて直近のファイルをチェックアウトするだけ。

本データもいいけど、どうせなら、作った実験データも保存してほしいよね。
ラベルと日付付けて、「〜のテストしました。」とかって保存する機能ほしいね。
わずらわしい設定無しで右クリでラベル付けて「ポン」って感じでできないかな・・・。

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

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

>>247
誰がいつ何をいじるかわからないオプソの世界なら
誰でも好きなときに弄って実験できる方がいいかもしれないが、
納期がある、順番どおり作っていく必要がある普通のプロジェクトで
好きなときに好きなように弄られても、困るだけじゃないか？

MS製品もOracle製品もCVSの登場するずっと前からあるよ。
おまいらの会社はそれらの製品よりはるかにソースの少ない少ない自称大規模プロジェクトの
業務系だろ。
CVSが無いと管理出来ないほど頭が悪いのか？

ディレクトリごとコピーとっときゃ良いんだよｗ

>>253
うん

>>251

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

>>253

そうなのか。

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

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

>>256
鬼門だと知って話題を振っている件について

right と correct の違いについて教えてください

>>259
まず、綴りが違います。

なるほど
ありがとうございました

>259
まず綴りが間違っています。

richtigとkorrektです。

WEBの世界にどっぷり浸かった
WEBエンジニア暦6年
CVSもVSSも利用したが、とりあえず。

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

追記で

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

もちろん

>>264
そんなんで追いかけられる程の規模ならな

バージョン管理の話だし、一日一回は更新するだろ？
一日　書けても1000行じゃないか？
きついとこなら200行書ければ良くない？
それくらいなら余裕でみれねえか？
意味わからんＤＩＦＦコマンドだから違う部分だけ出てくるからそこを追記して更新すりゃいいんじゃないの？

>>263
＞2，3人でやる仕事なら、短期開発が多いので、ツールいらない。

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

＞DIFFコマンド＋目視のが安全だったりしません？

本当そうですね。
ＷｉｎＣＶＳでチェックイン直前にＤＩＦＦツールで目視してますが、本当に安心。

>>267

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

分かり切っているものを打ち込む あるいはコピペなら。
もしくは無駄なウダウダ書いてる行数を計算に含めて良いなら。

>>268
>どうやってソースの渡しあいをするのか不思議でならない。
ツールばっかり使ってて馬鹿になったんじゃないの？ｗ

バージョン管理？そんなの要らないだろ。共有フォルダをリリースの
タイミングでバックアップすれば良いんだよｗ

週末になって緑の人がまたｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

>>273
最近、流れがよくわからなくて参戦してないんだけど？
俺はDIFFで比較すらしない。
そもそもソースがバッティングすること自体アフォ。

ま、痛い目あったことがないラッキーくんなんだろうな。。。
ネタだろうけどね

>>275
具体的に説明してくんね？
痛い目ってどういう目のことをいうの？
普通にサーバーが飛んでサーバーのデータが消えた程度のこと？
それだったら、個々のマシンではデータが残ってるから全滅はありえないんだけど？

リリースが今日と明日と明後日とあって
今日の分も100％の出来じゃないのにリリースしなきゃならないような状況とか

>>277
え？俺は痛い目がどういう目にあうことなのかを説明してくれっていったんだけど？
コミュニケーションあんまり得意じゃなかった？

喧嘩腰の人間にまともに答える人は、そういないよばかばかしい。
バージョン管理ツールは、ツール使う人のなかでも信者論争があるくらいだ。
平行線辿るだけだろう。

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

進化を忘れた猿に道具の使い方を教えても無駄だってｗ

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

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

>>236
やるやるｗ
サーバーでいじっているファイルを見られるのが嫌でたまんない

>>279
自分が頭悪いのを俺のせいにしないでよｗ

そら、バージョン管理ツールの必要が無い人なんて、いくらでもいるだろ。
捨てコード書くのにバージョン管理するやつなんて、オナニーだろ。
痛い目くらい、ぐぐれば出てくるが、一つも例を挙げずに罵倒する自体、痛いﾔﾂのすることじゃねーのか。

>>280
CVSなんて糞wwwww

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

>>283
こういう態度の人間にはなにいっても無駄じゃねーかとは思うけどな

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

正直、バージョン管理なんて学習するほど難しいもんじゃないよな。

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

豪快！共有フォルダ丸ごとバックアップ。これ最強。

>>288
それはそれで必要な事も有るぞ
月に１度はフルバックアップしたいよな

>>289
しかもバージョン管理ツールなしでやるのだ。

>>290
うん、それでいいんだよ。
もしかしてバージョン管理ツールを根本的に分かってない？

必要性ってか、絶対必要だろ。
前も、間違ってファイル消して、ソース書き直してるうんこがいた。
俺は個人の趣味でプログラムやるときだってSVN使ってるよ。

>>287
バージョン管理すらわからんやつが、どうやってコードを書くのだ・・・
マジで足洗って欲しいよな。

いや、コードを書くことはできるだろう。
問題は、作ったアプリを他人に使わせられるかとういうこと。
障害が起きたときに、提供時のソースが残っているかどうか・・・。

>>294
それで犯人探ししてその後どうするの？
もう、すでに担当者なんていないとかそうだったときなんの意味もないじゃん。

>>294
あー、バージョン管理がなくてもソースは書けるよ。
俺が言いたいのはバージョン管理システムの使い方もわからん奴が、
まともなコード書けるのかってこと。

バグだらけのCVSなんか使えんわ

一番よくあるトラブルとして、サーバーが吹き飛んでもバージョン管理のデータって復活できるの？

気楽に使える個人用CVSって無いのかな？
サーバとかじゃなくてSQLiteとかが埋め込まれてるだけのもの。
IDEのプロジェクト単位で標準で付けて欲しいのだが

Tortoise SVNなら気軽にローカルにリポジトリ作れるじゃん。

バージョン管理否定派てオブジェクト指向も出来なさそうな感じ

>>295
>それで犯人探ししてその後どうするの？
犯人探し？・・・馬鹿？
君、仕事でプログラムのサポートしたことないでしょ？

>>295
まず、問題の起きた場所を特定しそのソースは
いつ書かれた(変更された)ものかを突き止める。

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

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

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

OOで思い出したが、Javaで同名クラス禁止のプロジェクトに関わったことがある
判断が微妙だが、被っていいのは他所のライブラリとだけみたいなのは普通？

>>295
提供先で障害が出たら、（運用のサポートは別途するとして）
開発担当がまずやるのはまず最初に現象出しだろう。

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

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

>>304
アプリケーション固有のクラスに関しては、
同一アプリ内で被らないほうがいいだろうね。

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

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

はぁ？そんなのやってねぇよ。
ちなみに派遣で松下、富士通、日立、沖、東芝、ＮＴＴまわったけどどこもそんなことしてるところねぇよ。
妄想もいい加減にしろ。
やってないことをさもやっているように語るな。嘘吐き。
バグったら、バグってる箇所見つけて、修正してリリースするだけだ。
別に書いた奴の意図なんかしらねぇよ。
俺はただ、バグった箇所を修正するだけ。

>305
> そのときに、提供時点のソースが残ってなかったら、
> どうやって現象再現させるの？

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

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

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

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

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

>>308（苦笑

>306
開発者毎に異なるネームスペースを使うとか、クラス名や関数名の頭に固有
の名称や文字を付けるように、あらかじめコーディングルールを決めておけば
よいのでは？

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

>>308
激しく同意。

変数名が有効なのは先頭の２文字

>>308 こりゃまた微笑ましいレスだなｗｗｗ

緑が俺だけでないことを目視で確認。

>>308
あんたが言ってることって、ツールより手作業のほうが確実かつ効率的だって
言ってるのに等しいんじゃない？IT不要論者？

コミットログじゃ駄目なのか？

>>315
いや、ツール使っても大事なことはできないじゃない？
っていってるんじゃね？

>>308
そのケースに限定しすぎ。
たとえば一人でやってても、ここ3日なかったバグが出たら、
疑わしいところを前のバージョンとdiffとったりするけどな。
あと、たまにコミットログ読み返すのも趣味として楽しめるぞｗ

>>308
>それって丸ごとexe含めてバックアップした方が、安全確実だと思うけど？
微妙な話だな。
ビルドファイルは当然管理するんだけど。
しかし、同一ビルドファイルとソースファイルから同一の exe が出ない理由なんてあるんだろうか？

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

>>317
なにができねーっていってるわけ？
リリースタグうったり、コミットログとばしたりじゃ足りないって？

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

>>310
>開発者毎に異なるネームスペースを使うとか、
それはどうやって結合するんですか？

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

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

図らずも否定派が馬鹿であることが証明されました

バージョン管理なんてやってるとこねーって意見もあるみたいだけど、
少なくともeclipseとかVSとか最近のIDE使ってるとこはほとんど入れてるんじゃね？
となると、バージョン管理ツール使ってるところが希少って意見は
ありえないし。
バージョン管理の有効性を各自が気にしてるかどうかは別にしてだが。

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

>>324
確かにバージョン管理してないない奴は
未だにコマンドラインでコンパイル、デバッグはprintfがデフォだったりする。
要するに環境構築に手間かける時間＜＜＜＜さっさとコード書く
という風にしか頭がまわらないうんこ。

十秒もあれば完了だろ
ファイル探して解凍するほうが時間掛かる

サーバーが吹っ飛んだときにあまりにも無力だな。
どっちにしろ手動で一式保存する操作はバージョン管理を使ってても必要だな。
でもって、アクセスも頻繁で負荷も高いから一番よくあるしね。

>>327
無理だろ。
サーバーから差分だしてデータをコピーする時間は確実にかかる。
ソースはいいけどデータがでかい。

リポジトリのダンプ取るバッチ組んどけばいい話

>>330
つか普通そうするだろ。
サーバのバックアップの話とか、バージョン管理と何の関係があるのやら。。

>>325
データベースの状態まで保存していない？
テスト用のデータセットアップスクリプトとあわせて置いて置けば良いだけじゃないのか？
操作ログも取らずに思い立ったテストをだらだらやるやり方だからデータベースの状態が残せないんだよ

>>332
データベースなんてみんなが色々操作してるから中のデータなんてそれなりにめちゃくちゃになってるよ。
突然変更するとプログラムまで動かなくなってこまったもんですな。

じゃあそんなのバージョン管理しなきゃよくね？

なんにしろローカルで圧縮するくらいなら
バージョン管理に入れろって話になるね

>>334
でも、一番やってほしいのってこの辺じゃね？
実際はデータとプログラムがそろって動作するわけでさ。

>>335
まるごと保存で済むならバージョン管理なんていらないじゃん？

>>336
リグレッションテストと、その有効性と、それをやるためには何を管理しなきゃいけないか
を考えると、自ずと答えはでるんじゃね。
そんな偶発的なDBの状態をそのまま管理するのが果たして正解だと思うか？

>>338
いや、とりあえず理想はおいておいてプログラム動かすので精一杯だからｗ

だから、理想っつほどコストかかんねーっつうのよ。

共同作業じゃなけりゃバージョン管理ツールなんていらんだろ

だから、一度で良いから開発標準を頭に入れて来い
IDE上でステップ実行してる内はテスト工程に入っていないんだよ

いや、共同作業でも普通、作業の切り分けってのはできるもんでな。

>>342
毎回、それでリリースしてんのに、そういわれてもね。

バージョン管理ツールが要るか要らんかは、バージョン管理の必要が
あるかないかに依存する。
バージョン管理がいるかいらんかは、要件の複雑さと規模とバグがでたとき
客先に提出する紙をどこまで詳しく書かなくちゃいけないかに依存する。

>>345
そもそもちゃんと作業の切り分けができてれば、ソースがバッティングすることも
バージョン管理しなきゃならんほどのバグもでないでしょうよ。
って議論はしないんだね？

>>343
まずソースコードの共同所有あたりでググってこいや。

つか、要らねって人は収入低い仕事してる人だと思うな。
普通、要るだろ。おれはさっき書いたコードも三歩歩けば忘れるよ。

>>347
だから、関係ないって。

>>348
はいはい、都合の悪いレス>>307は見ないんだねｗ

バージョン管理すら使えない奴って、言語も一つだけしかできないんだろうな。
しかもオブジェクト指向も出来てないとおもう。

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

>>349
関係おおありだよ。
今日日の開発は、ソース単位で作業を切り分けられねーんだよ。

>>351
だって面倒くせぇんだもん。
そりゃ全部のソースが団子みたいに丸まってるなら一括管理のほうがいいけど。
折角分かれてるもんをわざわざバージョン管理に突っ込むこともねぇし。

このスレ盛り上げてるヤツって、釣りうまいよな

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

いざってときに１つのソースを二人でいじる、
それがちょちょーいと出来るのが最近いいな〜って思ったな。
同時に編集してても自動マージしてくれるし、
ミスってもすぐロールバックできるしな。

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

>>355
はぁ？
プログラムの基本は分割だ。
お前のは新しいとか古いとかじゃない。下手糞なだけだｗ

その証拠に

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

　意　味　が　わ　か　り　ま　せ　ん　！　（笑）

>>357
なんで意味がわかんないのかわかんないな。
ファイル間・・・つまりはクラスや構造体同士の依存が起こるって話じゃないの？

>>358
で？昔と今でどう違うの？

長々とまぁよくつづくねぇ…

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

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

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

>>360
はぁ？俺が言ってるのは

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

ってことなんだけど。

>>359
ああ、いまも昔も変わらないよねってツッコミだったの？
ごめんね行間読めなくて。

>>362
いや、俺がいいたいのは>>355の発言の

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

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

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

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

>307
漏れの経験だと…
目立では確かに使ってなかったが、
IB○とデン○ーは使ってたYO!

>>361
君、そろそろ飽きたんで別のネタにしてくれるかな？

>>365
はぁ。じゃあ、適当なの振ってください。
１ついっておくと、君の振る話題は面白くないから私に話題をとられてしまうんですｗ

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

正直さ
超大規模プロジェクト＝＞利用してもいい
ベンチャーの人入れ替わりまくる会社＝＞利用すべき
受託開発会社＝＞品質を保つ為利用してもいい（客先がコストダウンしろいうなら利用しないほうがいい）
その他＝＞好きにしろ
てか同じソース同時に弄る可能性のある振り方するな。大規模ならしょうがないが。
でも品質維持の為に利用する分にはいいんでない？

流れをぶった切って ﾇﾙ(･ω･)ﾎﾟﾘｰﾝ 参上！

>>367
同じソースを複数人数がいじるのは、
後輩が書いたソースを先輩が直して、コメント書いておいて勉強させるとか、
プログラマの技術交流的にもやってもいいかなって思う

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

>363
>クラスや関数なんて分けるための技術であるにもかかわらず>>355のいうことっておかしいよねぇ？

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

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

>>370
なに、話すり替えようと必死なのｗ
もう、君がただの馬鹿なのは明白なんだよ。
その辺で黙っとけｗ

>>339
新しい道具を試す余裕もない仕事をしてるんだね
バージョン管理以前に一度立ち止まって考えてみるべきだな

このスレを読んでいて、バージョン管理ツール導入しただけで、バージョン
管理したつもりになってるクソ会社ばかりなのがよく判った。○○でも使って
いるから、ウチも導入しましょうってか？

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

というか、ここで議論されてるのはもっとレベルの低い
バージョン管理システムが必要がどうかって話だ。
必要って事に異論を唱えること自体信じられん・・・

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

一番使えんのは、あれこれツールを試したとか言うけど、いざ実際に使わ
せてみると雑誌の照会記事の追検証やったことがあるレベルで、とても道具
として使いこなせていないケース。アミバ以下のレベル。

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

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

ゲーム屋だと、その一本グソを作ることになる＝バージョン管理必須

コンシューマ系？PC系？いくらゲームでもイマドキ一本ってことはないと
思うが？もしかして、同人系？

コンシューマー。普通に一本グソだよ。

>>363
クラスは機能毎にファイルわけてねーだろ。
当然データごとに分ける。

当然か？

本当は当然でも無い。
意識してそうしないとならない。

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

いや、でも、BCEモデルってそんな感じじゃね？

>>376
大規模プロジェクトがバージョン管理ツールを導入する必要条件って
わけじゃないんだから大規模プロジェクトの定義なんてしても
しょうがねーだろ。

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

>>383
と思ってる奴も多いと思う。
まずはここ読んでみてくれ。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

>>385
自分の理解では、その記事は、
MVC における、Cにビジネスロジックを書くことが問題だといっているような気がするんだけど。
BCE の CE って MVC の Mでしょ？
つまり、BCEのCにビジネスロジック書くのは、MVCでいえば、Mにビジネスロジックを書くことで、
その記事の内容と矛盾しない。

>>386
MVCのCはBCEのB(の一部)だべ。
よって記事の内容は、BCEのBにビジネスロジック書くのが問題だっていってる。

分割するとかしないとかあんまり関係ないだろ
構成管理をツールで楽をするかしないかだけの話じゃないか

> DLL化してたらなんなの？なおさらバージョン管理（つか、それ含む構成管理）
> する必要があるんじゃないの？

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

おまいら飽きねえなぁ…よく続くよ。
これだけ説明しても必要性がわからないってのは
老害か、本当にバージョン管理の必要性を感じない”ユウシュウナＰＧ”なんだろ。
（もっとも、賢明な人は普通使ってるもんだが）
あるいは必要性のない程の小規模プロジェクトでも有り得るか。

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

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

390の補足。
>あるいは必要性のない程の小規模プロジェクトでも有り得るか。
これは１〜２日から１週間程度で書き上がるの書き捨てコードってことな。

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

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

ばかだな。COBOLで基幹系の大規模開発にはCSVなんかつかわねえぞ

たかだか20万行のコードを20〜30人で触るプロジェクトって、多めに見積って
も、1人あたり1万行ってことだよな。その1万行のアウトプットに何ヶ月掛け
るわけ？要件定義や設計から含めると、のべ工数見積りはざっと200〜300人月
といったところか？そりゃ、工数だけ見ればたいそうな大規模プロジェクトだ。

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

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

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

>>390
てか、そういう前提がありえない。
さすがにそれを１本糞で組んでる状況ってのがあまりにも下手糞過ぎて笑える。
そんなに人数がおおけりゃライブラリみたいな形に分割することになるって。
分割すれば、全体で２０〜３０であっても個別の機能でみれば５〜６人程度におさまってしまう。
この人数であればバージョン管理はあってもなくても別にかまわない。
まず、この切り分けが出来てないような環境のほうが俺は信じられねぇよ。

工場勤務の組込ﾄﾞｶﾀが紛れ込んできたようだ。

>394
390は「マルチプラットホームライブラリをコアに」云々と言ってる。
またライブラリ自身も弄ってると言っている。
従って最低3チームには分割されているはず。
それ位読み取りなよ。

>>396
じゃあ、２０〜３０ってのは嘘なんだよね？

>392
使えない環境があるのは認める。てか基幹系業務コードに適用するバージョン管理ツールの存在を俺はしらん。
識者がいたら教えてくれ。

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

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

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

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

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

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

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

>>398
>担当者はおっしゃるとおり５人前後だな
じゃあ、もう、話の前提が崩れてるからこの話は終ね。
それは２０〜３０とは表現しない。

>>399
だーかーらー。
各々のサブコンポーネントがそこまで独立してねぇんだよ。
コアやミドルのコンポーネントを利用するコンポーネントが複数あるんだって。
その上に実験コードなりそれらのマージなりがあるんだから、
手作業なんかでやってたら時間がいくらあっても足りネェっつーの。

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

>>400
それをバージョン管理で解決しようとしてるところがすでにウンコっしょ？
なんかバージョン管理云々関係ない気が自分でもしてない？
してなかったらかなり重症だと思うぜｗ

つうか、それってコンポーネント間の独立性が糞で依存性があるからそんなことになるんでしょう？

>>401
>どれだけの違いがあるんだ？
大して違わないな。
じゃあ、使わなくてもいいよね？

設計が糞なだけじゃんｗｗｗｗｗ

この不毛な論争はいつまで続くのだろうか
使いたきゃ使えば良いし、使いたくねえなら使わなかったらいいだけなのに

>402
バージョン管理ツールを、バージョン管理にしか利用できない君がウンコ。

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

そんなものはコンポーネントとかミドルウェアとはいいませぬ。

>>407
ついにフォークでラーメンを食えといいだしたかｗ

Java厨にミドルの設計は無理。
終了。

なんだ。こちらにもおじゃばさまが降臨しているのかｗｗｗ

ライブラリと、それを利用する 「複数の」 アプリを
複数人で平行して開発しようと思ったら、
バージョン管理ツール無しだと、ライブラリへの変更が
相当不自由になるか、破綻するかだと思うのですが。

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

>>412
関係ないんじゃない？
すくなくともライブラリの版数を上げたモンを適用しなきゃいけないわけだし、
そんときにソースなりlibなりdllなりもらえばいい話だし。

古いライブラリ限定のアプリとか開発するの？

ライブラリのテスト・デバッグとリリース機構に欠点があると見た。

結合度が高い設計しかできないJava厨には無理。

あれだな、Javaの奴らってみな共通する特徴がある。

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

>>404
>>>401
>>どれだけの違いがあるんだ？
>大して違わないな。
じゃあ使ってもいいんだよな。
手作業に比べてヒューマンエラーの介入する余地の少ない、バージョン管理ツールをな。
わざわざ間違いを犯しやすい方法を選択する、その根拠を教えて貰えないかな？

Javaの場合はさらにJDKのバージョンとかTomcatのヴァージョンとかStrutsのバージョンとかあって、
その組み合わせが無限大に。

Java厨のCVS厨って、eclipseが無ければチェックアウトすら出来そうに無いな。

>>417
どんな使い方してるんだ？能無しアピールされても煽りにはならないって。

ura2ch　ura2ch

発注元（某大手キャリア）から、品質ISOの必要性からツールを
導入して欲しいと言われたことがある。
ソース管理が適切に行われていることのエビデンス（証拠）が
必要だからだそうだ。
ツールにはそういう側面もあるんじゃないの？

マージ作業程度で間違いを犯すようなら、プロジェクトから抜けてもらった
方がいい。

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

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

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

分割されたモジュールが一本グソなわけ？モジュールつぅても、複数の
クラスや関数で構成されていて、ソースはクラスや機能単位で分割されて
いるのが普通だと思うが違うのか？

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

>>424
>マージ作業程度で間違いを犯すようなら、プロジェクトから抜けてもらった
方がいい。

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

>>398
> >10万ステップでバージョン管理が不要で、
> これは俺が１週間で一気に書き上げた経験から。
> こんときは書き捨てだったからいらなかっただけ。

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

>424みたいな
「何を言っても自分の認識外の事象があることを認めない」人種には
何を言っても無駄。

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

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

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

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

偽装派遣が専門のエンジニア売買会社からキックバックを受け取っている
現場マネージャーさんでつか？

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

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

>>428
１週間＝７日と多めに考え、15h/day程度だったとして1000 step/hだな。
１週間＝５日で15h/dayでも1500 step/hだぜ？

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

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

>>430
馬鹿だな。偽装派遣人員なら速攻お帰り願えば済むだろ。
わざわざ使い続ける意味がワカンネ。

>>432
言ってることがよくわかんないんだが、
もしかして手段と目的間違えてないか？
目的：リスクマネジメント
であり、
手段：（ヒューマンエラー低減を見込んだ）ツールの導入
だろ？

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

>430
いや、ルールがツールという形になってる点で非常に有意義。
口頭や文面でルールを伝えるより、よっぽど徹底しやすい。

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

俺の場合、開発初期は爆発的にコードが増え、
後半はリファクタリングやなんやらでだんだん減少していく。

少し話題を変えるが、皆はCommitの単位をどう区切ってる？

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

>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文字キー
入力し続けなけりゃ追いつかんな。もちろん、その間は、仕様書に目を通す
ヒマも、ヘルプ調べたり、トイレで用を足したり、コーヒ飲んだりする時間
なんてのもない。

基本的には細かけりゃ細かいほどいいんじゃないか？
自分の環境で動作確認できない時に、
commit→サーバーでupdate→build→確認
って手順を踏んでたときは
コメントがDebug,Debug,Debug....って酷い状態になった。

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

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

>>433
偽装派遣の会社から、『受け入れて貰えたら、派遣1人あたり1万円をマネー
ジャーさんの個人口座へお振り込みしますよ』と言われるわけだよ。

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

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

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

コピペしないわけじゃないけど、バグまでコピペしたら嫌なので
安易にはっつけて置換で終わりということは絶対にしない

#include <stdio.h>

と書いたら、コピペして

#include <stdlib.h>

と書き換えるだろ。

コピペしたり、ペーストした行を修正するにも、カーソルを移動したり、
不要な文字を削除するために、キーボードなりマウスの操作をするだろ
うが。

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

バージョン管理ツールってさ、（バージョニングされた）リリースを管理するものじゃねえの？
つまり、コミットするのはテストが終了したコードが前提。そんなに頻繁にするものじゃない。
バージョンとバージョンの間のソースはローカルで書き、ローカルでテストしろって。

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

>>445
つうか、CVSFSとかSVNFSとかを使うのがいいんだと思うよ

構成管理と版数管理の関係

テストも通ってないコードをコミットしないでください。

CVS/SVNを導入すると、１ファイルのサイズが大きくなる傾向がある。
どうも新しくモジュールやクラスを登録するのが微妙に億劫になるみたいで、
追加する時に既にあるファイルの隅にコードを追加する輩が多いんだよな。

>>449
そういうのはソースレビューして弾いちゃえ

>>445
>改編履歴記録ツールだな。よほどDQNﾄﾞｶﾀをかき集めてコードを書かせているんだろうな。

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

>>445
改版履歴記録ツールとして使う場合はブランチを切るのが吉

>>449
CVSならまだしも、SVNでそんな馬鹿見たことねぇ

10万行のコード書くまでに
試行錯誤で100万行分のコード書いているな。

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

>>454
コーディングだけがマの仕事だと思ってる時点で、ダメじゃん？

なぜいまだに信者論争にしかならんコトを気付かないんだ・・・
どっちもどっちだおまいら

>>454
案外、他所のソースのコピペか他人のプログラムを丸ごと拝借して、自分で
書いたと称している厚顔無恥な香具師か、厨房なのかもしれん。

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

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

正直、必要かどうかだけでここまで荒れるネタだとは思ってなかったわけだがｗ

この業界に入ったときからずっとcvs(最近はsvnも)を使ってきた漏れとしては、
バージョン管理ツールを使わない開発ってのが想像もできんのだが。


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

個人で作るときもCVS作るの？

>>460
1から作り始める場合、最初は普通にファイルベタ書きだな。
で、ある程度ソースツリーの枠組が固まった時点でCVSに突っ込む。
cvs init => cvs import => cvs checkout するだけだから、ほんの1,2分の作業だ。

居るんだよなぁ。入社した時からずっとこのやり方で、これがウチのやり方
ですって言う、視野狭窄な香具師。特に、世間から隔離された大手企業に
多い。

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

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

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

何度も言われているように必要か否かという議論は既に終わっている

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

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

>>462はバージョン管理ツールがどういうものかわかってないと思われ

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

でも、それでバグを入れられたらむかつくよな。

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

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

>>462
プロジェクト管理やプロジェクト方法論の書籍は
世に数多出版されているわけだが、
バージョン管理を用いないほうが良い、なんて書いてあるものがあるのであれば
教えてほしい。

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

vssだけにしろや

ＣＶＳって文字コードの問題解決したの？
昔はシフトJISのファイルを食わせたらバイナリと間違ってたりしてなかったっけ？

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

subversion使わないの？

あれってJavaじゃないの？

いや？

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

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

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

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

いや

WinCVSごった煮版ってなんなんだよ。素人丸出しというか玩具だな。

バカが勝手にファイル名を変更したのでわけがわからなくなりますた。

ブランチ間でマージする方法を教えてください。

CVSつかってりゃ全て完璧って思ってるバカおおいよね。

だから使わないの？それこそ馬鹿

バージョン管理ツールは効率を上げるための道具に過ぎない
俺も前はzipにしてローカルに保管してたけど
今思えば随分無駄なことをしてたと思う

導入してからが大変って話。
CVS入れてデグレの増えたところ多いんだ。

しかしデグレにならなければそのまま上書きされて>>475のようになるわけで。

完璧じゃなければやらんほうがマシ



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

>>484
なんでCVS入れるとデグレが増えるの？

何で毎日上書きすんの？
テストしたコード以外コミットする理由がわからんわ。

知るか

>>487

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

なんでもCVSで管理しろって馬鹿いるよな

常に同期を取ってリアルタイムに変更を反映するようなツールがあればいいと思われ

CVSで管理するのにふさわしくないものも有る。


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

共有ドライブ上でコンパイル

結合テスト始めるまでは毎日上げてもいいと思うが
開発マシン壊れたら洒落にならない
まあ、コンパイルエラーで自分の作った機能以外が動かなくなるような
ソースを上げなけりゃそれで良い

だから、文字コードの問題はどうなったの？解決したの？
まさかチェックアウトするたびに変換してるの？

vssだけにしろや

subversion使わないの？

CVSはバックアップツールじゃないよ。
テストを通るまではバックアップツールの役目。
単体テスト終わり、結合テスト終わったらバージョン振ってコミット。

バージョン管理って呼び方が駄目なんだな
変更履歴管理ツール

ばかばっかし

>487
それについては、そいつも当人に問い詰めたらしいが不明。

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

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

>499
変更履歴保存ツール

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

日々の作業のバックアップツールと勘違いしている馬鹿がいて困りますね。

そのバックアップツールとしてさえ満足に機能していないわけだが？

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

ごった煮版って何？

ぶっちゃけ、WinCVSは糞。CVSを弄るためだけにEclipseを起動し、コーディングは秀丸でって人も多いだろう。

よく判らないけど
コピーコマンドマンセー、俺以外は馬鹿だから俺のやることは正しいって事でOK?

>>505
ﾉｼ

>>507
お前だろ、毎回エラー出したままサーバーに上げてみんなに吊るされてるのｗ

日本のCVSコミュニティがアホぞろいだったから、ローカライズが糞で日本語文字コードの扱いがぐだぐだになってしまったのは事実。
あれですっかりCVSに失望した人は多いよ。

>>509
バージョン管理なんて使ってる奴等はみんなアフォぞろいだからそういうことになるんだ。

CVSは糞だよ。
その糞を改良したのがSVNなのに、なんでいまだにCVSを使い続けるのかよーわからん。

リリースが頻繁で分岐の激しい業務系だけでしょ。こんなの必要なの。
リリースがきちんと管理されたパッケージには無縁だよ。

業務系ﾄﾞｶﾀ管理ツール

いいわけ大王だな。
http://subversion.bluegate.org/svn-anti-fud-ja.html

ＥｃｌｉｐｓｅでSVNが弄れて、CVSに蓄積したソースをSVNに移行してくれたらやるよ。

> CVS は非常にすぐれた、そしてバージョン管理にふさわしいことが証明
> されたモデルである; 単にうまく実装されていないだけだ。

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

>>514
ツッコミどころ万歳だなｗ
俺、こんなアホが作ったもん使うのやだなｗ

ＳＶＮも糞ですが。何か？

一番まともなのはVSSとRCS

>>515　つ[cvs2svn]

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

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

とんでもねえ話だな。
ソース管理という極めて重要なツールで人柱を要求してやがる。

SVN厨とJava厨って同じ臭いがするよね。

CVS厨ほどではないと思うよｗｗｗｗｗ

もはやCVSがスタンダードだろ。お前らアホか。

必要性の次は信者論争かｗｗｗｗおまいら楽しいな

>>525
こんなボケの作ったSVNでもCVSよりはましな状態なんだ・・・orz

Team Foundation Server を使ってるところは、まだあまりないのかな？

信者論争に入ってきて、ﾄﾞｶﾀ罵倒要素が入ってきたら、3年くらいは続くな。。。



Javaスレのように。

基本的に賛成派で、バージョン管理の好きなところはいろいろあるけど、
>>17で説明している「コードにゴミコメントを残さなくて良い」と
いうのが一番好きな部分。

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

CVSで管理していても、DELとかADDってコメントを残させるところって無い？

高々道具なんだから、使いよう。
だがいかなる道具も、使わないより使いこなした方が便利になり、
使いこなせない場合は、使わない場合より不便になる。

バージョン管理ツールの一番の利点はバージョン管理のやり方をツールのルールで統一できるところ。
逆にツールのルールに縛られる部分もあるので、不便になる状況も確かにある。

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

何がむかつくって#ifdef 0でコードを残す奴だな。
コメントで残してくれたほうがマシ。

> ごみコメントっていうかIFDEFブロックコメントが最悪。
> エディタも色分けしてくれないしね。
> 何がむかつくって#ifdef 0でコードを残す奴だな。
> コメントで残してくれたほうがマシ。

あーそれ、漏れ。

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

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

>>535
もちろんバージョン管理ツールは使わないんだよな？

>>535
だから、「なぜこのコードが残されたのか？」って思わせないために
#ifdef 0
は勘弁してくれ

C言語使ってると馬鹿になるという典型だな

デバッグ用、もしくは、単体チック用のコードです。

だったら

#ifdef _DEBUG

だろ。ゴミ

#ifdef〜#endif で囲まれた範囲に色付けできる
エディタも普通にあるのだが。

俺、Ｃ言語大好きだけどそれ使ったこと無い
ド低能が使ってるの見たことはあるけど

>>540
勝手にデファイン切らないで下さい。

>540
あの〜。C++(Cは知らん)標準は NDEBUG ですよ。
ttp://donguri.sakura.ne.jp/~shock8/wisper/debug_release.html

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

>537
残されていないコードだから、#if 0なんだよ。ところで、#ifdef 0は常に
TRUEか未定義動作になるんじゃないのか？

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

>>546
じゃあなんで消さないの？

#if 0 でコメントアウトって、>535の言う「冗長なコード」には
当てはまらないのだろうか。

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

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

>>549
なるほど。じゃあバージョン管理ツールについてはどう思う？

>548
余分なバイナリ生成されない#if0 〜 #endifは漏れ的にはソースコードじゃ
ないから。

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

＞余分なバイナリ生成されない#if0 〜 #endifは漏れ的にはソースコードじゃ
＞ないから。

死ねよお前ｗ

俺ルールが全てって言ってるだけの厨じゃんｗ

>551
無茶言うな

>>553
>>506

何人もの人の手を経たソースで#if 0 が複雑にネストしてると#elseを探すのが大変だ
勝手に消したらまずいだろうし、てわけでネストが増えていくｗ
この話題はそろそろスレ違いかの

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

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

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

なんでこんなに粘着なの？
しつこいのにも程があるよね

クソは叩いておかないと、世界中がクソまみれのコードであふれかえるから。

バージョン管理使うんならいらんコードは全部消していいじゃん。

>>559
んじゃ、鏡に向かって罵声浴びせるといいよｗ

つーか、#if 0とかじゃまくせーコードをバッサリ消せるのが
バージョン管理ツールのメリットだろ・・・って釣りなんだろうな。

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

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

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

そういう連中は、プログラミングも車の運転もやめた方がいいと思うぞ。

おまえ絶対仕事できねぇだろｗ

またしてもバージョン管理否定派は馬鹿であることが証明されました

>565
おまえの言う仕事とは、日々ステップ数を増やした分だけバグを埋め込ん
で、いたずらに納期を遅らせ、テスト工数と残業時間を増やすことか？
そりゃ、漏れにはマネできんわ。

共同作業を理解出来ない奴が仕事でコード書くなよｗ

おまえらキモイ連中と合体するような、依存関係の高いコードなんて書ける
かよ。オブジェクト指向とか、モジュール化って言ってるのが、表面的で、
言葉尻だけなのがよくわかるよ。

な？こんな奴ばっかだ。

そんなに今やってるプロジェクトで嫌なことがあったのか？
そんな君にはバージョン管理ツールの導入をおすすめするよｗｗｗｗｗ

こいつ(535)バージョン管理否定派なのか
どっちでもいいけどこいつとはいっしょに仕事したくないなというのが率直な感想

漏れも、1行blog機能付き変更履歴保存ツールを導入しているだけで、
バージョン管理しているつもりで居られる連中とは、仕事したくないな。

とりあえず、Ignoreファイルに535追加。
俺のリポジトリが汚れる。

流石に名前欄に全角数字書いちゃうような子とは一緒に仕事したくないな

ageていこうぜ

同じエンバグ繰り返すとか言ってるがソースレビューやペアプロとかやらんのかこいつ
教育しても同じバグを繰り返す奴は適正がないってだけの話だから首にすれば良いだけ

えーっと

#ifdef DEBUG

#endif

はダメっすか？

>>577

% vi 577
:% s/適正/適性/
:wq

% cvs commit -m "typo"

CVSの何がむかつくって、勝手にviを起動するところだな。
あんな前時代の遺物を使えってのか！

>>580

環境変数 EDITOR を設定するだけじゃないのか?

あ。俺は Emacs + pcl-cvs だが。cvsweb は w3m で見る。
コーディングからデバッグ、バージョン管理まで Emacs で完結。

VSSのように使いづらいインタフェースに縛られることなく、
CVSやSVNは自由に自分の使いやすいのが選べるのは良いね。

>>541
それはmakefileのコンパイルスイッチも解析して色分けしてくれるの

>557
ネストしないならコメントでいいじゃん。
つうか再発防止の為なら、コメントにして「コレじゃダメだった」とでも書いとこうよ。

あと>535で #ifdef 0 を華麗にスルーしてたのが恥ずかしいからって、
責任なすり付けるのはイクナイ。
というかみんなスルーしてるのに、自分で掘り返してどうするw

あげ

オイラが余計なことを書いたばっかりに・・・。すまん

/* ----------- 仕様変更のため、ここから削除 ------------
　　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のネストが増えていく。

しつこいぞ

まとめてみますた。(何を?)
>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

>586
刑: トリップ剥奪
半年名無しに戻ってろ

つーかソースコード論は他でやってくれないか

ぱっと見て「ヘタだなぁ」と思うコード その4
ttp://pc8.2ch.net/test/read.cgi/prog/1152383007/

とか

さあさあ、ageていこうぜ。

あなた達はそんなにも愚かなのに、バージョン管理を使わないことに対する
ヘタクソな言い訳だけは湯水のようにあふれ出てくるんですか？


ああわかった。
普段から言い訳にばっか頭を使ってるから、大事な思考能力が欠けてるんだなｗｗｗｗ

確かに。こんなことでグズグズ言ってるやつはまあダメだな。

69式のおっさんが悪いんだよ

いや、69式のおっさんは悪くない。
「#if 0」や「/* */」でコメントアウトする人が悪い。
閉じ忘れを防ぐのと、差分を見るために「//」を使うのがスタンダードです。

69式のおっさんはそれなりに技術はあるが
最近は酒の飲みすぎで脳のシナプスが溶け出しているふしが見受けられる

大体チーム開発でコードを共有するなんて嫌だな
Java厨あがりの糞コードなんてメンテできんわ
かってに動かないソースをいつまでもいじっとけ
という俺はVSSで細かくラベルをつけている。
おいVSS使うときは動作したタイミングで必ずラベルつけとけよ！

糞コテ氏ね

if(糞コテ == 69式 || 糞コテ == おじゃばさま){
　goto abone;
}

Cソースでは「//」によるコメントが使えないから、 >>596 のような
おじゃば様は、自分で理解できないという理由で、必要なコードを
ばっさり消してしまうのですね。

C99準拠のコンパイラ使えよ。カス

>>600 よりによってgotoかよ。さすがは低スキルだな（ﾌﾟ　
goto論者も死んでいいよ。
gotoを言語仕様からはずしたJavaは神

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;
}

>>603
しかし何故か Java の予約語には goto が存在する。

それはgotoという名前を関数名や変数名からすら排除するため

class goto {
　private String goto;
　public goto(String goto) {
　　this.goto = goto;
　}
　public String toString() {
　　return goto;
　}
}

＞　int c = b/*p; ←あ、ここに、ここに…
それって、
１．　b　割る　*p
２．　b　の後からコメント開始
のどっち？

>>608 2になる

なぜならば
コメントはプリプロセスの時点でなくなる予定だから

ミドルでは常識なgoto
ifでハンドルするとくそくどいコードになる。
Java厨はミドル経験ゼロだからgotoを叩くｗ
void handler()
{
　//メモリ割付
　//エラー発生
　goto unko;
　//メモリ割付
　//エラー発生
　goto unko;
　//処理
　//エラー発生
　goto unko;

　return;
unko:
//メモリのクリーンアップ
　return;
}

Java厨きえてくれ。
自分のいる狭い箱庭ワールドの常識しか見えないんだから。

バージョン管理ﾏﾝﾄﾞｸｾ
↓
使わないほうが無能
↓
使うﾒﾘｯﾄあんの？フォルダコピーでいいじゃん
↓
はいはいわろすわろす
↓
バージョン管理について誤解したまま叩きはじめる
↓
CVS対SVNの信者論争
↓
そもそもソースを整理すれば必要なし
↓
そもそもバージョン管理使えない奴はコーディング能力も(ﾌﾟ
↓
goto論争
↓
Java厨叩き　←　いまここ

>>611
Java の場合そういうのは try 〜 catch とか使うから goto 不要。
C はないから goto 使った方がそのように見易くなる。

try catchがネストしまくり
醜いコードでも満足な馬鹿なJava厨
シンプルにはどうしてもなれないのだ。

goto sentai boukenger

goto Java叩きスレ

>601
言いたいことを長々とクドクド書こうかと思ったら、
602と603に的確に簡潔に言われてしまったので、今回は出番無し。

コードを簡潔にかけない時点で無能

>>613
何のスレなんだよ、ここはｗ

大丈夫。バージョン管理してあるので

>CVS対SVNの信者論争

この辺りまで戻れます。

goto＋行番号
これ最強。食わず嫌いはよくないね。

関数内でのgotoなら別にいいだろ。

C++で、例外使えない環境ではgotoを、こんな風に使ったり・・・

〜雑多な処理〜
if (isError) {
result = ERR1;
goto error;
}
〜雑多な処理〜
if (isError) {
result = ERR2;
goto error;
}
〜雑多な処理〜
goto finally;

error:
〜エラー処理〜
finally:
〜最後にすべき処理〜
return result;

素人に使わせたくないものは、「使わない」をデフォにしておくべきだ。
素人にこそ使わせたいものは、「使う」をデフォにしておくべきだ。

漏れ的にgotoは前者、バージョン管理ツールは後者

で？主観に基づく>>625の内容のどこに合理性と普遍性があるの？

>611
そんな常識一度も聞いたことがないぞ。ifネストが深くなってしまう部分の
処理は、大抵別の関数として独立させることが可能なものだ。

しかし、コードの再利用とか、モジュール化といった概念と無縁のケツ穴
野郎は、一本グソがお好みなので、あちこちにクソをまき散らすのだ。

そもそも、returnが2箇所あるのが、糞コードであることを証明している。
そんな厨房は、メモリだけ解放して、関数内でオープンしたハンドルを
閉じるのを忘れたコードを書いてリソースリークを発生されるのだ。

そして、じゃば房は、C/C++にはガーベージコレクションがないから悪いと
言い。VB房は、わざわざ代入コードを書かないと変数が初期値されないのが
悪いと、決まり文句の言い訳をする。>611
そんな常識一度も聞いたことがないぞ。ifネストが深くなってしまう部分の
処理は、大抵別の関数として独立させることが可能なものだ。

しかし、コードの再利用とか、モジュール化といった概念と無縁のケツ穴
野郎は、一本グソがお好みなので、あちこちにクソをまき散らすのだ。

そもそも、returnが2箇所あるのが、糞コードであることを証明している。
そんな厨房は、メモリだけ解放して、関数内でオープンしたハンドルを
閉じるのを忘れたコードを書いてリソースリークを発生されるのだ。

そして、じゃば房は、C/C++にはガーベージコレクションがないから悪いと
言い。VB房は、わざわざ代入コードを書かないと変数が初期値されないのが
悪いと、決まり文句の言い訳をする。

出口は一つでないといけないてのは今は流行らないらしい

メモリ割付のケースによるんだけどね
出口ひとつも可能かな
void handler()
{
　//メモリ割付
　//エラー発生
　goto unko;
　//メモリ割付
　//エラー発生
　goto unko;
　//処理
　//エラー発生
　goto unko;

unko:
//メモリのクリーンアップ
//確保したものだけを開放する
　return;
}

ようはソース管理ツール使うのを議論する前に
ソース管理ツールにチェックインする品質のソースじゃないと
いれても意味がないよ。金庫にごみをいれるようなもの。

フェラーリにDQNが乗ってるようなもんかｗ

returnを一つにするテクニック
その１
void foo(void) {
　if(...) { goto end; }
　if(...) { goto end; }
end:
　return;
}
その２
void foo(void) {
　while(1) {
　　if(...) { break; }
　　if(...) { break; }
　}
　return;
}

それﾌﾙ >>632

いまはどのコンパイラにも、try __finallyがあるお。

>628
プログラミングスタイルは流行を追いかけるような性質のものではない。
出口が増えたら、トレースの際のブレークポイント設定も面倒だし、何より
それだけバグがテストケースをすり抜けてしまう潜在的可能性が増えるん
だけどな。

おまえら、テストファーストとか言ったり、目視デバッグで済む様なコード
にCppUnitとか使ってコンパイラにバグがないことを追証してないよな。

>630
言ってることが正しくても、説得力がない。

きれいなコードでも実行時に「どろろ」ってなるのもだめ。

百鬼丸 sage!

バージョン管理の必要性とソースの書き方は全く意味が違うと思うんだが。

汚いソースはバージョン管理する意味がないのか？
細分化されPG毎に完璧に管理されたソースはバージョン管理する必要がないのか？
オブジェクト指向で書かれたソースはバージョン管理してそうでないものは管理する価値がないのか？

意味のない議論をするなよ。これじゃただの信者論争だろ。
使いたきゃ使え、いらんと思うならやめとけ、使っても使わなくても痛い目見るのは自分だ。

使ってるさ。当たり前だろう。
動作もしないアーカイブにラベルつけて保存するのは
やめてくれと言っているんだ。
そしてそういう馬鹿は100%Java厨だ。

漏れ「チェックアウトしても動かないんだけど」
Java厨「んなことないはずっす」
漏れ「ほれっ」
　どろろろろろろろろろ、そして500番
Java厨「これは漏れさんがなにかXMLの設定を間違えてるんすね」
漏れ「やってみてよ」
Java厨「しゃこしゃこ」
　どろろろろろろろろろ、Out of Memory!
漏れ「いつまでも糞アプリいじってろ！」

ここでぬるぽ

>>633
VC8でエラー出たぞ・・・try, __finallyの組み合わせ

>639
アーカイブをバージョン管理？テスト中に？あまりやらんな。
それをやるのは、むしろコンパイルオプションによって動作が変わるのC方だろう。
それどころか、ヘッダーファイルがあるCの方が、全体コンパイル時にコンパイルが通らないと、
毎回大騒ぎしてるぞ。

100%Javaとか言うならせめて根拠を示してくれ。C厨は妄想家が多いのかな。

月曜からの結合試験
Java使い「さあ、結合試験やりましょう。準備はいいですか？」
C厨1「ちょっと待って下さい。コンパイルエラーが...。おい、○○さんはどうした。」
C厨2「○○さんは休日出勤して、今日は遅刻みたいです。日曜日にヘッダを変更していますね。」
C厨1「仕方ない、ヘッダだけ戻すか...。こんどは別のエラーが。いったいどのヘッダーを戻せばいいんだ。
　　　誰か分かる人はいないのか。」
C厨2「チーム全員いません。昨日で力尽きたのかもしれません。ああ、新人さんが来ました。」
新人さん「ああ、それはちょっと○○さんに聞いてみないと。あ、電話してみます。」
C厨2「コンパイルエラーで結合試験どころか、他の単体試験をやってる人も困っています。」
新人さん「○○さん、今から来るそうです。...寝ていたみたいです。」
C厨3「おいおい、どうなってんだよ。コンパイルエラーじゃ、試験も進まねーぞ。
　　　やってらんねーな、タバコでも吸ってくるか。今日は仕事にならねーな。」
C厨1「とりあえず、コンパイル通るバージョンまで戻すよ。少し待ってくれ。」
C厨2「どうですか？C厨1さん。」
C厨1「...先週の月曜まで戻った。」

>>639
javaのEJBとかいうの弄ってたときに悪夢のような数と質のエラーが出まくった。
（しかも、俺が出したわけじゃない。でも、動かないままにして帰る糞野郎が多かったから仕方なく直した）
EJBは俺の人生で１番か２番目ぐらいにブチキレた瞬間だったかもしれん。
俺のわけがわからん仕様ライブラリランキングで１か２位、
少なくとも３位には確実に食い込んでくるほどのわけのわからなさだった。

MSのOLE/ATLに並ぶぐらいわけがわからなかった。
ちなみにSwingは5位ぐらい。

あほか

>>645
てめぇのほうだろ！
死んでろ！

ガキの喧嘩か

>>647
はぁ？つまんねぇんだよ！消えろ！

おじゃばさまは以前のJavaスレで、maven等を長文で熱く語るJava厨様に比べると随分と小物だな。

>642
>それどころか、ヘッダーファイルがあるCの方が、全体コンパイル時にコンパイルが通らないと、
>毎回大騒ぎしてるぞ。

「ヘッダーがあるから」っつーのはおかしい。
ヘッダの扱い方が間違っているだけだと思われ。
さもなきゃ個別にコンパイルが通るものを寄せ集めたら通らなくなった、
なんて事はありえん。（リンクエラーは起こりうるが）

C言語が小規模、少人数の開発にしか向いて無いのは２０年前から既出だろ

↓バージョン管理ツールの話題に復帰

antもmavenも糞だよ。
どれぐらい糞かっつーと、makeと同じぐらい糞。

mavenはともかくantはmakeより使いやすいだろ

>650
自分で理解できないエラーをすべてコンパイルエラーと称しているんでは
ないかな？　あるいは#pragma onceに対応していないコンパイラ用のソース
でよく見かける

#ifndef __xxx_INCLUDED__
#define __xxx_INCLUDED__

// ヘッダ本体

#endif

の意図を理解していなくて、複数のヘッダで同じ「__xxx_INCLUDED__」を
使っていて、インクルードの順序や親子関係によって、特定のヘッダが
読み込まれない状況が発生しているとか。

そもそも、全体結合だからといって、全コンパイルの必要な理由もわか
らん。

仮に、各ソースに、単体テスト用に

#ifdef UNIT_TEST
int main(int argc,char **argv)
{
　　// 単体テスト用のコード
}
#endif

みたいなソースが含まれていたとしても、コンパイルスイッチを変更して
各モジュールをコンパイルすればいいだけ。

アーカイブを全チェックアウトして環境が再現できないような
使い方しかできない低スキルならさ
ソース管理ツールなんて使うなよJava厨。

どろろろろろろろろろろろろろろろろ〜

>>653 antはやりたい機能ごとにいちいちタスクの使い方を覚えなきゃならんのが面倒
しかも痒いところに手がとどかな一つーか、ちょっと凝った事をやらせようとすると
結局自分でantタスクを書かなきゃならんので余計に手間がかかる気がする

makeは依存の仕組みが変態すぎてついていけん。

mavenは単なるオナニー

結論、どれも糞。シェルスクリプト書いたほうが何ぼかまし

その気持ちはわかる。まーJavaならantでいいけど。

まー


昼飯でもくおうぜ

どろろ定食たべてきた

>644
俺もEJB被害者で、EJBは不要だと思っている。あれはEJB考えた奴が悪い。
だからJavaの問題じゃなくて、EJB考えた奴らの脳が腐ってたためだから、参考にしてはいけない。

>649
それは是非とも見てみたいな。
コピペしてみて。

>650
システムやサブシステム「共通のヘッダファイル」が修正になった場合だよ。
システムが大きくなると、共通ヘッダを修正した人が毎回コンパイルを全部やり直す事をしなくなったり、
チェックインタイミングのずれによって使用するヘッダが変わるから、
「コンパイルが通らなくなっているのに気が付かない」って事だよ。

>>661
>EJB考えた奴らの脳が腐ってたためだから
やっぱ、そうだよな。こんなガラクタ早く捨てなきゃ駄目だ。
せめてJSPにしようぜ。

>654
誰に言っているのかよく分からないが、内容的におかしいので言っておこう。
「自分で理解できないエラーをコンパイルエラーと称している」？
理解も何もmakeが途中で止まるのがコンパイルエラーだろ？誰でも分かるんじゃないか？

コンパイルエラーが自分で解消できないのが問題だって言いたいのかな？よくわからんな。
次の内容の「2重インクルード防止を理解していない」ってのだが、
さすがに共通関数を作っている人はある程度技術のある人だから、そんな事はないだろう。
ライブラリにmain()を入れてしまうなんて事もないだろう。
素人じゃないんだから、さすがにそれは失礼なんじゃないか？

結局、共通ライブラリを修正している人達の中で、数人が同時期に修正したため、
それそれの持っていたヘッダファイルにバージョンの差があって、相互に相手の古いヘッダを
使用していたため、全て最新にするとコンパイルが通らなくなるって事だったらしい。
分かった？

>655
俺に言っているの？
客先リリース後ならともかく、アーカイブをバージョン管理なんてしないって言っているんだけど。
何言っているのかわからんな。
ソースからアーカイブが再現できないのは、コンパイルオプションがあるCだろ？
あと、高スキルしか使えないソース管理ソフトの方が意味がないだろう？
いまいち意味がわからん。日本人じゃないのか？

EJBってなんて楽なんだろうと思える糞フレームワークに関わったことがある

>>663
くずなJava厨が大勢集まり、糞コードを書いては
チェックインするのか。それじゃあ全体でびしっと動作するバージョンって
作れないからラベルもつけられないよね。

>663
>理解も何もmakeが途中で止まるのがコンパイルエラーだろ？誰でも分かるんじゃないか？

(1)ソースファイルをオブジェクトファイルに翻訳する処理　（コンパイル）
(2)オブジェクトファイルをライブラリにまとめる処理
(3)オブジェクトファイルやライブラリから、　実行可能なファイルを生成する処理　（リンク）
(4)(1)〜(3)で生成したファイルを、補助記憶装置に配置する処理　（インストール）
(5)(4)で配置したファイルを削除する処理
(6)(1)〜(4)で生成した一時ファイルを削除する処理　（クリーンアップ）

makeは(1)〜(6)の処理の実施を補助するためのツールです。
つまり「makeが途中で止まるのがコンパイルエラー」は不適切です。

まァ、おじゃばさまは大人しくJavaでも使ってて下さい。

えーと、結論は

お前ら好きなツール使えや

でOK？

>667
いや、「身の丈に合ったツールを使えや」ですかね。
不相応なツールを使う　or　適切なツールを使わない
がイクナイ。

>>668
最初は誰でも身の丈を越えたツールを使う事になるんだよ。
そんな事言ってたら何も使えない

VSSでの出来事
C++プロジェクト　フルチェックアウト25Mバイト
チェックアウト−カシッ−＞シャコシャコ−＞完了

Javaプロジェクト　フルチェックアウト 528Mバイト
チェックアウト−カシッ−＞どろろろろろろろろろろろろろろろ
ろろろろろろろろろろろろろろろろろろろろろろろろろろろろろ
ろろろろろろろろろろろろろろろろろろろろろろろろろろろ
この間10分−＞やっと完了

自分でバイト数書いておいて何言ってんだ？

おなじ機能を実現するのにも
これだけファイルサイズの違いが出ることを言いたかったのだが
それを気づいてくれないとはおぬしJava厨だな。

出ねーよ、Javaのほうがコード量少ないだろ

Javaでサイズが大きいのは、ほとんど外部依存jarのせいだろう。
C++でサイズが小さいのは、OSに最初から入ってるor別インストール済みの
外部依存dllをチェックインしてないからだろう。

外部依存のjarは、動作検証したものをすべていっしょに固めて
おかないと動作しないのがJava

C++はOSのパッチレベル程度の差分しかないので無問題

> 外部依存のjarは、動作検証したものをすべていっしょに固めて
> おかないと動作しないのがJava

こいつ頭おかしいだろ？夏郎が煽ってんじゃねーよ

どろろが怒っているぞｗ
Java厨は本当の事言われるとすぐに切れるのが特徴。

> 本当の事言われると

だから夏郎は知ったかしてんじゃねーって

StringBuilderを実装したマイ外部依存jar
チェックアウトした環境がjdk1.4.xだった

Oracle 8i(Linux)をインストールしようと思ったが
IBM jkd1.1.8をいっしょにかためておかなかったから
インストールできないとか

で？

ちょいと古い環境にチェックアウトしたら
推奨されていませんの嵐になったとか

UNICODEが化けるとか

でないはずの500番がでるとか
いろいろあるでしょう。

> 古い環境にチェックアウト
古いコードをじゃなくて？

Unicodeって何だよ、絞れよ
エンディアンに依存するのはJavaの話じゃない

> でないはずの500番がでるとか
コードが悪いんだろ

いろいろ無いから。

Javaは重いスレに帰ったら？
レベルが低すぎて話にならん

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

で、前例から何も学ばす自分の経験だけのオレオレ手法で行くわけか。

おじゃばさまに変わる人気者
それは>>684

無知のまま居座れるって怖いな
２ちゃんねるそのもの

>685
前例じゃなくて、マスコミをはじめとする文献や世間一般、著名人といった
権威に弱いだけだろ。

>666
タイトル見ると、多分俺の言いたいことも分かっていて、無意味知りつつ書いているようなので、
その潔さに敬意を表してそれなりのリアクションを取らせてもらおう。
「ふーーーん」

>675
俺も676と678に同意。
そういえば夏休みだな。オマエラ休みは何日？

>688
いやマスコミと権力に弱いのが学生、実績と経験に弱いのが社会人。

>>689
>実績と経験に弱いのが社会人
これ普通に弱いだけじゃん・・・

元は何を話すスレだか知らないけど、随分レベルの低いスレだね
恥ずかしくないの？

バージョン管理ツールは余裕がないならやめといた方がいい
なぜなら管理ミスで逆にわけがわからなくなることがあるからだ・・

俺は治したソースは毎日フォルダを日付名にして保存している
それを後でdiffで比べるほうがよっぽど安全、完璧だよキミ

>>692
しつこいな身の丈にあったツールを使えって事でFA出てるだろ

誰も同意してないｗ

だが誰も反論してないな。

おまえら！バカとブサイクこそバージョン管理使え！

>>695
別にバージョン管理つったって、バージョン管理してる奴が納得できる状態のソースでないと
上げると起こられるから結局、自分でソースのバックアップとって管理してるから俺んところだと意味無し。
上げるときだけチェックアウト→手動でマージ→チェックイン。ハイハイ。ウンコウンコ。

＞なぜなら管理ミスで逆にわけがわからなくなることがあるからだ・・
それはあんたが間抜けなだけじゃん

間抜けなJava厨兵隊たちがデグレードしたソースを無造作にチェックインする。
管理したくともできない。それはPGの責任。
馬鹿なJava厨兵隊は戦う気がないヘタレばかり。

デグレードする前のソースや、
どこが変更されたかわかるのが
バージョン管理ツールの利点。

デグレードしたことにぜんぜん気づかず
気づいたときには、手遅れになるのが
バージョン管理ツールを使わなかったやつの運命

>>699
病院に帰ろうな

おまえら早く寝て明日の仕事にそなえとけよ

>>702
テキトーでいいんだよ。
仕事なんてどうせ良し悪しもわからん奴が上司なんだからｗ
アホかｗ真面目にやんな。疲れるだけだぞｗ

>>700 まあ、それが結論だな

>>699
チェックインする前にレビューしろよｗｗ

>>692
お前学生だろ？　もしくは超小プロジェクト？
5人以上で、同一ソースツリーいじるなら、普通に使おうよ。
20人超のプロジェクトで、バージョン管理システムなしとか、成立不可能だろ。

色んな香具師が書いたソースを集めてリリース版をビルドする人の身にも成ってみろい

バージョン管理ツールを使うのは当たり前。
こんなもの使ってえばりちらしているここの主Java厨は
ほんとに低レベルだな。

2人でもバージョン管理ソフトはあった方がいい。
自分のスキルに合ったってのは間違いで、みんなバージョン管理ソフト使うのが正解。
問題なのは使い方を間違っている場合と、手順を守らない人がいる事。
たとえばVSSの場合は、必ず守らなければいけないのは以下の通り。
・アカウントは必ず個人毎に作成する。
・編集する時は必ずチェックアウトする。
・コンパイルの通らないソースはチェックインしない。

ただしこれでもチェックアウトせずに編集して、上書きでチェックインする人が最初は何人か出る。
これを見過ごしてはいけない。アカウントを個人毎に作成すれば誰がやったか分かるので、
その人は見せしめになってもらう。
「あなたのチェックインした所は全部差分がないかチェックしてください。
　差分があったら修正して、関係する試験を全部やり直してください。明日までに。」
大体これで2度と違反しなくなる。
こっそり直したり、うやむやにしてはいけない。手順を守らない人が1人いるだけでみんなが迷惑する。

そもそもチェックアウトしてなくて、書き込み禁止属性の共有ファイルに
エクスプローラなどで強制上書きするんだから、チェックインなんてする
わけないし、チェックイン操作できないだろ。

しかも大抵の場合、VSSへのログインの手間を省くため、ネットワークのファ
イル共有のアカウント/パスワードと、VSSのアカウント設定が同じだったり
するんだから、始末が悪い。

というより、これでバージョン管理してるだって？低レベルのJava房が笑わ
せてくれるわ。Java房をプロジェクトから排除するのが、品質向上の解法。

>710
日本語で頼む。

>>709
VSSやCVS使っていても､しっかりとした管理者が目を光らせていないと、まったく意味がないということだな。
なんか入れることがほとんど目的になっている部署があるし。

>なんか入れることがほとんど目的になっている部署があるし。
それは、バージョン管理ツールの問題じゃなくて、あなたの会社の問題だから
ここに持ち出してきても解決しないと思うよ。

>>713
だいたいが絡んでるんだけどなｗ

だから、Subversion使えって。重いけど。

CVSとかVSSとか、簡単な抜け道があるようなバージョン管理ツールは管理能力が低い

CVSじゃもはやスタンダード。
SVNの付け入る隙は無い。

ディレクトリ移動、ファイルの削除が出来なくて何がスタンダードか…。

うちは毎日帰る前にチェックインが義務付けられてるな
各個人以前に管理のルール自体がクソだとアレだな

バグが残ってたら帰れませんね、大変そう

その場合、１日で終わらない修正はbranchする、ってルールをつけくわえるだけでいいんだよな。
でも、なぜかbranchするのを妙に臆病になってるトコが多い気がする。

てか、毎日チェックインはなんのためにやるのかわからない。
他の奴に触らせたくないからチェックアウトしてるのに、他の奴に触らせたくない状態でチェックインさせるなよ。

でも同期は細かく取ったほうがいいわけで。
単に作業状態を保存するチェックインと
完成したコードのチェックインという二段構えの構造があればいいんだけどなあ

>710
俺も711の言う通りを希望なのだが、同じ事を言っても仕方ないので少し説明する。
「編集する時は必ずチェックアウトする」ってのは、
「チェックアウトせずに、エクスプローラーで書き込み禁止を解除して編集し、そのファイルをチェックイン」
したり、
「自分のローカルで手動バージョン管理（ファイル名変更）とかしていたやつを、戻してチェックイン」
する人が最初は少なからず存在するって事だ。こういう事をするなって事。

ネットワークアカウントとVSSアカウントが同じ？
なんだかしらんが、俺が言っているのはVSSアカウントの方で、それを個人毎につけろって事。
Windowsのネットワークアカウントは好きなの使え。Administratorでもいいんじゃね？
ネットワークログインが面倒なら「ネットワークドライブの割り当て」でも使えば？

>712
管理者が必要というより、最初に手順の説明と文章化が必要と言う方が近いかな。
最初に全員集めて、チェックアウト、チェックイン、チェックアウト取り消しの説明を
実際に誰かにやらせて説明する必要があるって事。面倒だと省略する所が多い。
実際にやれば説明には10分もかからないのだから。
あと文章化しておいて後から入った人にも徹底させる事も必要。
それとしくじった人を見せしめとしてさらすことも。

>718
「編集の必要ないファイルは帰る前にチェックインしておく」ってルールが、
「編集の必要のない」と言うのが抜け落ちて、変な風に残ったんじゃないか？
開発者の中には朝に必要と思われるファイルを大量にチェックアウトして作業する人もいて、
そのまま忘れて帰る場合があるので、それに対する警告だと思う。

基本的に編集が必要になったファイルだけチェックアウトすべきだが、
作業量が多い人はそんな面倒な事はやってられないって人もいるからな。

編集中のファイルは無理にチェックインしてはいけない。ブランチなんて不要。
チェックアウトしたまま帰るべきだ。

前にいた馬鹿なJava厨の話
プロジェクトにないクラスを勝手に作った。
こいつはVSSにこのクラスを追加しなかった。
リーダはVSSを使っているので不足なファイルは無いと信じていた。
Java厨のローカルディクスをフォーマットした。
依存関係のあるソースのコンパイルが通らなくなった。

Java厨Java厨っていうけど、ただの厨なだけじゃないかな。

>>725
それはJAVAじゃなくても・・・

CSVの使い方知らない奴にCSV使わせると碌な事にならん
ライブラリとか文字コード変換されてプロジェクト全体が一時麻痺したときはあせった

>>725
そのバカをつるしあげて全員にバージョン管理を徹底させるのは当然のこととして、それでもバカを使うためにはまだ検討の余地があると思う。

１．定期的にまっさらな環境で全コンかければもうちょっと早いタイミングでわかったんじゃないか？
２．クライアントツールで追加漏れファイルがある事を容易にわかるようにできないか？

オレのところではビルド専用PCを立てることで１の問題は解消した。

２についてはVSSからsubversionに移行することで解決したが、これはチーム全員がVSSに強い不満もってたからできた話。大概はそんなホイホイ移行できるわきゃないわな。うーん、VSS2005なら回避策あんのかな？

全コンっていうか、Java厨くんしか持ってないんじゃもともとJava厨くんしかビルドできないじゃん
そもそもディスクをフォーマットするっていうのがバカだし

>>4
> この手のツールは結局
> 人がルール守らないから強制させる為の物
> 無くても出来るではなくさせる為の物だから必要
> ただその運用も守らないからあっても意味無い所が多いのには同意

お前はなにもわかってない。
まずはSubversionを使ってから発言しろ。

強制されるものではない。開発効率があがる。
むしろ、バージョン管理システムがやるべきことを人間に強制させる
ことのほうが意味がないどころか非常に非効率でミスが多い。

人間とは、機械と比べ信用できない存在なのだよ。

>>9みたいな時代遅れなオッサンってまだいるんだな。
そのローテクさ加減には驚くばかりだ。

>全コンっていうか、Java厨くんしか持ってないんじゃもともとJava厨くんしかビルドできないじゃん
問題なのは、それを誰も認識できていなかったこと。
定期的にまっさらな環境にexport->全コンしてれば、必ず気付く。

どんなプロジェクトにもバカは紛れ込むが、事前に対策をしておけば他のメンバーへの被害は最小限に抑えられる。

と、ニートが申しております

確かにクラスの入れ忘れなら他の人がコンパイルすれば、ほとんどの場合はコンパイルエラーで気が付く。
ただインスタンス作成して呼び出すような場合は、コンパイルでは分からないから、
入れ忘れを完全に防ぐのは困難だろう。まあ、上の例はコンパイルで見つかる一般的な物だったようだが。

この場合は無理にシステムでどうにかしようとする必要はない。
単に入れ忘れた人を見せしめに、
「ではまた作って、試験をやりなおして、チェックインして下さい。明日までに。」
と言えばいい。これで入れ忘れも減るだろう。
それまではダミーのクラスでも作ってコンパイルを通るようにしておけばいい。

>735
> ただインスタンス作成して呼び出すような場合は、コンパイルでは分からないから、
> 入れ忘れを完全に防ぐのは困難だろう。

またまた、おじゃばさまの馬鹿っぷり炸裂。

インスタンス作成ってことは、そのクラス定義のヘッダをインポートして
いるはずだから、まずコンパイル時に「インクルードファイルが見つから
ない」エラーが起きる。仮にヘッダのみがあって単体でのコンパイルでは
エラーが起こらなくても、リンクエラーで判る。

> それまではダミーのクラスでも作ってコンパイルを通るようにしておけばいい。

こういう馬鹿が一匹でも混じっていると、全体ビルドでクラスの整合性が
とれなくなるわけだな。(w

＞736
つ Class.forName

>737
そのクラスが、引数を必要とするコンストラクタしか定義されていない
場合や、コンストラクタがprotectedで、シリアライズ機能からオブジェ
クト構築することし許されていない場合もあるわけだが？

前にいた馬鹿なJava厨の話2
漏れ「Java厨太くん、ここではVSSでプロジェクト管理しているから
動作バージョンはラベルつけてもいいですのでしっかり管理して下さい。」
Java厨太「え・僕はEclipseのプラグインがサポートされていないものは
使う気がしませんので使いません。」
漏れ「あのこれはここの業務仕様なので厳守してくださいね。」
Java厨太「動作バージョンができたらjarにしますのであとはそちらで」
なんていうやりにくい馬鹿もいたっけな。

「これは業務命令なんだよ！
従えないならその腐れエディタごと窓から放り投げて
キモいJava厨同士でXPでアジャイルなペアプロごっこでもしてろや、ゴるぁ！！！」

でFAじゃね？

>>739
つ[http://sourceforge.net/projects/vssplugin]

>>741
Error!
Invalid Project
だそうです。

>741
Bugs : (48 open / 296 total)
Bug Tracking System

ページを表示できませんｗ
ああ、絵栗糞低品質プラグイン地獄

なぁ、バージョン管理ツールってバックアップとれるの？

とれるよ。アーカイブもできるし
VSSだったらルートフォルダごと別の場所にコピーしておいても
バックアップになる。

>>736
>> それまではダミーのクラスでも作ってコンパイルを通るようにしておけばいい。
>
>こういう馬鹿が一匹でも混じっていると、全体ビルドでクラスの整合性が
>とれなくなるわけだな。(w
「無能な働き者は銃殺刑」という言葉を思い出すな。
こんなことされるくらいなら、コミットのやりかたをしらない「無能な怠け者」のほうがまだマシ。

ゲーテは「活動的な馬鹿より恐ろしいものはない。」と言っているな。

>748
耳が痛い…
勝手に関数の並び順変えて怒られた事がある。

んで、元に戻せと言われたけど、そのソースはバージョン管理もしてなかったし、
元の並び順も憶えてなかったんで、素直に「無理」と言ったら1時間も押し問答になった。
漏れが悪いのは分かるがどうしろと。

皆はこんな事にならんよう、バージョン管理ツール使うか
こまめにバックアップ取っておこうな!

>>746
その程度だったらSubversionでも可能どころか
SubversionではVSSよりももっと高度なことができる。

頭の悪そうなＣ言語厨くんが暴れているスレか。
いや、バージョン管理システムもろくに使いこなせない
時代遅れな頭が悪いC言語厨くんが暴れていると。

>>725
C言語厨馬鹿であるお前は頭が悪いから気づいていないようだが、
Javaに限った問題じゃないな。

VSSなんてチェックアウトするとロックされてしまうような
古臭いバージョン管理システムを使ってるからそういうことになるわけだが。

そこでJava言語にせいにして2chでしか愚痴をこぼせない馬鹿を演じてないで
バージョン管理システムもちゃんと選べないお前の組織を恨め。

>>721
VSSみたいなチェックアウトするとロックされる糞システムでも使ってるんだろ。
で、ロックされたまま長期海外旅行されると困るのでチェックインしておけ
っていってるんだろ。

バグのこしたままチェックインされたほうが迷惑なんだがな。

>>712
> >>709
> VSSやCVS使っていても､しっかりとした管理者が目を光らせていないと、まったく意味がないということだな。
> なんか入れることがほとんど目的になっている部署があるし。

そこでSubversionを使えっていってるわけだが。

VSSなんぞ論外。

Subversionならバイナリ差分アルゴリズムによりバイナリファイルの差分も取れるし
ファイル名の変更、移動をしてもちゃんとバージョン管理されている。

ＣＶＳはそれができないから糞。

>>692
お前みたいな馬鹿個人はつかわないほうがいいな。

俺様のチームに加わるならSubversionは徹底的に
使わせて貰うが。

>>679
ＪＶＭバージョンも明記されたＭａｖｅｎのpom.xmlもリポジトリに
一緒に追加しておけ。

ただし、settings.xmlはリポジトリには一切追加するなよ。
あれはそれぞれ個人で保有しておくものだからな。

>>675
FatJarでも使っておけ。

>>674
Jarsでも使っておけ

>>670
VSSしか使えないお前のプロジェクトに問題があるようだな。
Subversionのように差分だけチェックアウト(というより"Update"だが)
されるならそうはならんのだが。


おっと、VSSのチェックアウトとSubversionのチェックアウトは意味が違ったか。

VSSだとプロジェクト全体をチェックアウトするとすべてチェックアウトした奴の
権限になって他者にはロックされるからなw

>>667
いや組織でそんな考えで
バージョン管理システムを使われては困る。
自分のソースコードを自分専用に
管理するときだけ使うなら解るが。

それでも使い方がわからないやつに使わせると

プロジェクトに.vssというファイルやCVS、_svnというディレクトリができて
かなり迷惑だが。

それでパッケージ名にCVSや_svnと名が付くものができたりしてな。

ANtやMaven, Eclipseなどを使っていれば問題ないことだが。

>>662
お前の脳みそはもっと腐っとるよ

>>661
EJB3.0でお前は幸せになれる。
代わりにHIbernateやSpringやSeasar2で幸せになれるかもしれないが。

>>657
> >>653 antはやりたい機能ごとにいちいちタスクの使い方を覚えなきゃならんのが面倒
> しかも痒いところに手がとどかな一つーか、ちょっと凝った事をやらせようとすると
> 結局自分でantタスクを書かなきゃならんので余計に手間がかかる気がする
> mavenは単なるオナニー

お前が使いこなしてないだけだよ。

>>639
VSSなんか使ってるからそうなるんだよ。
CVSかSubversionに切り替えろ。
無駄な作業が減るぞ。

>>625
まるでコンピュータを使う者は素人で
そろばんを使う者が玄人だと主張してるかのような
愚かな発言だな。

>>613
お前がJava嫌いなことはわかった。
だがこのスレはJavaスレじゃないんだよ。
お前はVSSの話題を持ち上げようとしてるようだが
VSSなんぞバージョン管理ツールとして最低のブツなんだよ。

バージョン管理ツールの評価
Subversion >>>>>>>> CVS >>>>>>>> VSS

この構図に変わりは無い。

お前のレスを見ていると、
Javaのあら探しをしようとしてお前は
VSSの欠点を露呈してばかりでかえってお前を不利な立場に追い込んでいる。

お前は間抜けだよ。

>>598
ＶＳＳ厨あがりの糞厨にSubversionを
使わせてもプロジェクトの管理でろくなことがないな。

悪いけどお前みたいなのは即クビだわ

>>564
お前なんぞ、ワイパーを壊して
かわりに蠅叩きでもつけてる馬鹿だろw

VSSが糞なのは同意
CVS使いはじめて８年くらいになるがそろそろSubversionに移ろうかな

スレを流し読みしてみると
バージョン管理ツールを否定してる奴が
未だにいることが信じられないな。

以前書いたソースコードをどこかにとっておいて
無駄に重複したコードが増えてしまうやり方でもしてるんだろうか。

ソースコードを修正するたびに毎日毎日圧縮保存を繰り返すなんて
アホ臭い作業でもしているんだろうか。

>>364
IBMはDeveloper Worksでバージョン管理の記事を書いてるくらいだから
使わないと恥だろw

>>308みたいは香ばしい馬鹿は始めて見た

>>298
リポジトリをDBみたいにdumpで差分バックアップを
とっておけば無問題。

それでも怖いならミラーリングなりしておけばいい

>>121
最近じゃ種種のオープンソースのプロジェクトも
CVSからSubversionに移行しているところが増えている。
Apacheのプロジェクトとか

>>87
Bugzillaのようなバグトラッキングのことか。
それはバージョン管理とはまた別。

>>76
だからCVSやSVN使うときは
まず最初にUpdateを必ず実行してから
Commitする。

マニュアルにもまず先にUpdateを実行しろと書いてある。

>>71
Fedora Coreを使えばyumだけで簡単にインストールできる。

>>745
とれないでどうする。
バックアップできないとかどんな糞システムなのか。

SubversionではまるでDBのようにリポジトリを差分dumpできるぞ。

>>749
そもそも並び順変えられても困るようなプロジェクト管理してる
逆ギレしてる奴の管理能力に問題があると思うんだが。

関数の並び順変えたらわけわからんって
関数にちゃんとコメント書いてないか
無駄な似て非なるゴミ関数が乱立してるか何かだろ。
関数の名前も変なわかりにくい名前にしているとかな。

クラスやパッケージの中にまとめて分割統治してしまえば
そんな混乱も避けられるだろうに。

>>769
cvs2svnでさっさと移行汁

Subversionってだいじょうぶか？
オプンの得意技で動作不安定デグレしまくりとかないだろうな。

おい、はやくパンチングの作業に戻るんだ！

すでにかなり安定してるよ。
BDB使ってる頃はリポジトリが壊れる事も多かったがFSFSにしてからは
うちの会社で今のところそういう不具合は起きていない。

つーか既にリリースしてからだいぶたつし、バージョンも1.3.2まで進んで
その間も継続して改良＆バグフィックスがなされている。

もうそろそろ、かなり用心深い人にも勧められるぐらいになってきたと思うけど。

>>781
CVSと比べたら全然いいんだけど。


そんなことより、
動作不安定がオープン系の得意技？
何言ってんだこいつ？

>>752
>>753
VSSは多重チェックアウトが出来るわけだが

正直VSSは使い方がよくわからん
Subversionのほうが直感的だと思う

VSSはVisualStudio統合で使って初めて真価を発揮する

MS製品はMS製品で固めないと使いづらいってのはあるよなあ。
781みたいにオプソをやたら敵視する人がいるけど、オプソだと
使い勝手のいいのを自分で組み合わせられるってのは
ものすごい利点だと思うんだがな。
MS製品だけでなく、他の売りもんでも
動作が不安定なものはいくらでもあるわけだし。

MS製品はとりあえずポン入れするだけで全部揃うから楽っちゃ楽

VSSを本格的に使いたかったら
いくらかコストをかけないと逝けなくなる。
組織内でのアップグレード費用も馬鹿にならん

Java屋はライセンス費を払えない貧乏会社が多いのか。。。

単に費用対効果の問題だろ

バージョン管理ツールなら、NeoSteel社製のものが最高
https://www.neosteel.com/neosteelshop/shop/extras/index.cfm?fuseaction=start

あっ、バージン管理ツールの間違いだった。　てへっ！

>>791
今どきそんな煽りをする奴は
演歌歌手のコンサートに行く金も無いのかと
言ってるようなほど格好悪いぞ。

同様の効果が得られるなら安い方がいいよね
それをわざわざ高い方を購入するのは無駄遣いでしかないじゃん

■Java屋はソフトウエアはみんなただという恐るべき感覚
私の取引先のJava屋さんなんですけど、秀丸、Windows98
(アクティベーションがないからいまだに利用),Office2000
(同)のライセンスが必要な製品までフルコピーで使っています。
ソフトウエアはみんなJDKやEclipseと同じと思っているようで
正直恐ろしいです。

一部を見ただけで全てがそうだと決め込む考えは
確かに恐ろしいですね。

java屋だってそのまわりのDBは金がかかるのが多いからあんまり安いって感覚はないだろうな。

秀丸をフリーソフトと呼ぶ奴はむしろPHP坊だろｗ

つpostgreSQL

>736

>インスタンス作成ってことは、そのクラス定義のヘッダをインポートして
>いるはずだから、まずコンパイル時に「インクルードファイルが見つから
>ない」エラーが起きる。仮にヘッダのみがあって単体でのコンパイルでは
>エラーが起こらなくても、リンクエラーで判る。

何言っているかいまいち分からないけど、Javaの話でいいんだよな。
で、クラス定義のヘッダって何？あとインクルードファイルって何？あとリンクエラーって何？
C++と間違えたのかな？

で、737が言うように「JavaでインタフェースとClass.forName」を使った場合の事なんだけど、
738がまた何か言っているんだけど、「736=738」なのかな？
738は「引き数なしや、シリアライズされたクラスは、Class.forName」が使えないとか言っているのかな？
言っている意味が分からないので、できれば説明して欲しいのだが。

XMLを修正するためにJava屋にある秀丸を起動すると
「わたしは相当つかいこんでいます・・・」のダイアログが出る。

>>802
秀丸だけどフリーソフト公開して作者にメール出せば無料でライセンスとれるよ
なんでそうしないの？

そのJava屋とやらに言わんと話にならんでしょうに
なんで>802にレスするの？

ネタだから

>801
> 言っている意味が分からないので、できれば説明して欲しいのだが。

こういう馬鹿が一匹でも混じっていると、全体ビルドでクラスの整合性が
とれなくなるわけだな。(w

>>796
Javaを使う者全員がそうだと言い切る根拠を示してから
そういう断定的表現を使うんだな。

そのOfficeはOffice2.0の間違いかね。
OpenOffice2.0はタダで使える。
今どきWindows98を使って開発するくらいだったら
Fedora Coreで開発した方が効率が良い。
秀丸もそれこそEclipseやEmacsで十分だろう。

>>802
学生なら>>803のいうように、学生の特権として
作者にメール送れば
送金免除できる方法を教えてくれる。
非常に簡単だがな。

さて、バージョン管理とは関係ない話題で話を
そらそうとする馬鹿が現れたが、話を戻すとするか。

Subversionの隠しファイルは.svnから_svnに変更された。
これはドトネト厨の都合を考慮してのことらしいな

>>810 変更じゃない。選択可能。デフォルトは .svn 。

Java屋がWindows98SEにこだわるのには理由がある。
ファイルサーバに使うのだ。10接続しかできない
Win2K, XPではだめなのだ。ｾｺｲﾖﾅJava屋。

わざわざWinを使う理由が不明

ところで、今職場でJavaの開発にcvs使ってて、
subversionの導入を検討してるんだけど、
subversionの積極的な導入メリット／デメリットってなにかある？

ソース管理だけなら今のところはcvsでも困ってないんだけど、
仕様書の管理を始めるとバイナリに強いsubversionを、
って話なんだけど。

ちなみにcvsでも更新せずにコミットとか、
チェックアウトじゃなくてエクスポートして作業とか
そう言うのは割と頻度高し、な職場です。

そんな話はこっちじゃなくてsubversionスレ@プログラム板

ちっ、やくにたたねーな。

ちなみにWordやExcelは機能限定的だが、
subversionで版管理して、diffったりもできるぞ。
仕様書の版管理に悩んでる人にお薦め。
ってか誰か人柱になれ。

>>814 book 嫁

>>812
アホか。そんな糞OSをファイルサーバに使うなら
LinuxにSamba入れてファイルサーバとしてつかったほうが
セキュリティ上安全だ。

>>814
過去ログにもちゃんと書いてあるぞ。良く嫁

CVSや糞VSSと違って優位性が決定的なのは

ファイル名変更やディレクトリ変更/移動しても差分情報をバージョン管理できること
つまりプロジェクト単位で管理できることだ。
他にもバイナリ差分アルゴリズムによりバイナリファイルもバージョン管理できることだ。
しかもテキストファイルは行単位ではなく文字単位でバージョン管理できる。


それぞれのディレクトリやファイルにアクセス権限を与えることもできる。

>>818
漏れもそう思うしそう言ったよ。
彼らの言い分はLinuxにスキルが無いからこれが一番と言っていた。(Win98SE)

Java房ではないが、Windowsだと通るファイル名が、Sambaで通らない(ファ
イルが作れない)ことがあるんだけど？

Sambaのマルチバイト変換がおかしく成ることが昔よくあったな。
漏れが愛用しているRedHat8.xはWinのドメインコントローラとの
連携もばっちりだし問題ないけどな。
どのディストリビューション使ってる？

>822
登録商標記号(丸で囲ったRを使った文字)のファイル名とか通らんよ。

>>823
それか。その手のはファイル名として使っちゃいかんと思うが。
おぬしはどう思う。

そういやあ管理ツールに話を戻すがVSSに登録するファイル名に
$文字とか使えない制限があったような気がする。

使ったらいけないというのなら、
エラーで使えないようになるべき。

それはオープンソースクオリティ
文句があるならおぬしが直して公開するのが筋。

文句は無いよｗ
いつまでもバグが残るだけ。

お前も文句無いんだろ？
こうやって存知のバグが残りつづけるｗ

無いよｗ
ならば見て見ぬふりしれ

つうような事がオープンソースソース管理プロダクトにも
存在する可能性が高いと言う事を自己責任の元に使いましょうね。

バグ報告を聞いた人が
直さないからいつまでもバグが残る。
これがオープンソース。

gyaoでリナックスのドキュメンタリーやってるからお前らもみろ

>>831
なぜかバグが多発するのにそれをよろこんで使う
Java厨たち。やっぱり貧乏なのが使う理由なんだろうな。

結局win98seを選んだ奴は正しかったのか。

>>834
Yes ﾜﾗﾀ

>>820
JavaができるやつでそんなLinuxできない奴を
Javaアーキテクトとは言わせない。
そういうのはドトネト厨やC言語厨っていうんだよ。

>>825
絶対パスの先頭に$がついてるから
そういう制限があるのか。

アホくさいな。

>>827
>>827という返答が>>826に対するもので
>>826という返答が>>825に対するものであるという
リンクがあるなら、お前はVSSはオープンソース製品だと
主張しているということになるが、どうみてもそれはおかしいな。

>>828
オープンソースだったら目につくバグはすぐ治せる。
むしろM$のほうが自社製品のバグを治せない。

ま、M$もGoogle勢力によって落日を迎えようとしているが。
あのGoogleですらオープンソース製品を続々と出しているからな。

>>832
おい、どこのカテゴリでどういうキーワードなのか説明しろ。
動画探すのが大変だからURLかキーワードかタイトルか何かで
示せ。

Win98SE最強説。

>>831
いや、それはWindowsやM$ Officeを手がけるM$のことだろう。
バグがなかっらウィルスにやられることもないだろうに。

$とか使う奴とGoogle信仰してる奴って未だに居たんだな
同一レスから抽出できるとはおもわなんだ

>>833
ドトネト厨が使うドトネト製品群M$製品群のほうが遙かにバグが多いのだが。
どいつもこいつもウィルスに弱いしな。

>>843
$を使う奴とGoogleを信仰ではなく指示しているのがどういう関係にあるんだと。
Googleを使う奴は皆全員が$を使う奴だとでもいいたいのか？

いっておくが、PerlやPHPを使うと嫌でも$を使うことになるんだが。

win98se ＞＞＞＞＞＞＞＞＞＞＞＞ Linux + Samba

>>845
日本語でおｋ

>>846-847は小学生か？

そう、彼はデブ小学生

レスが早い

VSSしか知らないって痛いな

>>845はファビョりすぎて内容が支離滅裂になってると理解できんらしい

>>814
Tracが使える

>806
うるせー馬鹿。氏ね。

>>854
偽物乙。

>>855
偽者乙。

>>852
おまえのほうがファビョッてるとしか思えないんだが

>>857が本人だからね

今時M$だなんてUNIX板でも使わんだろｗ

「がんばれゲイツ君」とか喜んで読んでそうだな w

>>859
そりゃそうだ。UNIX信者はMSという企業を使うことはないんだからw

>>860
今だったらウェブ進化論を読むのがお勧めだぞ

オープンソースアプリがバグ直すの早いのって
まともにテストしてないからだよね。

　　　　　　　　　　　　　　　　 　 　 　 　 　 /i　　　　　　　　　　│
　　　　　　　　　　　 ,ｒ ''''' -、_,.. -- ..,,__ ,ノ ﾉ_,.::--､_　　　　　　│
　　　　　　　　　　　i' r''⌒ >｀　　　　　 ´　ﾐ+ｨ-‐-､ ﾍ　　　　　│
　　　　　　　　　 　 i !、 ／　　　　　　 　 　 　 ｀ヽ、,｝,|.　　　　 Ｊ >>863
　　　　 　 　 　 　 /'` `´　　　　　　!　　　　　　 　 Y ,!
　　　 　 　 　 　 /　　 　 　 i 　,r'ﾍ ,!　 l　 i　　 ,i　　 i
　　　　　　　　　i　　 ,i'　　 i　| {_ﾉ /､　ｌ! ,/,i　 /}i| 　 i
　　　　　　　 　 {/　 /　　 i ,/i ,rｧ=､,,｀ァ/|,i-''´ ﾉi　| |
　　　　　　 　 ／_,. /／　 i//λ代ﾂ!l Ｖ　|ﾄｧｪ< i　//
　　　　　　　´￣|　''´　　 | ''´.::::.｀´　　　､ｆ代）Vノｲ
　　　　　　　　 /ノ}　| |、i !、　,i　　!,___,.､′´::"ｸ　|
　　　　　　　　　 /ｲﾉ !|.!ﾉ｀`　i l　　.i'　　i"´　ノ,,ｲﾍ
　　　　　　　　　 　 　 ,| ヽ、　Ｕ ∧!-‐､ﾉ　 　 人!
　　　　　　　　 　 _,-'' .!　　｀ｰ　/｀ヾｬｰ'__,,.-ﾆ_
　　　　　　　,.:-''´　　-...,_　　　/　　　￣　　｀メ､
　　 　 　 ／　 　 　 　 　 ｀''-/　　　　　　　 '}＞__＼

>>864
なんかそのツールでこさえたＡＡってごちゃごちゃしててなんの絵かさっぱりわからん。

　　　　　　　,.:-''´　　-...,_　　　/　　　￣　　｀メ､
　　 　 　 ／　 　 　 　 　 ｀''-/　　　　　　　 '}＞__＼
　 　 　 /　　　　　　/　　　 ／　　　-､　i　ﾌ'´ ´　 ￣｀ '' ｰ- ､
　　　　i　　　　　　/.;'　　 ./　　　　　　`i"`-､_　 　 　 　 　 　 ｀ヽ、
　　　　!　 　 　 　 ﾚ　　　/　　　　　　　 i　　　｀ヽ、　　　　　　　:::::f'' ｪ_
　　　　 ! 　 　 　 /　　　 .!ｲレｖ,_ 　 ,、ﾉ!｝ 　 　 　 ＼　　 　 　 　 ::::::ゞ ,!
　　　 　 ＼　　　|　　　　　"|　　 ｀´fV/）　　 　 　 　 ', 　 　 　 　 　 ::::::::i
　　　　　　 i　　　!　　　　　 'i　　　,!:;:::;.:.　　　 　 　 　 ;　　　　　 　 　 　 l
　　 　 　 　 !　　　!　　　 　 ﾉ　　r';:ｿ､:i::.: 　 　 　 　 　 :　　 　 　 　 　 　 !
　 　 　 　 　 !　　　ヽ、_ _ノ'　　　ゞ' ノ:::　　　　　 　 　 ; 　 　 　 　 　 　 ,!
　　　　　　　　! 　　　　r 　 　 　 /　　　　　 　 　 　 　 !　　　　　　　　 /
　　 　 　 　 　 ＼　　　　　　　､-!　　　　　　 　 　 　 ,ﾑ_　　　　　　 ／
　　 　 　 　 　 　 !＼　r-､,,＿__V^''ー--.....,,_　　　 ノ　　｀''　ｰ-‐''´ !
　　　　　　　　　　ﾍ ｢入i'´ 　 　 `　　　　　　｀"ヾ´　　　　　　　　　/
　　　　　　　　　 　 ﾍ＼ ｀ヽ､__,,　　　　　 ＿ ヽ二_　　　　　　　 _ノ
　　　　　　　 　 　 　 〉　｀ー----――-=､ ヽ三ヽ ￣｀''ｰ-‐''T"
　　　　　　　　　　／ 　 　 　 　 　 　 　 　 ｀ヾ　　　　　　　 　 i
　　　　　　　　　/　　　　　　　　　　　　　　　　　　　　 　 　 　 i、
　 　 　 　 　 ／　　　　　　　　 　 　 　 　 　 　 　 _,　　 　 　 　 ﾍ
　 　 　 　 ／　　　　　 　 　 　 　 　 　 　 　 　 ／"ﾞ`　　　　　　 ヽ
　　　 　 /　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 　 ﾍ
　　　　/　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 　 i

>863
新たなバグが埋め込まれるのも早い。そして、完成前に飽きられてプロジェ
クトが放棄されるのも早い。オープンソースと称して、実用に耐えない
シロモノに税金を投入して溶かすのも早い。

>>863
そういうことを「オープンソース」でひとくくりにすると簡単に論破されるぞw

M$はM$という一組織とはいえ、オープンソースには様々な組織があるわけで。
まともにテストしてないところや頻繁にテストしてるEclipseやApacheなんてものがある。
まともにテストしてる組織のほうがバグ修正は早いぞ。
M$と違って開発者やテスターが何倍もいるんだからな。

>>866
よくわからない絵だ。
首無し人間か？

>>867
それはオープンソースではなくM$のことだね。

ま、そのM$もオープンソース製品を作っているわけだがw

それに気づかずにVSSマンセーしてオープンソース批判するのは
恥ずかしいぞw

>870
一言も、VSSマンセーなどと言っていないのに、自意識過剰のオープン
ソース房はこれだから始末が悪い。第一、オープンソースと違って、
マイクロソフトは税金を一銭も溶かしたりしていないわけだが？

854が本物です。
リンク厨の技法を真似て書いてみました。
あまり面白くなかったので、次回からは普通に戻します。

うっせー　どうでもいい

M$工作員ｳｻﾞｲ

何十年前の人間かと思うぐらいレガシーなのが湧いてるなｗ

「M$」という文字列を見るだけで、
そのレスを読む気が失せるよな。

ファイルロック少人数ベースのRCS　←　V$$の今ここ！
　↓
多人数同時編集のCVS
　↓
フォルダの変更追尾のSVN

>>871
今までのお前のレスを見ていると、VSSマンセーの匂いがするんだがなw

まだ何もわかってないな。
マイクロソフトがとある自社製品をsourceforgeに
公開したことを知らないとはおめでたいなw

>>876
臆病だな
VSSでファイル名に$が使えないからとそう僻むなよw

>>877
V$$ワロタ
ファイル名やディレクトリ名に$が使えないだけのことはあるわなw

おまいら、ここにも遠征してやってくれ。

＞Visual Source Safeに萌える香具師の集い
＞ttp://pc8.2ch.net/test/read.cgi/tech/1091615427/l50

M$ドトネト厨はエロ画像管理にVSSを使ってるのか(嘲笑

しかもバイナリファイルの差分も取れない癖にVSSでエロ画像管理してるw

エロ画像をバージョン管理する必要性がよくわからん俺ってやっぱDQN?

童貞

つまり「バージョン管理ツールは必要」って事で決着か。
きれいに収まったな。

画像の比較ツール程度なら簡単に作れそうなんだけどな。

複数バージョンのファイルを読み込む
↓
エンコードして単なるビットマップ形式に変換
↓
ピクセルごとに比較して差分の表示

実は、既にウチのグラフィックチームから要望が上がってるんだが
面倒なので無視し続けてる俺ガイル・・・

少しでも拡大縮小移動してたらダメじゃん

比較して何を差分としてだしてほしいのかで難易度が大幅にかわるな。
α要素の有無だけを判断するとか画像の拡大縮小は無視とか、
圧縮形式の違いも無視とか、正直詰めるとっていうかアリガチなフォーマットに対応するだけで
ゲーム１本作るより面倒そうで嫌。
アドビ社でも入れてもらえるんじゃねぇの？

>>887
その画像比較ツールならすでにTortoiseSVNにはついているぞ。

>>890
1.4.0 からね。まだリリースされてない。 Nightly Build で見れる。
比較できるのは Windows で普通に見れるファイルだけね。

やっぱり昨日見たおっぱいと今日見たおっぱいが同じものか分かるようじゃないと嫌だな

エロ画像なんて一期一会なわけですよ
エロ動画なんてＤＬすることに意義があるわけですよ

あー確かに。画像の移動や回転、拡大縮小はだめだな。
そもそも、それを比較できるツールなんて存在するのか？
画像の特徴を調べて基準点を算出し、それらの位置の変化を読み取って
元の画像からどのように変更されたかを計算で求めるんだろ。

あ゛ー、俺の頭じゃ無理だわ。
つーかこれ作ったら、かなりの値段で売れるんじゃね？

二次元の静止画像ごときでなぜそんなに必死なんだか。

動画じゃないとつまらんだろ。

いつも同じ向き、いつも同じ髪型、いつも同じポーズ、
いつも同じ恰好の女なんてつまらんだろ。

>>894
その程度なら画像工学の分野で研究が進んでいる。
なにせ、犯罪捜査に使われているくらいだからな。

>896
でも、捜査の決め手はいつも密室の取調室での自白だったりする罠。

自白は重要証拠にはならないよ。
自白どおりのモノが見つかったらそれが証拠になるだけで。

>>898
モノが見つかってから無理矢理自白させて終わり、なんてこともあったなあ。

>>899
モノが見つかってその事実を明かさずにモノのあった場所を吐かせたらそれはかなり黒だろ
どこどこにあるのか？Yes/Noだと意味無いが

今、青果物を日付ﾌｫﾙﾀﾞ毎に格納するというダサいルールの下で作業している訳だが。
すげーｽﾄﾚｽ。
バージョン管理ツールがこれほど恋しいとは思わなかった。

あおくだもの

それにしてもこの手のツールを頑なに拒絶する人がいるのはなんでだろ？
便利なのに・・・

>>903
なんでもできるようにしてあるぶん肝心なことをやるのが面倒臭いってのが大きいな。
例えば>>901の例だと昨日の青果物をその前の日の青果物を比べてみたいわけだけど
バージョン管理だと昨日とかその前の日の状態のものを見るのって上げる奴と
見る奴と双方がバージョン管理ツールを使い慣れてないと結構面倒じゃね？

まあ、できないわけじゃないのはわかるけど、ちょっと面倒でしょ？
ソースやクラスの構造を変えてる場合とか具体的にどこがどう変わったのかわかりずらいよね？
データとかを格納する位置とかそのとき使ってたlibやdllのバージョンとかもみなきゃいけないしね。
フォルダに丸々入れてもらったほうが全体的にどうかわったのか見やすい。
必要なものが必要なだけ固まってるってところがいいっしょ。

まあ、俺はバージョン管理にも入れておいてもらってフォルダでもまとめてもらってるけど、
自分でやるの面倒だから。

シナショウ青果

せいか　―くわ 1 【青果】
野菜と果物の総称。

性化物

>>904
君が知らないなら爆笑だが、知っているなら教えてしまえよ、こんなもんVSSだろうがCVSだろうがSubversionだろうが半日あれば余裕で仕込めるだろ。

>>904
>ソースやクラスの構造を変えてる場合とか具体的にどこがどう変わったのかわかりずらいよね？
>データとかを格納する位置とかそのとき使ってたlibやdllのバージョンとかもみなきゃいけないしね。
>フォルダに丸々入れてもらったほうが全体的にどうかわったのか見やすい。

フォルダに丸々入ってるほうが差分が見づらいと思うんだが？
もし差分比較ツール使ってるんならバージョン管理ツール使うのと大差ないし。

そもそもバージョン管理ツールだとその都度任意の時点でのを取り出せるんだから、
いちいち全部丸々とっておかなくてもいいってのはわかってんのかな。
もしフォルダでまとめておくとしても cron で回しておけば自動化できるし。

>>909
>そもそもバージョン管理ツールだとその都度任意の時点でのを取り出せるんだから
これって、そう簡単でもないじゃん。
手間もかかるし。

毎日フォルダーに入れてるくらいなら、毎日タグ打ちすれば？
全然手間じゃないよ
タグの命名ルールだけはちゃんと決めとけばOK
たとえばB-20060810-01とかね

>>911
>毎日タグ打ちすれば？
だれがやんの？じゃあ、５人分よろしく

タグ5人分ですってよ、奥さん　ｷｲﾀ?( ﾟдﾟ)ｵｸｻﾝ(ﾟдﾟ )ｱﾗﾔﾀﾞﾜｧ

>>912
5人分って何？
構成全体に対して1回やるだけだぜw

>>914
５人の作業を見る必要があって、１人１人の状態をとっておきたいんだけど？
構成全体じゃなくて１人分の差分が必要なんだけど。
で、他の人間の更新状態をこっち側で管理できるなにかがあるの？
それともやっぱり１人１人に指示出さなきゃ駄目なの？

>>915
５人分フォルダーで管理してんの？
共有コードはどうしてんの？
ちなみに全く分かれているならタグ打ちすら不要だけど？

>>916
いや、５人分わかれてるわけじゃない。
ソースはそれぞれ散りばめられてる。
その中から５人それぞれの更新状態が知りたい。

他は知らねーけどCVSはコマンド一発でユーザが特定の日に更新したソースの履歴はとれるよ
マニュアル見ねーとここじゃ書けねーけど

流石はコンマ区切り、こんなことも出来るんだぁ〜φ(・_・｡ ) ﾒﾓﾒﾓ

>919
CSV

CSV CVS SCV SVC VCS VSC

V\V　ﾌｫﾌｫﾌｫ

各個の作業実績をコード量で把握してるのか？
それ自体が激しく無駄な行為だろ

>912=915=917
そういう状況で現在フォルダで管理されている５人の更新状況を
お前が的確に把握できているのか激しく疑問。

バージョン管理ツールの必要性を論破しようとして
無理やりありもしない状況をでっち上げてるだろ？

それかぜんぜん管理できてないのに管理できてる気になってるだろ？

俺は障害票の消しこみしてる時は日付ごとの受け入れフォルダ作るけどな
やっちゃいけないの判ってるが多重分岐をリポジトリに放り込むと直に破綻する

>>925
多重分岐の意味するところが正確にはわからないが、それはバージョン管理ツールの問題では
ないだろう？ バージョン管理ツール使ってなくたって破綻する。むしろより早く。

この前バージョン管理ツールを使っているやつの
プログラムを見たんだけど、バグばっかりで
まともに動かなかったよ。
これだからバージョン管理ツールはダメなんだ。

こ
プ
ま
こ

　　　バ
　　グ
　と
　れ

駄目なのはお前の頭だよ

>930

　　　　　,-'"ヽ　　　　
　　　　　　/　　　i､　 　 　　　／￣￣　ヽ, 　　　　　＿/＼／＼/＼／|＿ 　
　　　　　　{ ﾉ　　　"' ゝ 　　 /　　　　　 　 ', 　　　　＼　　　　　　　　　　／
　　　　　 ／　　 　 　　"' ゝﾉ　{0}　 /¨`ヽ{0}　　　　 ＜　 ガーン！！　＞
　　　 　 /　　　　　　　　　　　　　　ヽ._.ノ　　', 　　　／　 　　　　　　　　＼ 　　　　　　
　　　 　i 　　　　　　　 　　　　　 　｀ー'′　 '.　　　　￣|／＼/＼/＼/￣　　　　　　　
　　　　/ 　　　　　　　 　 　 　　　　　　　　 　}. 　　　　　　　　　
　　　 i'　　　 /､　 　　　　　　 　　　 　　　　,i..　　　　　　　　　　
　　　 い _／　 `-､.,,　　　　　､_　　　　　　　i　　　　　　　　　　
　　 /'　/ 　 　 _/　 ＼`i　　　"　　　/ﾞ　　 ./　　　　　　　　　　
　 (,,／ 　 　 , '　 _,,-'"　i　 ヾi__,,,...--t'"　 ,|　　　　　　　　　　　
　　　　　　 ,/　／　 　 　＼　 ヽ､　　　i　　|　　　　　　　　　　　
　　　　　　 (､,,/　　　　　　 〉､ ､,}　　　 |　 .i　　　　　　　　　　
　　　　　　　　　　　　　 　 `` `　　　　　! ､､＼　　　　　　　　　　
　　　　　　　　　　　　　　 　　　　　　　　!､_n_,〉>

　　　　　　　　　　　　　　ツ
　　　　　　　　　　　ん　　　　　　　　　　　　　で

　れ

やぁ、程度の低い香具師が悦び勇んでカキコしてるところはここでつか？

バージョン管理ツールすら使いこなせないなんて．．．プププ(w

ファイル共有原理主義者みたいなのは永久に絶滅しない

で、バージョン管理ツールの導入を促すと、
しつこいくらいに排他制御のこととか、共有ロックとかについて
説明を求められるんだよな。
他所様でもコレ使って上手く行ってるんだから使おうぜ、って思うんだが。

バージョン管理ツールを普及するためには、
イタリア人の場合、さっき美女がCVS使ってますた。
ドイツ人の場合、CVSを使うのが決まりになっています。
アメリカ人の場合、ここでCVSを使えばヒーローになれますよ。
日本人の場合、隣の会社もCVS使ってますよ。

>>935
前にも書いたけど、このツールって機能を限定してない分、
使いたい機能を使うのがすごく面倒なんだよ。

>>901
ならば、今すぐ導入すればいいじゃん。

会社でやってなくても自分のマシンにリポジトリ
作って自分だけでやればいい

>>903
ただの食わず嫌いな連中だよ。
新しいものに対する抵抗。

つまり、連中は変化を恐れている共産主義者どもだからだよ。

>>904
> >>903
> バージョン管理だと昨日とかその前の日の状態のものを見るのって上げる奴と
> 見る奴と双方がバージョン管理ツールを使い慣れてないと結構面倒じゃね？

んなもん、みんな有名なバージョン管理システムにすでに同梱されているよ。

>912=915=917みたいな痛い奴久しぶりに見たよ。

>>935
フランス人の場合､CVSなんて誰も使ってませんよ。
ブラジル人の場合､CVSを使うとサッカーがうまくなりますよ｡
中国人の場合､CVSは食べることができますよ。
韓国人の場合､CVSは韓国が起源ですよ。

とでも言えばいいのか？

>>941のセンスの無さに感動した

>>904=910=936(=912=915=917)みたいなのが
使いこなせない香具師
っていうんだよな

もしかして、気付いてない？(プゲラッチョ