[過去ログ] バージョン管理システムについて語るスレ3 (1001レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
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)
上の異なるヘッドことを指しており、リポジトリ上で別の
ディレクトリとして分岐されたものという意味ではないですよね?
確かに「ブランチするときはそのブランチ用のリポジトリを
作れば良い」という記述も見ました。そのときリポジトリ丸ごと
クローンするのでしょうか?巨大なプロジェクトだと一部だけ
クローンして作業を進めたいというのはあり得ると思います。
分散型だと「あるリポジトリが消失しても別のリポジトリを
マスターと思えばよい」という記述も見ましたので、
分散している各リポジトリはそれぞれ対等にフルのツリーを
持っているのでしょうか?
602(1): 2009/03/01(日)13:50 AAS
VCS毎に違いはあるだろうけど、たいていはローカル(というかハードリンク可能な場所)なら
ハードリンクでリポジトリの内容を共有して領域節約できる。
ネットワーク経由の場合もフルに取ってくるんじゃなくて、最新からこのリビジョンまでって指定も出来る。
「ブランチ」って言葉の使い方も、VCS毎に変わるから一概に言えないな。
gitやhgは同じリポジトリの中でブランチ出来るけど、bazaarはリポジトリも別になるとか。
結局のところいくら記事読んでも、実際使ってみないと実感わかないと思うよ。
きっと分散じゃないVCS使い始めたときもそうだっただろ。
Subversion使ってるなら、svkとかgit-svn使ってみるとか。
603(1): 2009/03/01(日)14:11 AAS
そもそも「リポジトリ」という言葉の意味すらシステムによって違うしな
>>601
端的に言うと、分散型の進め方では
「フルのクローンをそれぞれ持っている」という理解はおおよそ合ってる
各作業メンバーが、「masterの履歴+自分が行った変更の履歴」を持ってるような感じ
> 巨大なプロジェクトだと一部だけ
> クローンして作業を進めたいというのはあり得ると思います。
一部だけ持ってこれるような仕組みがあるよ
たとえばBazaarなら、履歴なしで最新版のファイルだけを取ってこれるようなオプションがある
604: 601 2009/03/01(日)14:58 AAS
>>602-603 ありがとうございます
>gitやhgは同じリポジトリの中でブランチ出来るけど、bazaarはリポジトリも別になるとか。
分散型といってもいろいろあるんですね、流儀が(当たり前か)。
>>602 wrote ネットワーク経由の場合もフルに取ってくるんじゃなくて、
>最新からこのリビジョンまでって指定も出来る。
>>603 wrote たとえばBazaarなら、履歴なしで最新版のファイルだけ
>を取ってこれるようなオプションがある
リビジョン範囲は指定できるものもあるんですね。
「分散型」を十把一絡げで理解しようとしたのが間違いでした。
605(1): 601 [長文すみません] 2009/03/01(日)15:01 AAS
最も強く疑問に思ったのは、あるプロジェクトのリポジトリ内に
「アプリの主要部分、いくつかの下請けライブラリ、
ドキュメント、UI関係」などがあったとき、
自分が担当しているライブラリ、ドキュメントの部分だけを
クローンして作業を進めるということができるのだろうか、という点でした。
これは最初から「ドキュメント用のリポジトリ」などに分離
しておくのが分散型の流儀なのだろうか?という点です。
これもDVCSによって異なるのかもしれませんが。
もう一つの疑問が、そのように完全に分離したとして、
共通の祖先をもたない複数のリポジトリを複数あつめて
一つのプロジェクトを遂行するのは難しいのでは?ということです。
たとえばプロジェクトの途中で「これは共通のライブラリで実現するように分離しよう」
などという決定が 可能なのだろうか、と懸念しています。
Pythonを常用しているので、まずはMercurialとBazaarから主に上記の点について
実感をもつべく使い始めてみようと思いますが、DVCSの機能もさることながら
運用上のポリシー という側面も大きいと思うので、実際に使っておられる方の
アドバイス(ベターなプラクティス)があればぜひお聞かせください。
606(1): 2009/03/01(日)16:48 AAS
そもそも分離したいという目的は?
リポジトリの物理的大きさの問題であれば
いまさらそんな気にすることはないと思うけど・・・
管理面の規模の問題なら、分割するのもありかもね。
JDK7 なんかは分かれてるし。
分割した方が管理コストがさげられるならそうするべきでしょう。
607: 2009/03/01(日)18:47 AAS
http://sarabande.info/doc/bzr/user-guide
ここの画像無くなってる?
608(2): 2009/03/02(月)20:27 AAS
>>601さん、なかなか興味深い質問ですね。
分散VCSを使い始めた人の意見や疑問点をもっと聞いてみたいので、ほかにも質問があれば遠慮なく書いてください。
もちろんすべてに答えられるわけではないですが、他の人にも参考になると思います。
>>606
ディスクスペースを節約するために必要なディレクトリだけ持ってくるというのはあり得る。
たとえばゲームのように画像や動画や音声ファイルがある場合、それらもリポジトリに登録するべきだけど、
そうするとリポジトリサイズが膨らみすぎて、いくらHDDが安いと言ってもちょっと困る。
リポジトリからとってくるネットワーク資源もばかにならない。
あと、ディレクトリごとにアクセス権をつけたいという要求もある。
たとえば画像ファイルは全員がアクセス可能だけど、元となるPhotoshopファイルはデザイナーだけがアクセス可能にしたい、とか。
#この場合はリポジトリを分けた方が自然かも。
609: 2009/03/03(火)02:43 AAS
>>608
メディアファイルをリポジトリに「登録するべき」と決めつけずに、
分散かどうかに関わらず、リソースなども照らし合わせて管理方法を検討すべきだろうね。
最新ファイルしかいらないのにそもそもリポジトリを公開すべきなのか、とかも。
サブプロジェクトへの権限委譲については、
やっぱりJDK7みたいにするのがいいんじゃないかな。
アクセス制限も分散は難しいし、ロックもないし、
人間どうしの折衝や信頼は結構重要。
上下前次1-新書関写板覧索設栞歴
あと 392 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.021s