アカウント名:
パスワード:
反応が薄いですねえ。
Disるわけじゃなく、純粋に質問したいのですが、GitがSubversionより良いところってどんなものなのでしょう。 私は小規模なプロジェクトにしか関わっていないせいか、類似ソフトにしか見えないのです。
私は逆にGitのよいところが知りたいです。
非常に小規模なプロジェクトなため、分散管理にメリットは感じられません。 対象OSが、Windows なため、環境を整えるのも結構手間取りました。 日本語の扱いも多少難がありますし。
対象OSが、Linux だったり、大人数が係わるプロジェクトだとGitの方がいいのかな、と思いましたが。 今のところ、TortoiseSVN + SVK に落ち着いています。
とりあえず家マシンはバージョンアップしました。 会社のは夏休み後に(忘れないようにしないと)
#何でLinus は subversion を、あんなに攻撃するんでしょうか?
> + SVK
SVKのリポジトリを自分のPCローカルじゃなく複数のPC(のユーザ)から共同で使えるようにする方法って、あったっけ?あるなら是非ご伝授を。
#SVKリポジトリをSVN鯖に食わせちゃえば動くっちゃー動くんだが、なんか怖い。
なんでそんなことしたいかというと、上流(ぶっちゃけ仕事だ)がSVNリポジトリ握ってて、そいつらがアホ運用をするもんだから、(たとえば「レビューが終わるまでCOMMITするな」とか。なんのためのVer管理なのか理解してないたぐい※)こっちはこっちの自衛のために内輪のみんなが使うリポジトリを建てつつ、それを上流と自動連動できるようにSVKにしておきたい、と。
この話題の元ACです。
上流は何を考えているのやら、と思います。たぶん、「管理」という概念を何か勘違いしている人間が上流で「管理」権限を握ってる、といったことなのでしょう。
>何のVer管理のメリットがあるのか聞きたいですね>そのVerへ戻せる環境を作る為のはずです。
ほかのひとも言っていますが、どの段階をCommitしようが「戻せる」わけですし、交通整理をしたいならCommitするかどうかじゃなく、Truncや(運用で決めたしかるべき)BranchにいつCommitするか、で整理するほうが上策です。
>小規模なプロジェクトならしょうがない
いえ。「大規模」なプロジェクト(をおこなうような大規模な会社)ほど、上流の馬鹿が偉そうに踏ん反りかえっててなかなか改心してくれなくて、この状況になります。
この点から想像するに、大規模プロジェクトほど、比例的じゃなく累進的にデスマに陥り易いと言えると思います。
>Ver管理 = バックアップと思ってる人が多すぎる。
(私は)それでも構わないと思っています。ただ、(私は)その「バックアップ」の捉え方のほうが違います。
つまりですね、一回セーブするごととか、UT通すごととか、関数1つできるごととか、5分ごととか、に「バックアップ」をしたくなるんです。一日なんて悠長な粒度ではなく。
(一日粒度のバックアップなんてのは、そうしないとならないような別の残念な理由がある場合に妥協案として使うくらいなものです)
もちろん「できる」の定義も更に細かくすることが出来る(UT通った後だけじゃなく、とりあえず書いた後や、とりあえずシグネチャ作っただけの状態も、「できる」に含める)ので、Commitしたくなる頻度は益々増えます。減りません。
ただ、こういう考え方の人は少数派であり、Commitは面倒だ、Commit頻度をいかに少なくするかが生産性の鍵である、と思い込んでる人のほうが多かったりします。困ったもんだ。
>ブランチ作って勝手に
馬鹿管理においてはブランチも「勝手に」作らせてくれませんし、ブランチだろうがなんだろうがCommitを自由にやらせてもらえません。
ブランチやタグといった概念の活用の仕方を全くわかってないわ、使い方も全く勉強してないわ、で、何のためのSVNなのやら…と。
#単に無料のVSSだと思ってるんじゃなかろか?
そういえば、トランクとブランチの使い分け方も、間違ってるというか「逆」に覚えている人がしばしば居ました。危ない危ない。
バージョン管理文化圏(たとえばオプソ関係とか)に住んだことが無い人だと、いきなりSVN使う話になっても、どう使うのが「当然」なのか、どう使うのが「おいしい」のか、が全く知らない状態で自分流に妄想することになってしまいます。
どんな馬鹿運用でも、一旦決めて走り始めてしまうと、後から変えるのは困難だというだけの理由で変えられなくなることがしばしばあります。「啓蒙」はとても大事だと思います。(啓蒙なんてあまり良くない言葉だとも思いますが、ほかに言いえて妙な言葉がなかなか思いつかない)
Linuxを「布教」「啓蒙」する活動をしてるコミュニティがしばしば有りますが、同じ調子でオプソの(優秀な)バージョン管理ツールとかについて「布教」「啓蒙」してくれるコミュニティが居たりすると、うれしいなあと思ったりします。SVN鯖のインストール大会をやるとかさあ。
>問題発生した時どこまでどうやって戻せばいいの?>ある修正を行うことに対するリビジョンはできる限り少なくするのが当たり前と思ってます。
いや、だから、それは「バージョン」(リビジョン)管理じゃなく「タグ」管理によって実現してください。戻す単位はタグで管理してください。修正の「単位」もタグで単位付けをしてください。
そして両方を同じツールで地続きに管理するほうが、二重管理にならなくて扱い易いってことです。
>プログラマの生産性とか(中略)では無くて
(バージョン管理が)生産性に寄与しないんだったら、邪魔とまでいわないけど控えめに言っても「無駄」なツールだ、と
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
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: (スコア:0)
Subversionの管理者やってますが、逆にレビューが終わってないのをCommitするのに
何のVer管理のメリットがあるのか聞きたいですね
Ver管理を行っているのは、不具合、その他が起こった場合にどこでバグが発生したのかのチェックと
そのVerへ戻せる環境を作る為のはずです。
まぁ、小規模なプロジェクトならしょうがないですが・・
Ver管理 = バックアップと思ってる人が多すぎる。
1日の作業が終わったらCommitとかどうやって履歴を管理しろと言うのか
バックアップに使うのなら個人の環境で取るかブランチ作って勝手にやってくれ
Re:Subversionは人気がないのですかね? (スコア:0)
この話題の元ACです。
上流は何を考えているのやら、と思います。
たぶん、
「管理」という概念を何か勘違いしている人間が上流で「管理」権限を握ってる、
といったことなのでしょう。
>何のVer管理のメリットがあるのか聞きたいですね
>そのVerへ戻せる環境を作る為のはずです。
ほかのひとも言っていますが、どの段階をCommitしようが「戻せる」わけですし、
交通整理をしたいならCommitするかどうかじゃなく、
Truncや(運用で決めたしかるべき)BranchにいつCommitするか、で整理するほうが上策です。
>小規模なプロジェクトならしょうがない
いえ。「大規模」なプロジェクト(をおこなうような大規模な会社)ほど、上流の馬鹿が偉そうに踏ん反りかえっててなかなか改心してくれなくて、この状況になります。
この点から想像するに、大規模プロジェクトほど、比例的じゃなく累進的にデスマに陥り易いと言えると思います。
>Ver管理 = バックアップと思ってる人が多すぎる。
(私は)それでも構わないと思っています。
ただ、(私は)その「バックアップ」の捉え方のほうが違います。
つまりですね、一回セーブするごととか、UT通すごととか、関数1つできるごととか、5分ごととか、に「バックアップ」をしたくなるんです。一日なんて悠長な粒度ではなく。
(一日粒度のバックアップなんてのは、そうしないとならないような別の残念な理由がある場合に妥協案として使うくらいなものです)
もちろん「できる」の定義も更に細かくすることが出来る(UT通った後だけじゃなく、とりあえず書いた後や、とりあえずシグネチャ作っただけの状態も、「できる」に含める)ので、Commitしたくなる頻度は益々増えます。減りません。
ただ、こういう考え方の人は少数派であり、
Commitは面倒だ、Commit頻度をいかに少なくするかが生産性の鍵である、
と思い込んでる人のほうが多かったりします。
困ったもんだ。
>ブランチ作って勝手に
馬鹿管理においてはブランチも「勝手に」作らせてくれませんし、ブランチだろうがなんだろうがCommitを自由にやらせてもらえません。
ブランチやタグといった概念の活用の仕方を全くわかってないわ、
使い方も全く勉強してないわ、で、
何のためのSVNなのやら…と。
#単に無料のVSSだと思ってるんじゃなかろか?
そういえば、トランクとブランチの使い分け方も、間違ってるというか「逆」に覚えている人がしばしば居ました。危ない危ない。
バージョン管理文化圏(たとえばオプソ関係とか)に住んだことが無い人だと、いきなりSVN使う話になっても、どう使うのが「当然」なのか、どう使うのが「おいしい」のか、が全く知らない状態で自分流に妄想することになってしまいます。
どんな馬鹿運用でも、一旦決めて走り始めてしまうと、後から変えるのは困難だというだけの理由で変えられなくなることがしばしばあります。「啓蒙」はとても大事だと思います。(啓蒙なんてあまり良くない言葉だとも思いますが、ほかに言いえて妙な言葉がなかなか思いつかない)
Linuxを「布教」「啓蒙」する活動をしてるコミュニティがしばしば有りますが、同じ調子でオプソの(優秀な)バージョン管理ツールとかについて「布教」「啓蒙」してくれるコミュニティが居たりすると、うれしいなあと思ったりします。SVN鯖のインストール大会をやるとかさあ。
Re: (スコア:0)
> Commitは面倒だ、Commit頻度をいかに少なくするかが生産性の鍵である、
> と思い込んでる人のほうが多かったりします。
> 困ったもんだ。
こういう結構やってる人のコメントを見ると
やはりバージョン管理行う目的に非常に差異を感じます。
> Commitは面倒だ、Commit頻度をいかに少なくするかが生産性の鍵である、
たぶん、管理者はこんな事考えてなくて、勝手にバンバン増やされたリビジョンで
問題発生した時どこまでどうやって戻せばいいの?
っていうだけだと思います。作った人ならそりゃわかるでしょうが・・
Re: (スコア:0)
>問題発生した時どこまでどうやって戻せばいいの?
>ある修正を行うことに対するリビジョンはできる限り少なくするのが当たり前と思ってます。
いや、だから、
それは「バージョン」(リビジョン)管理じゃなく「タグ」管理によって実現してください。
戻す単位はタグで管理してください。
修正の「単位」もタグで単位付けをしてください。
そして両方を同じツールで地続きに管理するほうが、二重管理にならなくて扱い易いってことです。
>プログラマの生産性とか(中略)では無くて
(バージョン管理が)生産性に寄与しないんだったら、
邪魔とまでいわないけど控えめに言っても「無駄」なツールだ、と
Re: (スコア:0)
Re: (スコア:0)
ただ、Git、Mercurialなどの分散管理システムと違って
説明されている「タグ」ってSVNで言うTagの事ですよね?
タグ付けって単なるリビジョンのその時点でのスナップショットでしかないので
修正単位でタグ付けするためには、Commit順序を厳密に管理してないと
好ましいもののみ集まった「タグ」にはならないですよね?
普段、ブランチでリビジョン上げておいて集まったリビジョンをTrunkへマージして
タグを作るっていうんならわかりますが、そのリビジョンを集めるのも
好き勝手にリビジョン上げられているとどうやって把握してマージするのでしょう?
チケットに紐づいてるのは全部マージだろって話でしょうが、
管理者にとってはもの凄い負担です。
そういった使い方だと、やはりブランチで勝手にやっててもらって修正が終わったら
まとめてトランクにマージしてね。っていうぐらいしかまともに管理できる方法は思いつかないですね
Re: (スコア:0)
プログラマとして履歴を取りたい物と、プロジェクトとして履歴を取りたい
物が一致してないのが問題だとは思います。
本来であればGitなどの分散管理システム使えばうまくいきそうなのはわかってるのですが
Windows環境、日本語問題など通常の開発現場に持ち込むのはどうにも躊躇しています
こういうソース管理ってかなり大切な部分だと思うのですが
日本の開発現場だとほんとおざなりだと思います。
こういう議論できる場も人もほとんどなくて開発に流される事が多いので
今の議論も結構楽しかったりします
Re: (スコア:0)
リポジトリの粒度を考えるのが面倒というなら、確かに分散系のが向いてる。
ただ根本問題として、修正単位一つ一つに対して、戻せるようにしたいという要求がちょっとズレているというか、マイクロマネージメントの傾向が高すぎるんじゃないかな。
開発中盤でそんな事はしないだろうから、おそらくリリース直前の状況と思うけど、それはバージョン管理ではなくリリースエンジニアリング技術の問題になるのだと思うよ。
つまりリポジトリ管理者であるあなたの権限の外側に問題がある = 全体のマネージメントがおかしいので、プロマネにクレームを挙げるべきかと。