[過去ﾛｸﾞ] バージョン管理システムについて語るスレ3 (1001ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
582: 2009/02/25(水)23:11 AAS
そもそもmergeが優れているってどういうこと
583: 2009/02/26(木)00:16 AAS
SubversionとMercurial使ってるけど、俺も「Mercurialはmergeが優れている」って
聞く度にいつも、いまいち意味が分からんと思う。
584: 2009/02/26(木)00:44 AAS
branchは、破棄されるか、trunk(master)に統合されるか二択。
そういったprojectなら、gitやhgはbranchしたのが何時だったか思い出す
必要が無い。mergeが優れているのは、その一点のみ。
その主張は、ほとんどの場合正しい。
585: 2009/02/26(木)01:34 AAS
ああ、branchで作ったディレクトリを見失う（どこにブランチ作ったか忘れる）心配がないって事ね
でもそれmergeが優れているわけではなくて、単なるbranch方式の違いだよな
586: 2009/02/26(木)02:08 AAS
マージの優劣って言葉通りじゃなくて、マージトラッキングや
その自由度・速度を含めたことだと思うが･･･
587(1): 2009/02/26(木)02:16 AAS
Mercurialって、マージの自由度低くない？
統合する方向のマージに強制されてるような気になってる来るというか、
cherry-pickingしにくい仕組み。
むしろ、Subversionぐらいの放任主義の方が自由感がある。
588(1): 2009/02/26(木)02:28 AAS
git or mercurialは3-way マージでsubversionは2-way マージだったはず。
589: 2009/02/26(木)02:32 AAS
>>587
機能を追加するたびに、bookmarkがbranchを使えばそもそもcherry-pickingする必要がない。
gitとmercurialは両方とも、mergeとcherry-pickingを区別してたと思う。
590(2): 2009/02/26(木)02:50 AAS
>588
3-way マージって、
(1)自分が編集したバージョン
(2)第三者が編集したバージョン
(3)上の(1)の元になったバージョン
の3-wayでしょ？
なら、Subversionと一緒じゃん？
591: 2009/02/27(金)00:19 AAS
>>590
Subversionって、ファイル単位でコンフリクトしたらCになって終了（解消してね）
じゃなかったっけ。今は違うのかな。
svkとかGitだと行単位でぶつかってなければ良い感じにマージしてくれる。
592: 2009/02/27(金)00:22 AAS
CVSの昔から、行単位でぶつかってなければ自動マージだろう……。
593: 2009/02/27(金)00:25 AAS
行単位だよ。
594: 2009/02/27(金)00:53 AAS
>>590
gitとmercurialは(3)が(1)と(2)の両方の元になったファイル
595: 2009/02/27(金)09:56 AAS
Linuxレベルならともかく、普通の規模のプロジェクトとか
普通の業務利用とかでそんなに賢いマージが必要
なのは、ちょっとどうかという気もするが・・・
マージだけならSubversionで困らない。
会社でSubversion個人でGitだけど
596: 2009/02/27(金)11:02 AAS
も少し賢くてもいいけどなぁ
あと Subversion は遅くね?
597: 2009/02/27(金)12:16 AAS
TortoiseHGでコミットするとき、Mステータスのファイルにデフォルトでチェック付けたい。
どっかで設定できる？
コミットツールはinternalって設定にしてる。
598: 2009/02/27(金)15:48 AAS
分散SCMだと分岐したまま進められちゃうから、
共通先祖を考慮したマージが必要なんじゃないかな。
Mercurial の内部マージと diff3 のマージってどっちがいいのかな？
衝突時に共通先祖が表示されるんで diff3 使ってるけど・・・
599: 2009/02/28(土)03:32 AAS
デフォルトでチェックされてるけど
600: 2009/02/28(土)08:09 AAS
600
601(4): 2009/03/01(日)13:26 AAS
分散型のバージョン管理システムの場合、
それぞれのリポジトリはリポジトリ丸ごと
持っているという感じなんでしょうか？
あるリポジトリをマスターと決めたとして、
そのフルのクローンをそれぞれ持っているということでしょうか？
いまはSubversionを使っていて trunk, branches, tags 型で
かんりしてまして、branches の下の自分が作業を進める
ブランチだけ手元のワーキングコピーにチェックアウトして
作業しており、マージはマージ担当（まれに自分）に任せてます。
そもそも分散型だと trunk, branches, tags 型の
管理というのはやらないものなのでしょうか？
分散型のバージョン管理システムの紹介記事を読んでいると、
そもそも「ブランチ」というのはリビジョンツリー（というかDAG）
上の異なるヘッドことを指しており、リポジトリ上で別の
ディレクトリとして分岐されたものという意味ではないですよね？
確かに「ブランチするときはそのブランチ用のリポジトリを
作れば良い」という記述も見ました。そのときリポジトリ丸ごと
クローンするのでしょうか？巨大なプロジェクトだと一部だけ
クローンして作業を進めたいというのはあり得ると思います。
分散型だと「あるリポジトリが消失しても別のリポジトリを
マスターと思えばよい」という記述も見ましたので、
分散している各リポジトリはそれぞれ対等にフルのツリーを
持っているのでしょうか？
上下前次1-新書関写板覧索設栞歴
あと 400 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.028s