アカウント名:
パスワード:
反応が薄いですねえ。
Disるわけじゃなく、純粋に質問したいのですが、GitがSubversionより良いところってどんなものなのでしょう。 私は小規模なプロジェクトにしか関わっていないせいか、類似ソフトにしか見えないのです。
私は逆にGitのよいところが知りたいです。
非常に小規模なプロジェクトなため、分散管理にメリットは感じられません。 対象OSが、Windows なため、環境を整えるのも結構手間取りました。 日本語の扱いも多少難がありますし。
対象OSが、Linux だったり、大人数が係わるプロジェクトだとGitの方がいいのかな、と思いましたが。 今のところ、TortoiseSVN + SVK に落ち着いています。
とりあえず家マシンはバージョンアップしました。 会社のは夏休み後に（忘れないようにしないと）
＃何でLinus は subversion を、あんなに攻撃するんでしょうか？
> + SVK
SVKのリポジトリを自分のPCローカルじゃなく複数のPC(のユーザ)から共同で使えるようにする方法って、あったっけ？あるなら是非ご伝授を。
＃SVKリポジトリをSVN鯖に食わせちゃえば動くっちゃー動くんだが、なんか怖い。
なんでそんなことしたいかというと、上流(ぶっちゃけ仕事だ)がSVNリポジトリ握ってて、そいつらがアホ運用をするもんだから、(たとえば「レビューが終わるまでCOMMITするな」とか。なんのためのVer管理なのか理解してないたぐい※)こっちはこっちの自衛のために内輪のみんなが使うリポジトリを建てつつ、それを上流と自動連動できるようにSVKにしておきたい、と。
>動かんソフトにバージョン付加してもしょうがないよね
違います。その言い方に合わせて説明するならば、(動く)ソフトに付加すべきは、バージョンではなく「タグ」です。
つまりSVN(CVSもだが)のバージョン管理は、少なくとも「二段構え」になってる、と捉えるべきなのです。まずバージョン(リビジョン)がある。その上位にタグがある。
だいたい「動く」かどうかなんてのは、主観が絡んだり、相対的なもの(UTではOKだが結合すると没だったり)なので、それを基準にCommitじたいを受け付けるか否か決めるなんてのは無理です。まずセーフネットとしてとりあえず全部Comm
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
Subversionは人気がないのですかね？ (スコア:1)
反応が薄いですねえ。
Disるわけじゃなく、純粋に質問したいのですが、GitがSubversionより良いところってどんなものなのでしょう。
私は小規模なプロジェクトにしか関わっていないせいか、類似ソフトにしか見えないのです。
Re: (スコア:0)
私は逆にGitのよいところが知りたいです。
非常に小規模なプロジェクトなため、分散管理にメリットは感じられません。
対象OSが、Windows なため、環境を整えるのも結構手間取りました。
日本語の扱いも多少難がありますし。
対象OSが、Linux だったり、大人数が係わるプロジェクトだとGitの方がいいのかな、と思いましたが。
今のところ、TortoiseSVN + SVK に落ち着いています。
とりあえず家マシンはバージョンアップしました。
会社のは夏休み後に（忘れないようにしないと）
＃何でLinus は subversion を、あんなに攻撃するんでしょうか？
Re: (スコア:0)
> + SVK
SVKのリポジトリを自分のPCローカルじゃなく
複数のPC(のユーザ)から共同で使えるようにする方法って、
あったっけ？あるなら是非ご伝授を。
＃SVKリポジトリをSVN鯖に食わせちゃえば動くっちゃー動くんだが、なんか怖い。
なんでそんなことしたいかというと、
上流(ぶっちゃけ仕事だ)がSVNリポジトリ握ってて、
そいつらがアホ運用をするもんだから、
(たとえば「レビューが終わるまでCOMMITするな」とか。なんのためのVer管理なのか理解してないたぐい※)
こっちはこっちの自衛のために内輪のみんなが使うリポジトリを建てつつ、
それを上流と自動連動できるようにSVKにしておきたい、と。
Re:Subversionは人気がないのですかね？ (スコア:0)
某社に出向してた時の事。
当時（もう5年位前ですかね…）その出向先のプロジェクトはCVSサーバでバージョン管理をしてた。
そこでのルールは、レビュー後コミットみたいなものは無かった。
が、何処の誰か知らないけれど（プロジェクト全体は、当方は全く把握しておらず、
プロパーのPLクラスの人と直接コミュニケーションをとりながら作業を進めていた）
ろくに動作確認もせずコードをアップする馬鹿が居た。
当方窓口のPLからは動作確認を強要され（ま、常識なんですが…）、コミット直前にアップデートして
動作確認をしようとするのだが、アップデートしたら最後、下手したらコンパイルも通らなかったりして、
それでもコミットしてから帰宅する様に言われる。
しかも動作不全の原因となるコードをコミットしたやつは既に退社してたりして、
こっちは何時帰ったらええねん、一体どうすりゃええんじゃ！
毎日コミットが終了するのが夜中の2時〜3時頃に。
う〜ん、デスマ臭濃厚な…
最終的には、自社の営業にもう契約延長せんでくれ、と泣きつき、
いやほとんど脅しを入れてやっと解放してもらったが、
もう2、3ヶ月続いていたら会社辞めてただろうな。
プロジェクトメンバのモラルが高ければ、コミットに対するルールは不要かもしれんが、
レビューまで必要かどうかは別にして、有る程度のルールは必要だと思うよ。
別コメさんにも有りますが、バージョン管理ソフトはバックアップソフトとは違うんだし、
バグが有るだけならまだしも、動かんソフトにバージョン付加してもしょうがないよね。
Re: (スコア:0)
>動かんソフトにバージョン付加してもしょうがないよね
違います。その言い方に合わせて説明するならば、(動く)ソフトに付加すべきは、バージョンではなく「タグ」です。
つまりSVN(CVSもだが)のバージョン管理は、少なくとも「二段構え」になってる、と捉えるべきなのです。
まずバージョン(リビジョン)がある。
その上位にタグがある。
だいたい「動く」かどうかなんてのは、主観が絡んだり、相対的なもの(UTではOKだが結合すると没だったり)なので、それを基準にCommitじたいを受け付けるか否か決めるなんてのは無理です。まずセーフネットとしてとりあえず全部Comm
Re: (スコア:0)
Re: (スコア:0)
問題は、Commitされたバージョンが正しく動くバージョンかどうか
どうやって判断するのか？じゃないのか
そのための知恵として trunk と branche 、unittest なんかがあるわけで
ソース管理って本気でやろうとするとどうやっても難しいよ
使い方を制限するか、すべて分かってるメンバー揃えるしか無い