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

>>949
理解されようとしてるの？

>>951
そんな問題があっても、バージョン管理ツールを使うか使わないかについては
悪く見ても「使う」≧「使わない」だろ。拒絶する理由としては無理がある。

>>953
そんなところで思考停止してるからいつまで経っても
万人が使えるツールにまで昇華しない。

>>953
まあそれには同意
コンフリクトだけでも自動検出できるってのは
バージョン管理ツールの大きなアドバンテージ
ただのフォルダー管理では上書きで潰してしまうからな

それはそれとしてそろそろ運用についても話し合ってみないか

>>954
Subversion や TortoiseSVN の開発が停止しているとでも思ってるの？
だいたい（以下 >>953 と同文）

>>956
いや、だから何もわかってないな。
機能があるかどうかの問題じゃないんだよ。

>>955
運用については各ツールの専用スレでいいだろ。このスレももう終わりだしな。

CVS導入スレ〜 Rev.3
http://pc8.2ch.net/test/read.cgi/tech/1113141518/

Subversion r5
http://pc8.2ch.net/test/read.cgi/tech/1145841405/

つか、いまのままのバージョン管理ツールなら使いにくいしいらないよ。

>>957
システムの話なら Subversion, GNU arch, bitkeeper の比較とか。そこらへんの話を追え。
それ見て思考停止してると思うんなら、開発 ML に投稿でもしろ。
もしくは自分でシステムの草案でも挙げろ。それにしても（以下 >>953 と同文）

>>960は単なるSubversion厨だったか
時間の無駄だったな

>>951
> チェックインする前にアップデートしてコンフリクトを解消してから
> チェックインするようにした

これって当然のことじゃねーの？

> チェックインに関しては基本一日一回
って制限する必要ないんじゃね？

あと、なるべくコンフリクトしないような開発体制を敷くべき
同一コードを複数人で捏ね繰り回す愚は犯すべきでない

>>962
君にとっての当然は住人にとっての当然とは限らない
まずは意見を出し合ってみなければね

コンフリクトしない開発体制についてkwsk

>963
> 君にとっての当然は住人にとっての当然とは限らない
えぇっ、マヂでそれ言ってる？
．．．ってゆーか、あなた「マ」ではないでしょ？

> コンフリクトしない開発体制についてkwsk
きちんと分業すればいい、って話しでしょ
で、他人の担当箇所で追加/修正が必要な場合はそいつに依頼する、と

．．．う〜ん、なんか、単なる論客と話してる気がしてきた(汗

>>964
てか、お前の脳内の常識は俺にもわからんし、
現に開発の中でチェックインは毎日するべきかしないべきかで揉めたこともあるし、
自分の常識が一般の常識とは思わないほうがいい。

>>965
チェックイン前のアップデートなんてちょっと説明すれば必要性が納得できるだろ。
それが納得できないやつは共同作業自体を否定していることになる。

「チェックインは毎日するべきか」という問題には根拠がないから揉めるのも当たり前。
同じに考えるのはおかしい。

>>964
もちろんまじでいってる
いろんなレベルの香具師がいるわけだから提示することに意味がある

ではお互いに担当を知ってないといけないということかい
依頼するにしても手順があるだろう
そこで実質作業が停止してしまうわけだしな
その辺りの具体的な手法はどうしてる？

ちなみに「マ」じゃないといわれたのははじめてだよ

おめでとう
ついでだしオレからも言ってあげようか？

>>967
バージョン管理ツールがコミュニケーションまで自動化してくれないと使いたくないってことか。
無理っぽいなぁ。

>>951
バージョン管理システムをつかうとかえってバグを埋め込みやすいから
使わない方がいいと主張しているのか？
それもどうかね。バグが埋め込まれやすいかどうかはバージョン管理システムを
使うか使わないかの可否には全く関係ない。

チェックインというより、CVSやSubversionの用語にあわせてここでは「コミット」と
言わせて貰うが。

まさかコンパイルが通らないコードをコミットしているわけではあるまい。
XUnitなどのツールでテストが通ったものだけコミットすればなおよい。


剥離、コンフリクト問題を気にしているようだが、
ブランチを知っているか？

行の衝突もマージ機能がある。二つのソースコードを並べて比較するツールもある。


ようは、コミットはこまめにしておけ。ということだ。
最低でも一日に10回はやってるだろう。
XPのプラクティス、ペアプログラミングという概念に倣うならこまめなコミットは当たり前。

>>968
うむ、おれもとてもおまいがプログラマだとは思えない。

>>971
そんなのてめぇの勝手な使い方じゃねぇかよ。
実際はコンパイル通るソースだろうが、通らないソースだろうが、
バージョン管理ツールは通しちまうだろうがよ。

一日中チェックアウトしっぱなしの馬鹿はマに向いていない。
チェックアウトしたまま帰る馬鹿は共同作業に向いていない。

>>974
それができてしまうバージョン管理ツールってどうなの？

>>973
致命的なバグくらいはチェックインする前に単体テストで見つけろよ。
それが出来ないなら一人で出来るプロジェクトだけやってたほうがいいよ。
他人に迷惑掛けずに済むよ。

>>975
そんな常識も徹底できない職場ってどうなの？
猿しかいないの？

じゃあ、将来的にはバージョン管理ツールはチェックインする前に
それがソースコードならコンパイルを通ったものでないならエラーを出してチェックインできないように
なるのが正しい方向だと言ってる？

チェックアウトしたままの馬鹿なんて、管理者権限で取り消すだけだろ？
そいつの作業はコミットしてないんだから、別に問題なし。

一番の問題はコンパイル通らないものをコミットして帰るレベルだと思うが。

>>973,975
そうできないような仕組みを実現する手段はある。
コミット前フックでビルド〜テストケース全パスを条件にするとかね。
現実的ではないから誰もやらないだけ。だれも考えていないわけではない。

現実的なコストで実現可能だというのなら、そういうシステムを提言すればいい。
それができないなら現場の判断に従いやがれ。

>>980
現状できないことをさもできるように言うなよ。
そんなこと言ったら、コンパイラが入ってるマシンはなんでもできるって言えるじゃん。

それに修正途中のソースをコミットできないなんて使いにくいだろ。
設定でできるようにしたら今度は人によって設定がバラバラになるわけだから無意味だしね。

>>982
修正途中のソースをコミット？その考えが矛盾してる。
ファイルのセーブじゃないんだから。
セーブだけなら別にコミットは不要だろ？ローカルPCのHDDには存在するんだから。

なんか、バージョン管理ツールの使い方を(ワザと？)履き違えてる香具師がいるみたいね

運用については
- コミット逃げ厳禁
- コンパイルエラー等の明白なエラーが存在するコードのコミット禁止
- コミット前に必ず最新コードとのコンフリクトを解消
ってのが最低限のマナー(常識と言ってよい)かな

>>984
だから、それを強制できるか否かの議論じゃないのか？

>>981
できるのが理想だというのに、できると言うと否定するのは、何かおかしくないか？

C が嫌いなアセンブラ使い。
C++ が嫌いな C 使い。
似たような人はどこにでも沸くねぇ。

なんつうか、結果が大事じゃなく、自分で作った感、やった感が大事な人っているよね。
言葉を選べば職人肌、普通に言えばおなにい。

いきなり話の腰を折るねぇ(w

>>984は正論だな。
バージョン管理ツールはお前の日記帳入れるための机の引き出し
じゃないと言う事

日曜だというのに自演乙
このまま1000まで逝っちまいな

>>1は真性Java厨ですからw

でも実際バージョン管理使ってても
バグ修正した個所を残してたり
ここ修正とかをコードに書きまくってる現状は…

コードにわざと残す場合はある。
ここをこうやって間違ったら駄目だよとか、ここをこう変えたというのを明示したい場合。
同じミスというか、類似ミスをなくすためにわざとコメントで残す。

それが大量にあるのもいいのか…

うちの上司に言わせれば、どんなに便利なﾂｰﾙも、その必要性や使い方の理解が出来ないやつらが大半で、
その教育のためのｺｽﾄを払うことができないから、ﾂｰﾙ使用禁止だそうだ。

>>996
じゃあPC使うのやめちゃえよ。

PCはともかく、コンパイラはおろかIDEも禁止だな。

いや実際、とあるプロジェクトでおいらが開発環境作ることになって、
CVS+eclipsな環境と使い方のマニュアル用意したんだが、
上司をはじめとした全メンバーの拒絶にあったのさ。
でも鯖上のマスターソースを上書きデグレ(もちろん復帰できない)するのは当然だし、コンパイル通らないソースばっか。

幸い漏れはｽﾎﾟｯﾄのヘルプだったからとっととにげたけどな。

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。