「Subversion 1.5.6以前と1.6.0～1.6.3に脆弱性が発見される」記事へのコメント

Subversionは人気がないのですかね？

[leftwing (37789)]

反応が薄いですねえ。

Disるわけじゃなく、純粋に質問したいのですが、GitがSubversionより良いところってどんなものなのでしょう。
私は小規模なプロジェクトにしか関わっていないせいか、類似ソフトにしか見えないのです。

Re:

[Anonymous Coward]

　私は逆にGitのよいところが知りたいです。

　非常に小規模なプロジェクトなため、分散管理にメリットは感じられません。
　対象OSが、Windows なため、環境を整えるのも結構手間取りました。
　日本語の扱いも多少難がありますし。

　対象OSが、Linux だったり、大人数が係わるプロジェクトだとGitの方がいいのかな、と思いましたが。
　今のところ、TortoiseSVN + SVK に落ち着いています。

　とりあえず家マシンはバージョンアップしました。
　会社のは夏休み後に（忘れないようにしないと）

＃何でLinus は subversion を、あんなに攻撃するんでしょうか？

Re:Subversionは人気がないのですかね？

[Anonymous Coward]

> + SVK

SVKのリポジトリを自分のPCローカルじゃなく
複数のPC(のユーザ)から共同で使えるようにする方法って、
あったっけ？あるなら是非ご伝授を。

＃SVKリポジトリをSVN鯖に食わせちゃえば動くっちゃー動くんだが、なんか怖い。

なんでそんなことしたいかというと、
上流(ぶっちゃけ仕事だ)がSVNリポジトリ握ってて、
そいつらがアホ運用をするもんだから、
(たとえば「レビューが終わるまでCOMMITするな」とか。なんのためのVer管理なのか理解してないたぐい※)
こっちはこっちの自衛のために内輪のみんなが使うリポジトリを建てつつ、
それを上流と自動連動できるようにSVKにしておきたい、と。

※
初期のワープロもそうだったしVer管理もそうなのだが、
計算機の一番おいしい使い方は「清書のためのツール」ではなく「下書きのためのツール」としての使い方なんだよね。
もちろん清書も綺麗だから、下書きを清書に流用するの自体は大歓迎なんだが、
ああいうツールを清書「専用」だと見なすのは愚の骨頂。
たとえばレビュー済みの納品物「だけ」SVNして、そのまえのファイルはWin共有フォルダ、なんてな運用がソレ。

…で、そこらへん突き詰めるとだ、

>Gitのよいところ

分散管理(それも上流下流の区別のないタイプ)は、やはり「下書き」の管理としては、より秀逸なんだわ。
Gitの実装そのものが良いとは言わないが、やっぱり分散、そして上流下流の区別がないこと、は重要だと感じる。

SVNじたいはバランスが良いツールだとは思うんだが、結局部分最適解でしかないんだな。

Re:

[Anonymous Coward]

>(たとえば「レビューが終わるまでCOMMITするな」とか。なんのためのVer管理なのか理解してないたぐい※)

Subversionの管理者やってますが、逆にレビューが終わってないのをCommitするのに
何のVer管理のメリットがあるのか聞きたいですね
Ver管理を行っているのは、不具合、その他が起こった場合にどこでバグが発生したのかのチェックと
そのVerへ戻せる環境を作る為のはずです。
まぁ、小規模なプロジェクトならしょうがないですが・・

Ver管理 = バックアップと思ってる人が多すぎる。
1日の作業が終わったらCommitとかどうやって履歴を管理しろと言うのか
バックアップに使うのなら個人の環境で取るかブランチ作って勝手にやってくれ

Re:Subversionは人気がないのですかね？

[130R (31126)]

Ver管理を行っているのは、不具合、その他が起こった場合にどこでバグが発生したのかのチェックと
そのVerへ戻せる環境を作る為のはずです。

別にレビューなしでコミットしても、過去バージョンには戻せますよね。
レビュー云々は運用次第だからどうでもいいけど、作業のスナップショットとしてコミットするのは問題ないと思います。
まあ、作業終わりでコミットされるの嫌なら分散SCM使って、ローカルとマスターリポジトリで運用してはどうでしょう。

#やたらリビジョン番号あがるのをいやがったり、ログが汚れるのをいやがる人がいるけど、そんなん気にしても仕方ないよなあ

Re:

[Anonymous Coward]

UnitTestを一通りクリアしてればcommitするというルールで十分。
レビューは都度tagを打って行えばいい。

>まぁ、小規模なプロジェクトならしょうがないですが・・

いちいちレビューしてからcommitするなんていう、ちんたらした体制こそ小規模向きですよ。
それとも、そこまで慎重にやらないとひどいコードが溢れるような環境なんでしょうか？
だったらバージョン管理より、まず優秀な人材を揃えるなり教育をする方が先では？

まあ釣りだと思うけど。本気でレビューしてからcommitなんてやっているならどこか教えてくれ。
絶対に関わらないようにするから。

Re:

[Anonymous Coward]

ああ、レビューって言葉の取り方に違いがあったかもですが、
UnitTestレベルのテストを通してからCommitするとの意味で反応しました。

単体テストも何もしてないものを後で戻せるからといって
バカみたいにリビジョン上げる人は多いですが、trunkはある程度綺麗に保つっていうのは
ソース管理するに当たって必要な条件だと思ってます。

前にも書きましたが、修正単位でCommitを意識しないならbranche作ってやって欲しいです。
VSSじゃなくSubversion使ってるなら尚更ですね。

Re:Subversionは人気がないのですかね？

[annoymouse coward (11178)]

そういう subversion の"使いにくさ"を踏まえて、 git が開発された訳ですが。

そもそも git 使ったことあります？

Re:

[Anonymous Coward]

Git Mercurial Bazaar など一通り試してみましたが、
Windows環境での開発を行う場合、個人では使えますが
日本語使えないなど制限多すぎて、後1年ぐらいは待ちですね。

後、Trac、Redmineなどのバグ追跡系との連携もまだまだ未成熟なので。

ただ、外注時の分散開発などでのソース同期はかなり使えると思います
今時点でWindows環境ではMercurialですかねぇ

Re:

[Anonymous Coward]

この話題の元ACです。

上流は何を考えているのやら、と思います。
たぶん、
「管理」という概念を何か勘違いしている人間が上流で「管理」権限を握ってる、
といったことなのでしょう。

>何のVer管理のメリットがあるのか聞きたいですね
>そのVerへ戻せる環境を作る為のはずです。

ほかのひとも言っていますが、どの段階をCommitしようが「戻せる」わけですし、
交通整理をしたいならCommitするかどうかじゃなく、
Truncや(運用で決めたしかるべき)BranchにいつCommitするか、で整理するほうが上策です。

>小規模なプロジェクトならしょうがない

いえ。「大規模」なプロジェクト(をおこな

Re:

[Anonymous Coward]

> ただ、こういう考え方の人は少数派であり、
> Commitは面倒だ、Commit頻度をいかに少なくするかが生産性の鍵である、
> と思い込んでる人のほうが多かったりします。
> 困ったもんだ。

こういう結構やってる人のコメントを見ると
やはりバージョン管理行う目的に非常に差異を感じます。

> Commitは面倒だ、Commit頻度をいかに少なくするかが生産性の鍵である、
たぶん、管理者はこんな事考えてなくて、勝手にバンバン増やされたリビジョンで
問題発生した時どこまでどうやって戻せばいいの？
っていうだけだと思います。作った人ならそりゃわかるでしょうが・・

Re:

[Anonymous Coward]

>問題発生した時どこまでどうやって戻せばいいの？
>ある修正を行うことに対するリビジョンはできる限り少なくするのが当たり前と思ってます。

いや、だから、
それは「バージョン」(リビジョン)管理じゃなく「タグ」管理によって実現してください。
戻す単位はタグで管理してください。
修正の「単位」もタグで単位付けをしてください。

そして両方を同じツールで地続きに管理するほうが、二重管理にならなくて扱い易いってことです。

>プログラマの生産性とか(中略)では無くて

(バージョン管理が)生産性に寄与しないんだったら、
邪魔とまでいわないけど控えめに言っても「無駄」なツールだ、と

Re:

[Anonymous Coward]

＞なのでバグ管理システムの併用が肝だとは思うのですが、それをしたって一つのチケット（問題） ＞に対し、10もリビジョン作られたらたまらないですよね？ 全然困りません。100でも200でもリビジョン作ってokです。問題発生時の手がかりが増えるので大歓迎です、普通の感覚なら。

Re:

[Anonymous Coward]

なるほど。おっしゃりたい事はよくわかりました。
ただ、Git、Mercurialなどの分散管理システムと違って
説明されている「タグ」ってSVNで言うTagの事ですよね？

タグ付けって単なるリビジョンのその時点でのスナップショットでしかないので
修正単位でタグ付けするためには、Commit順序を厳密に管理してないと
好ましいもののみ集まった「タグ」にはならないですよね？

普段、ブランチでリビジョン上げておいて集まったリビジョンをTrunkへマージして
タグを作るっていうんならわかりますが、そのリビジョンを集めるのも
好き勝手にリビジョン上げられているとどうやって把握してマージするのでしょう？

チケットに紐づいてるのは全部マージだろって話でしょうが、
管理者にとってはもの凄い負担です。

そういった使い方だと、やはりブランチで勝手にやっててもらって修正が終わったら
まとめてトランクにマージしてね。っていうぐらいしかまともに管理できる方法は思いつかないですね

Re:

[Anonymous Coward]

あ、書き忘れたので

プログラマとして履歴を取りたい物と、プロジェクトとして履歴を取りたい
物が一致してないのが問題だとは思います。

本来であればGitなどの分散管理システム使えばうまくいきそうなのはわかってるのですが
Windows環境、日本語問題など通常の開発現場に持ち込むのはどうにも躊躇しています
こういうソース管理ってかなり大切な部分だと思うのですが
日本の開発現場だとほんとおざなりだと思います。

こういう議論できる場も人もほとんどなくて開発に流される事が多いので
今の議論も結構楽しかったりします

Re:

[Anonymous Coward]

リポジトリの切り方がでかすぎるんじゃないかな。
リポジトリの粒度を考えるのが面倒というなら、確かに分散系のが向いてる。

ただ根本問題として、修正単位一つ一つに対して、戻せるようにしたいという要求がちょっとズレているというか、マイクロマネージメントの傾向が高すぎるんじゃないかな。
開発中盤でそんな事はしないだろうから、おそらくリリース直前の状況と思うけど、それはバージョン管理ではなくリリースエンジニアリング技術の問題になるのだと思うよ。
つまりリポジトリ管理者であるあなたの権限の外側に問題がある = 全体のマネージメントがおかしいので、プロマネにクレームを挙げるべきかと。

Re:

[Anonymous Coward]

> (たとえば「レビューが終わるまでCOMMITするな」とか。なんのためのVer管理なのか理解してないたぐい※)

某社に出向してた時の事。

当時（もう5年位前ですかね…）その出向先のプロジェクトはCVSサーバでバージョン管理をしてた。
そこでのルールは、レビュー後コミットみたいなものは無かった。
が、何処の誰か知らないけれど（プロジェクト全体は、当方は全く把握しておらず、
プロパーのPLクラスの人と直接コミュニケーションをとりながら作業を進めていた）
ろくに動作確認もせずコードをアップする馬鹿が居た。
当方窓口のPLからは動作確認を強要され（ま、常識なんですが…）、コミット

Re:

[Anonymous Coward]

>動かんソフトにバージョン付加してもしょうがないよね

違います。その言い方に合わせて説明するならば、(動く)ソフトに付加すべきは、バージョンではなく「タグ」です。

つまりSVN(CVSもだが)のバージョン管理は、少なくとも「二段構え」になってる、と捉えるべきなのです。
まずバージョン(リビジョン)がある。
その上位にタグがある。

だいたい「動く」かどうかなんてのは、主観が絡んだり、相対的なもの(UTではOKだが結合すると没だったり)なので、それを基準にCommitじたいを受け付けるか否か決めるなんてのは無理です。まずセーフネットとしてとりあえず全部Comm

Re:

[Anonymous Coward]

コミット前のバージョンを取り出す方法も知らないような人は苦労しって当然でしょうな。 てか何にも分かってません、あんた。

Re:

[Anonymous Coward]

Commit前のバージョン取り出すのなんか知ってるに決まってる。
問題は、Commitされたバージョンが正しく動くバージョンかどうか
どうやって判断するのか？じゃないのか
そのための知恵として trunk と branche 、unittest なんかがあるわけで

ソース管理って本気でやろうとするとどうやっても難しいよ
使い方を制限するか、すべて分かってるメンバー揃えるしか無い