バージョン管理システムについて語るスレ8

1 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:26:04 ] バージョン管理システムについて語りましょう ●過去スレ バージョン管理システムについて語るスレ pc11.2ch.net/test/read.cgi/tech/1193332500/ バージョン管理システムについて語るスレ2 pc11.2ch.net/test/read.cgi/tech/1215520728/ バージョン管理システムについて語るスレ3 pc12.2ch.net/test/read.cgi/tech/1228366972/ バージョン管理システムについて語るスレ4 pc12.2ch.net/test/read.cgi/tech/1242918130/ バージョン管理システムについて語るスレ5 pc12.2ch.net/test/read.cgi/tech/1255241922/ バージョン管理システムについて語るスレ6 hibari.2ch.net/test/read.cgi/tech/1270640436/ バージョン管理システムについて語るスレ7 hibari.2ch.net/test/read.cgi/tech/1283780922/ 2 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:26:45 ] ●関連スレ CVS 1.3 [UNIX板] pc12.2ch.net/test/read.cgi/unix/1093611448/ CVS導入スレ〜 Rev.3 [プログラム板] hibari.2ch.net/test/read.cgi/tech/1113141518/ subversion バージョン管理【サブバージョン】 [Linux板] pc11.2ch.net/test/read.cgi/linux/1154701996/ Subversion r12 [プログラム板] hibari.2ch.net/test/read.cgi/tech/1254838551/ Git 2 [プログラム板] hibari.2ch.net/test/read.cgi/tech/1284467898/ 【分散型バージョン管理】 Mercurial 【hg】 hibari.2ch.net/test/read.cgi/tech/1251208950/ 【bzr】Bazaarでバージョン管理 Rev 2 hibari.2ch.net/test/read.cgi/tech/1265951333/ 3 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:27:35 ] ●関連サイト CVS ttp://ximbiot.com/cvs/wiki/ Subversion ttp://subversion.tigris.org/ Git ttp://git-scm.com/ Bazaar ttp://bazaar.canonical.com/en/ Mercurial ttp://mercurial.selenic.com/wiki/ Darcs ttp://www.darcs.net/ GNU arch ttp://www.gnu.org/software/gnu-arch/index.html monotone ttp://www.monotone.ca/ Visual SourceSafe ttp://www.microsoft.com/japan/msdn/vstudio/products/ssafe/default.aspx ●チュートリアル Subversionによるバージョン管理(日本語訳) ttp://subversion.bluegate.org/ (アクセスできない場合は↓) ttp://www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork Git入門 ttp://www8.atwiki.jp/git_jp/ git チュートリアル (バージョン 1.5.1 以降用) ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html Bazaar Documentation Overview ttp://wiki.bazaar.canonical.com/Documentation Mercurial の使い方のチュートリアル ttp://mercurial.selenic.com/wiki/JapaneseTutorial 4 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:28:25 ] 立てました。 5 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:30:20 ] バージョン管理システムの選び方 1. 同時に一人しか編集できないロック機構が必要ですか？ 　│ 　├(YES)→ Subversionをおすすめします。ただし、オンラインでしか開発できなくなります。 (NO) 　↓ 2. 日本語のファイル名が存在し、リポジトリをMS-Windows（CP932）とLinuxやMacintosh OS X（UTF-8）で同期を取りますか？ 　│ 　├(YES)→ Subversionを選択してください。WindowsとLinuxでなら、Bazzarで日本語ファイル名の同期も可能かも知れません。 (NO) 　↓ 3. 実験的なソースコードを頻繁に作成しますか？ 　│ 　├(NO)→ Bazzarをおすすめします。Bazzarは他のDVCSに比べると分岐が手間ですが、それ以外は遜色ありません。 (YES) 　↓ 4. MS-Windowsでの利用をしますか？ 　│ 　├(YES)→ Mercurialをおすすめします。設定で、日本語コミット文やCP932のファイル名も取り扱えます。 (NO) 　↓ 6 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:31:24 ] 5. GUIやEclipseでの利用を重視しますか？ 　│ 　├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。 (NO) 　↓ 6. シンプルな操作がお好みですか？ 　│ 　├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。 (NO) 　↓ Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。 （チェンジセット: 4:ae4c01d241ab） 7 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:32:11 ] 811 名前：デフォルトの名無しさん [sage]： 2011/01/01(土) 17:45:53 皆様のレスを読んだ上で、再度、大雑把に特性をまとめてみた。 Mercurial: ・一つのリポジトリで複数のブランチが扱える。 ・分岐時は、無名ブランチが自動で切られる。名前付ブランチもつくる事ができるが、目印なので必須では無い。 ・ブランチ内のチェンジセットは木構造に並ぶ。 ・分岐したブランチは、元のブランチに依存する。あるブランチ内のチェンジセットを消すと、別のブランチにある子孫チェンジセットも消える。 ・複数のリポジトリで変更を行いpushしても、分岐しているので衝突はしない。ただし、解消が要求されるmulti-head状態になるので、先にpullが望ましい。 Git: ・一つのリポジトリで複数のブランチが扱える。 ・分岐時に、ブランチ名を考える必要がある。 ・ブランチ内のチェンジセットは直線上に並ぶ。 ・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。 ・複数のリポジトリで変更を行いpushすると、衝突が発生する。先にpullが必要。 Bazaar: ・ブランチだけで運用を行える。リポジトリを作ると、複数ブランチでデータを共有して省スペース、ブランチ作成などの高速化ができる。 ・分岐時に、ブランチのディレクトリ配置を考える必要がある。 ・ブランチ内のチェンジセットは直線上に並ぶ。 ・マージするときは、自分のリポジトリのコミットをメインライン、他のリポジトリのを傍流として記録。 ・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。 ・複数のブランチで変更を行いpush/pullすると、衝突が発生する。先にpullが必要。 8 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:35:22 ] 589 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:31:11 お前らこの「svnが遭遇してきた問題点とその解決策」を共有したいのでどこに記述あるか教えてください 【bzr】Bazaarでバージョン管理 Rev 2 hibari.2ch.net/test/read.cgi/tech/1265951333/491-495 491 ：デフォルトの名無しさん：2010/12/10(金) 18:02:33 bzr初心者です。2.2.2をMac上で使おうとしてますが、扱うファイル名に濁点が含まれていると うまく動いてくれません。NFCとNFDの問題が絡んでいるということはわかったのですが、 何か回避方法はあるんでしょうか？（何かパッチを当てるとか。） 492 ：デフォルトの名無しさん：2010/12/10(金) 22:45:46 # だれかutf-8-macなcodec作ってくれ 493 ：デフォルトの名無しさん：2010/12/11(土) 08:29:26 なんだBazaarでも日本語使えないのか 494 ：デフォルトの名無しさん：2010/12/11(土) 14:48:30 Subversionでも解決しているに>>1の「多言語に完全対応」というのは嘘だったのですね 495 ：デフォルトの名無しさん：2010/12/11(土) 21:48:19 svnが遭遇してきた問題点とその解決策が ハッカーの間で共有知になってないことが問題なのかもしれぬ 591 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:41:23 >>589-590 こっちでいいじゃん d.hatena.ne.jp/hnw/20081024 592 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:42:16 ここも www23.atwiki.jp/selflearn/pages/55.html 593 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:44:57 あとここ hibari.2ch.net/test/read.cgi/tech/1251208950/466-474 9 名前：デフォルトの名無しさん [2011/01/20(木) 15:00:23 ] MacHgがなかなか良い。 10 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 15:14:59 ] 749 名前：デフォルトの名無しさん [sage]： 2010/12/30(木) 19:23:52 append_revisions_only “True”に設定されていればリビジョンはログにのみ追加され、削除されません。 この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。 通常これは bzr init --append-revisions-only によって設定されます。 twitter.com/#!/methane/status/11806331434442752 append_revisions_only = True に設定したブランチでは、連番のリビジョン番号が固定され、ID替わりに使えること。 中央リポジトリ上のブランチはこの設定がおすすめ。 11 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 15:15:43 ] 751 名前：デフォルトの名無しさん [sage]： 2010/12/30(木) 19:46:58 もうちょっと詳しく言うと、bzrはgitやhgと違って、「メインライン」という概念があって、 履歴のウチ並列して存在するラインの片方がメイン、残りがマージされたブランチという扱いになる。 通常はメインラインのウチのリビジョンだけを表示することで、別ブランチで開発中にコミットされた 細かいリビジョンを無視して、それをメインラインにマージしたコミット１つにまとめて表示できる。 なので、ローカルで作業中に作ったゴミみたいなコミットをまとめて綺麗な１つのコミットにするみたいな 作業が要らない。 (もちろん、メインラインを無視して、全ブランチが同等という運用をしても良い) なんだけど、だれかがローカルのブランチから中央のブランチをマージすると、そのローカルでは メインラインはローカルブランチに、中央ブランチはサブラインになって、それを push すると 中央ブランチのメインラインが置き換わってしまう。 中央 1:A - 2:B - 3:C - 4:D ローカル 1:A - 2:B - 3:X - 4:Y -(中央からマージ)- 5:Z (この状況でローカルから中央に push) 中央 1:A - 2:B - 3:X - 4:Y - 5:Z (中央のサブライン 2:B - 2.1.1:C - 2.1.2:D - 5:Z) (リビジョン番号3と4に割り当てられているリビジョンが変わってる) これを許さないのが append_revisions_only 12 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 18:04:24 ] そろそろ、zipを超えるバージョン管理システムがでるかな？ 13 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 18:44:34 ] それならzipよりもmkdirっていうバージョン管理システムの方がずっと強い 14 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 22:46:02 ] しばらく見てなかったけどJGitが、結構使えるようになってるな。 JVM上で動くので、WindowsやLinuxでも、UTF-8環境の native Gitとでも 日本語ファイル名も含めて今のところ相互運用に問題は無い。 まだ実装されてない機能もあるし、GUIで扱うなら eclipse のEGit plug-in に頼らないといけないところが難点。EGit の UI は悪くないけどね。 15 名前：デフォルトの名無しさん [2011/01/20(木) 22:59:57 ] 20110120最新-2.zip みたいな悪夢見さすな。 16 名前：デフォルトの名無しさん mailto:sage [2011/01/21(金) 00:10:52 ] インストールすると自動的にhomeに公開、ダウンロード、音楽、ビデオ、デスクトップ、 文書、テンプレート、画像、なんてディレクトリが作られちゃうんで是非ともutf8のマルチ バイト文字列のファイル・ディレクトリ名をきちんと操作・バージョン管理できるよう、おな がいします。 17 名前：デフォルトの名無しさん mailto:sage [2011/01/21(金) 00:43:44 ] 他人と共同作業じゃなくて、自分用のバックアップ目的で使うには、Bazaarが最強との結論に達した。 18 名前：デフォルトの名無しさん mailto:sage [2011/01/21(金) 00:55:06 ] 俺は個人で使うのはgit、他人と共同作業で使わせるのはbzrという結論になった 本当は一つにしたかったし、もし無理矢理一つにするんだったらhgを選んだろうけど 19 名前：デフォルトの名無しさん mailto:sage [2011/01/21(金) 01:41:43 ] 前スレでTeam Foundation Server使用したことある人がいたようなので 使用感はどんな感じか聞いてみたい。 特に大きなリソースを扱うプロジェクトでのパフォーマンスなど。 Perforceの対抗馬になるようなら嬉しいんだけど 20 名前：前スレ989 mailto:sage [2011/01/21(金) 23:57:50 ] >>19 それを書いたのは俺だが……すまん、実務ではまだ使ってないんよ。今年中にはVSSからの移行先としてTFS2010を評価する予定だけど。 まだホワイトペーパー（download.microsoft.com/download/A/C/5/AC56DA05-5AEA-4118-B2F9-83C4E70834F1/TFS2010_SCM.pdf） しかまだ見てないです。ちなみにシェルブ機能の紹介はP.57にあるね。 （ここから下は全部憶測） 個人的には、そもそもIIS+ASP.NET+SharePoint+MSSQLが要るという時点で、パフォーマンスはあまり期待してなかったり。 少なくとも、DBサーバーをインストールするマシンは十分なI/O性能を確保しないと悲惨なことになると思う。 その辺は伝統的な3層クラサバとまんま同じノウハウが適用できる（というか必要になる）ハズ。 あとは評価してみないことには分からないけど、ウチの場合、100MB近いMDBを数十個扱う予定なので、 その結果分かったことがあれば、ここに書くよ（忘れてなければ……）。 21 名前：デフォルトの名無しさん mailto:sage [2011/01/22(土) 04:43:43 ] sshの公開鍵をくださいと言ったら、秘密鍵と公開鍵の両方がメールで送られてきた。 BASIC認証でしか運用ができないので、Gitではなく、hgwebがあるMercurialを採用することにした。 22 名前：デフォルトの名無しさん mailto:sage [2011/01/24(月) 17:36:10 ] TracやRedmineを併用している？ 23 名前：methane mailto:sage [2011/01/25(火) 16:58:26 ] >>8 svn.apache.org/viewvc/subversion/trunk/notes/unicode-composition-for-filenames?view=markup ちなみに、2月リリースのbzr-2.3のベータ版ではもう直ってるっぽい。 24 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 06:51:31 ] >>23 これで「社会が憎い.properties」が使えるわけですね。 25 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 10:39:24 ] >>23-24 誰得アプリに磨きがかかったのですね 26 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 11:49:05 ] >>25 リポジトリの構造や、ブランチ操作の手軽さはMercurialの方が優位だと思うが、弊社の以下の状況はBazaar優位になっています。 ・PM佐藤は「英語わからんし」とつぶやいて、日本語ファイル名を作る。 ・PG田中はマカーなので、Windowsは手が汚れると言って触りもしない。 ・PG茶谷はLinuxでvimを使うことだけがアイデンティティ。 ・ﾃﾞｻﾞｲﾅ鈴木はWindows以外は分からないと言って、Macintosh OS Xを直視もしない。 27 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 11:51:09 ] 全員クビにしろよ 28 名前：methane mailto:sage [2011/01/26(水) 12:28:18 ] >>26 リポジトリの構造ってMercurial優位だっけ？ bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、 いつの間にか新しいリポジトリフォーマットが出てきてたのかな。 29 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 12:36:33 ] >>28 表現方法が悪いのかも知れないけど、以下の理由でMercurialの方が優位だと思う。 ・チェンジセットの関係が木構造で操作が直感的。 ・名前無しブランチがあるので、ブランチを作るのが容易。 ・名前付ブランチも、まとめてpush/pullできる。 GitもBazaarもブランチは直線的で、分岐するのには操作がいる。clone、push、pullもブランチ単位。 特にBazaarは、ブランチの扱いでディレクトリ配置を意識する必要がある。 30 名前：methane mailto:sage [2011/01/26(水) 12:44:09 ] >>29 あぁ、 .bzr とか .hg 内部のファイル／データ構造という意味じゃないのね＞リポジトリの構造 そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。 31 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 12:51:50 ] >>28 > bzrの方がファイル数少なくて容量小さいし、 hgはコピーをサポートしていて、ファイルの移動はコピーと削除だから 大幅にディレクトリ構成を変更した場合、必然的にリポジトリがでかくなる。 あまりにも大幅な構成の変更の場合、convertをした方が良い bzrはコピーをサポートしている？ FATの場合、でかいファイルの方がフラグメントやらで都合が悪くない？ gitの場合、packするしないはユーザの自由だが、bzrは勝手にパックしちゃうのか？ > やたら長いパスのファイル名を > 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、 cygwin あと、例の拡張 > いつの間にか新しいリポジトリフォーマットが出てきてたのかな。 進化している マイナーチェンジで基本は全く変わっていないけど 32 名前：methane mailto:sage [2011/01/26(水) 13:02:40 ] >>31 bzrはコピーは今はサポートしていない。 代わりに、移動はサポートしていて移動しても容量は増えない。 FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。 パックは10、100、1000コミットごとに自動で行われる。 >cygwin >あと、例の拡張 Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。 例の拡張ってなんだろう？ 33 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 13:12:22 ] >>32 > >>31 > bzrはコピーは今はサポートしていない。 > 代わりに、移動はサポートしていて移動しても容量は増えない。 > > FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが > ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。 > パックは10、100、1000コミットごとに自動で行われる。 2GB制限は？ > >cygwin > >あと、例の拡張 > Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。 > 例の拡張ってなんだろう？ 当然知っているでしょ？ MAX_PATHのことを言っているんでしょ？ ANSI APIを使うという方針なんだから仕方がない。 それを横取りしている拡張 34 名前：methane mailto:sage [2011/01/26(水) 13:31:30 ] >>33 bzr関連のブランチを格納しまくってるshared repositoryの中をのぞいてみたら、 pack数が12個で最大のものが31MBだから、ソースコード管理では2GB制限は 気にしないで良さそう。動画ファイルとか大容量のファイルの扱いは確かに苦手。 MAX_PATHはANSIとは直交した制限で、CreateFileWとか使っても同じUTF-16の コードポイント数が制限を受ける。 この制限を回避するためには "\\?\c:\" みたいな書きかたでWin32APIのチェックを スルーしてファイルシステムにアクセスしないといけないんだけど、これをやると カレントディレクトリとか一切使えなくなる。 例の拡張ってのが、もしfix-utf8の事を言っているのであれば、僕が昔触ってた時は utf8<=>utf16の変換をしていただけで、 "\\?\" は使ってなかった。 35 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 13:40:40 ] hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、 って、これも知っているよね？ もう１つの拡張の方も横取りしている。 パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、 そこがANSI APIになっている。 36 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 13:48:26 ] >>30 >そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。 リビジョン番号30（ハッシュタグ0b70750bdf9b02597741301c695ff46bc75036d4）から分岐するとする。 Mercurial (3ステップ): hg update -C -r 30 [編集] hg commit -m "以前のバージョンから分岐" Git (4ステップ): git branch NewBranch 0b70750b git checkout NewBranch [編集] git commit -m "以前のバージョンから分岐" Bazaar (4ステップ): cd .. bzr branch -r revno:30 ./OldBranch ./NewBranch cd NewBranch [編集] bzr commit -m "以前のバージョンから分岐" Bazaarはブランチがファイルシステムと連動しているSVN風なので、ブランチの切り替えが手間。マージもファイルパスを指定する必要がある。 Gitはブランチ切り替えは容易だが、ブランチの切り替えが必要。 Mercurialは、編集対象のチェンジセットと連動して、自動的に無名ブランチが切られる。 個人的には、Bazaarが洗練されているようには思えない。 37 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 13:59:05 ] >>36の続きだが、Bazaarの「リポジトリ」もあまり良いコンセプトに思えない。 準備無しにBazaarでブランチを切ると、ディスク占有サイズが倍増する。 「リポジトリ」を作っておけば、ブランチを切っても実ファイルはシェアするが、事前準備がいる。GitやMercurialには不要な作業。 後から「リポジトリ」を使うこともできるが、移行作業はいる。 38 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 14:07:06 ] >>36 Git (3ステップ): git checkout -b NewBranch 0b70750b [編集] git commit -m "以前のバージョンから分岐" 39 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 14:09:15 ] >>36 git checkout -b NewBranch 0b70750b 40 名前：methane mailto:sage [2011/01/26(水) 14:12:49 ] >>35 >hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、 >って、これも知っているよね？ bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を 用意してて、同じファイルシステムで clone した後に push / pull したら共有できない という制限もない。 >もう１つの拡張の方も横取りしている。 >パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、 >そこがANSI APIになっている。 もう一つって、win32なんちゃらの事かな？ 最近hg使ってないから最近の事情に疎くて、、、またhg使い始める予定だから調べとこ。 一応言っておくけど、 hg のリポジトリフォーマットが効率悪くて使い物にならないとか 言ってもなければ思ってもないよ。 >>26 を hg のリポジトリフォーマットがbzrより優秀と誤読したから反論しただけ。 リポジトリフォーマットは hg, git, bzr 全部、ソースコード管理目的では十分な効率をしている。 hgでMAX_PATHが問題になるのもレアケースで、僕が使ってる限り問題になったことはない。 41 名前：methane mailto:sage [2011/01/26(水) 14:13:42 ] >>36-37 つbzr-colo 42 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 14:53:47 ] >>41 何それ？ 43 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 15:19:30 ] >>40 > >>35 > >hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、 > >って、これも知っているよね？ > > bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を > 用意してて、同じファイルシステムで clone した後に push / pull したら共有できない > という制限もない。 foozy.bitbucket.org/hgbook-ja/d6ca1334a19d/hgbookch4.html#x27-790004.5 何人かの構成管理ツールの開発者により、この方法 完全にリポジトリ固有のものとしてファイルを複製する が ディスク使用量削減にそれほど効果的でないとの指摘を受けています。それは事実ではありますが、 ディスク容量の 確保は安価であり、 OS への複製要求を遅延することにより高い性能を得ることができます。 別な仕組みを用いる場合、性能が低下しソフトウェアの複雑さが増しますので、 日々の利用における “体感” に非常に影響を及ぼします。 訳注: つまり、 Mercurial でのハードリンクの使用は、複製を行うことによるディスクヘッドのシークを 低減するのが主眼で、ディスク使用量の低減が主眼ではな い、ということです。 44 名前：methane mailto:sage [2011/01/26(水) 18:32:36 ] >>42 簡単に言えば、gitみたいな名前付きブランチを実現するもの。 bzr自体は作業ツリー、ブランチ、リポジトリを分離して自由に構成できるけど、 逆に自由すぎるのが面倒なので、1リポジトリ, 複数のブランチ、1つの作業ツリーの 組み合わせを git のように扱えるようにしてくれるもの。 >>36 で言えば、 bzr colo-branch -r30 NewBranch の1ステップになる（現在のブランチ=OldBranchのr30からNewBranchを作って、 作業ツリーを新しいブランチのチェックアウトに切り替える） 45 名前：デフォルトの名無しさん [2011/01/26(水) 19:00:02 ] >>44 > >>42 > 簡単に言えば、gitみたいな名前付きブランチを実現するもの。 　　　　　　　　　＼　　　∩─ｰ､ 　　　==== 　　　　　　　　　　 ＼／　●　､_ ｀ヽ 　　====== 　　　　　　　　　　　/ ＼(　●　 ● |つ 　　　　　　　　　　　|　　 X_入__ノ 　 ミ　　　そんな餌で俺様が釣られクマ―― 　　　　　　　　　　　 ､　(＿／　　　ノ　/⌒l 　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　===== 　　　　　　　　　 　 〈　　　　　　　　 ＿_ノ　　==== 　　　　　　　　　　　 ＼　＼＿　　　　＼ 　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒ 　　　　　　　　　　　　　　　　＼　　 ＿＿_ ＼＿＿　　(´⌒;;(´⌒;; 　　　　　　　　　　　　　　　　　 ＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ 46 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 23:34:10 ] 誤解を恐れずに言えば、Gitにはブランチは存在しない 旧来のブランチの機能を果す何物かがあるだけ 47 名前：デフォルトの名無しさん mailto:sage [2011/01/26(水) 23:54:13 ] mercurialの設計で一番の間違いはブランチを名前で管理できると思ったところだと思う。 48 名前：methane mailto:sage [2011/01/27(木) 00:12:55 ] え、じゃぁ progit.org/book/ja/ch3-2.html ここでいう 'master' ブランチ とかいうのは名前付きブランチじゃないの？ まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように なるのが bzr-colo 49 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 00:40:14 ] 突然だけど、Meld と Diffuse ってどっちが使いやすい？ プラットホームは Linux で。ほかにも何かおすすめがあれば。 50 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 00:43:20 ] >>48 bzrはよく分かんないんだけど、 gitは>>46の通りで、SHA1ハッシュに対するエイリアスをブランチと呼んでいるだけで、 内部的には「ブランチを作る」という機能は無いと言っていい。 ただUIとしては「ブランチ」と特化した表現をしたほうが分かりやすいので 「ブランチを作る」というコマンドは存在する（エイリアスを作るだけのコマンド） 51 名前：methane mailto:sage [2011/01/27(木) 00:47:49 ] >>50 うん、で、今は内部構造じゃなくてワークフローの話をしているんだから、 >>44 の発言って別に間違ってないよね。 >>45-47 の突っ込みは気にしなくて いいよね。 52 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 00:54:56 ] >>50 馬鹿なの？ ブランチの意味知らないんなら喋らないほうがいいよｗｗｗ 53 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 01:10:01 ] 極端な例だけど下記のような分岐をした場合、各VCSはどのようにbranchを管理するでしょうか？ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿branch1 ＿×＿×＿×＿×＿×＿×＿×＿branch2 ×＿×＿×＿×＿×＿×＿×＿＿branch3 ＿×＿×＿×＿×＿×＿×＿×＿branch4 ×＿×＿×＿×＿×＿×＿×＿＿branch5 54 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 02:27:26 ] >>52 は？ 55 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 04:46:40 ] MercurialやGitのようなブランチの操作をするのに、bzr-coloが必要となる時点でBazaarは使いづらい。 「ブランチ」に対するアプローチが、 ・ディレクトリ名を指定 ・共有リポジトリ作成後、その下にあるディレクトリ名を指定 ・bzr-coloを利用 と3種類もある。 GitやMercurialはシンプルなコンセプトで実装が見えない所が、SVNに似ているので見えてしまうのがBazaarという印象が拭えない。 56 名前：methane mailto:sage [2011/01/27(木) 07:43:19 ] >>55 だから俺は >>30 で >どちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。 って言ったんだけどね。 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が 安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） だから、自分では bzr-colo はあまり使ってない。 ブランチ管理についてできるだけ特定のスタイルを押し付けないのがbzrの方針。 逆に言えば「こういうフローで作業しましょうね」という指針を提供してくれていないので 初心者にはどう使ったら良いのか判らなくなるし、gitと同じワークフローを採用すると gitよりもブランチ管理が手間になったりもする。 この点は結構前からBazaarのMLで議論されていて、bzr-colo は git と同じワークフローを 楽にするプラグインという以上に、将来の bzr の "bzr init" で作成するのを standalone branchじゃなくてcolocated branchにするための proof of conceptにも なっている。 57 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 07:44:04 ] >>47 Mercurialの「名前付きブランチ」は「おまけ」 リポジトリの分離と名無しブランチでも運用可能 cvsのブランチのように消さないことを前提としている 名前付きブランチを乱発すると収集が付かなくなるからcloseする機能が後から出来た 「名前付きブランチ」と「リビジョン番号」はgitには無い 58 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 07:46:13 ] >>48 > まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように > なるのが bzr-colo 用語はどうでもよいから、bzrは意味不明な用語を乱発しているのか 59 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 07:54:07 ] >>56 > 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が > 安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの > 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を > 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） 大量のごみブランチが発生するのは害でしかない マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい ブランチとやらがbzrの売りらしいが、 大規模コミュニティの開発では何のメリットも無い 60 名前：methane mailto:sage [2011/01/27(木) 07:58:51 ] >>58 いちいち突っかかるなぁ。。。 僕が git が定義している用語を知らないし興味もないってだけだよ。 gitはgithubクライアントにしか使ってないから。 bzr ではきちんと用語を定義して使い分けてるよ。 で、git で refs 以下で「コミットに対する名前による参照」を提供しているけど、 この「コミットに対する名前による参照」って git はなんて定義しているの？ 「ローカルブランチ」だとブランチが存在する場所が焦点になってしまって、 hgの無名ブランチと違って「名前で参照されている」という点に焦点を当てたかったから hgの用語を拝借して「名前付きブランチ」と呼んだんだけど。 61 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 08:04:16 ] >>60 ローカルブランチ、リモートブランチを勉強してから出直してきな 62 名前：methane mailto:sage [2011/01/27(木) 08:07:51 ] >>59 > 大量のごみブランチが発生するのは害でしかない > マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない だからこういう個人の主観による優劣で議論する気ないんだってば。 **俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」 ってならないし、本当に要らないものを整理する気になるから好きってだけで、 別にbzrはそれを強制してないから、 >>59 が bzr を使うときには俺と違う使い方をすればいい。 > github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい 意味が分からない。 リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？ 63 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 08:09:19 ] >>60 > 僕が git が定義している用語を知らないし興味もないってだけだよ。 bzr開発者はgitに興味が無いから、bzrは使い勝手の悪い誰得アプリになってしまったのか 64 名前：methane mailto:sage [2011/01/27(木) 08:12:07 ] >>61 gitも一応githubクライアントとして少しは使ってるから、 ローカルブランチとリモートブランチは使ってるよ。 どちらもコミットのハッシュ値ではなくて名前で参照できるという点では、 hgでいう「名前付きブランチ」だね。 もちろん完全に同じものとは言ってないよ。 65 名前：methane mailto:sage [2011/01/27(木) 08:13:34 ] >>63 本当にそうなら bzr-colo なんて存在しないよ。 66 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:01:24 ] >>62 > **俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」ってならない Gitはブランチの一覧ができる。 Mercurialはブランチやヘッドの一覧ができる。 Bazaarはディレクトリを見て、「これブランチだっけ？」と考える必要がある。 目につくところに無いのは、Bazaarとしか思えない。 67 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:05:55 ] >>62 > > github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい > 意味が分からない。 > リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？ 意味が分からない 「個人所有のブランチ」って何？ 68 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:19:32 ] >>62 > だからこういう個人の主観による優劣で議論する気ないんだってば。 「個人の主観」ではなく、VCS運用の基本ではないか。 Git、Mercurialとも基本機能は単純だが、プロジェクト毎に方法論を確立している。 Bazaarはオープンソースでの実績があまりにも乏しいのもあって、方法論が確立しているように見えない。 69 名前：methane mailto:sage [2011/01/27(木) 09:35:19 ] >>66 だから **俺は** って言ってるじゃん。別にbzrがgit,hgより優れてるなんて言ってないよ。 **俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て 「これブランチだっけ？」なんて考えないし、そもそもコミットしてないデバッグ目的の変更や、 addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って そこに残しているの。 bzrならこんな使い方もできるというだけで、一般的にこの方法が優れているなんて思ってないし、 bzrもこの使い方を強制しているわけじゃない。 >>67 自分がpushできるブランチ >>68 個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき ワークフローか？個人が便利に使えたらそれで良いじゃん。 70 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:40:39 ] >>69 > >>68 > 個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき > ワークフローか？個人が便利に使えたらそれで良いじゃん。 bzrは個人でしか使えないという認識で良いのですね？ 71 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:41:55 ] なんか煽るだけしかできない奴が張り付いてるな 72 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:42:12 ] お前らってホント色んなネタで宗教戦争できるのな 73 名前：methane mailto:sage [2011/01/27(木) 09:44:07 ] >>70 そもそもこの議論の発端が俺の 「ブランチがディレクトリにひもづく」 発言なんだから、 最初からローカル作業の話なんだけど？ 開発サイトでのブランチの管理と、ローカルでの作業ツリー＋ブランチの管理は別物。 74 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 09:49:59 ] methaneたんﾍﾟﾛﾍﾟﾛ 75 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:00:45 ] >>69 > そもそもコミットしてないデバッグ目的の変更や、 > addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って > そこに残しているの。 Subversionの欠点をそのまま踏襲しているのか？ 76 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:20:06 ] >>69 >**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て GitやMercurialと比較して、Bazaarは運用にmethane氏のようなコツがいるわけだね。 77 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:23:16 ] なんで普通に読めばbzrの不便な点が書いてあるだけなのに、それを個人に対する批判と捉えちゃうんだろう 78 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:30:24 ] Twitterでやれ 79 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 11:01:41 ] >>77 bzr特有の概念の「ブランチ」をあたかも普遍的な概念としていて、 誰も理解できないことを書いているのだから、批判と捉えても仕方がない 80 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 11:04:12 ] 話がかみ合ってなくないか 81 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:03:18 ] >56 > 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を > 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） svnでrepo/projectname/trunkをチェックアウトするのではなく、 repo/projectnameをチェックアウトしてたって事？ 変わった使い方だな。 82 名前：methane mailto:sage [2011/01/27(木) 12:19:23 ] >>81 project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo をそれぞれ並列にチェックアウトして作業したい事ってない？ 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。 というかこれもう完全にbzrの話じゃないよね。 hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。 83 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:24:13 ] >82 > hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。 いや、あんたがsvn, bzrの特徴として言い出したんだが。 84 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:41:23 ] >>82 > project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo > をそれぞれ並列にチェックアウトして作業したい事ってない？ > 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。 hgは同じファイルシステムだとリポジトリはハードリンクだからコストがかからなし、 gitもhgもcheckoutで切り替えればいいだけ わざわざ全部チェックアウトするメリットは？ 85 名前：methane mailto:sage [2011/01/27(木) 12:41:47 ] >>83 単に、ブランチごとに作業ツリー作るのが楽と感じる人もいるんだよという ことが言いたかっただけなんだが、 >>56 を見るとそれが bzr の特徴って 思われても仕方ないな。すまん。 86 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:50:52 ] >>81 > svnでrepo/projectname/trunkをチェックアウトするのではなく、 > repo/projectnameをチェックアウトしてたって事？ > 変わった使い方だな。 なるほど、bzrは"svn switch"も簡単にできないから全部チェックアウトする必要があるのか 87 名前：methane mailto:sage [2011/01/27(木) 12:53:10 ] >>84 だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で 持っておきたい場合があるんだって。 コミットしない変更とか、バージョン管理下に無いテストデータとか、 色々なゴミファイルが作業ツリー配下にできるから。 別に git stash; git checkout; とかでも良いんだけど、ファイルシステム上に 合った方がテキストエディタで開くにもgrepするにも何かと便利だったりするんだよ。 というかこれもう完全にバージョン管理ツールの話じゃなくて個人の 作業スタイルの話だからやめようぜ。 88 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:54:05 ] Mercurialは、BazaarやGitとはちょっと違う。ブランチもまとめてclone/push/pullになる。 89 名前：methane mailto:sage [2011/01/27(木) 12:55:07 ] >>86 bzr switch そのものズバリのコマンドがある。 90 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:59:49 ] >>87 > だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で > 持っておきたい場合があるんだって。 > コミットしない変更とか、バージョン管理下に無いテストデータとか、 > 色々なゴミファイルが作業ツリー配下にできるから。 分散型で「コミットしない変更とか、バージョン管理下に無いテストデータとか」が 発生すること自体が理解できないのだが MercurialのMQや"git merge --squash"のような機能が無いってことなのか？ 91 名前：methane mailto:sage [2011/01/27(木) 13:22:14 ] >>90 違う違う、 cd 1.1; ./foo --test > test.result; cd .. cd 1.2; ./foo --test > test.result; cd .. diff -u 1.1/test.result 1.2/test.result とか、あとは勝手に入れてコミットには絶対含めないprintfデバッグ用 コードとか、ローカルで動かすための設定ファイルetcetc... 最初から最後まで一切バージョン管理には含めないゴミだけど 作業中は残しておきたいファイルだよ。 もちろんそういったデータを管理するためのプラグインもある(pipeline) んだけど管理するよりディレクトリ分けた方が楽だと思ってるから 分けてるだけ。 だからもうこの話もうやめようぜ。 俺は作業ツリーを複数持ちたいからそうしているだけなのに、 なんでいちいちbzrの機能不足という事に繋げようとするのかねぇ。 bzrが使いにくくないと何か困ることがあるんだろうか？ 92 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 13:26:28 ] > bzrが使いにくくないと何か困ることがあるんだろうか？ Bazaarが使いづらいと、指摘している人が多いだけ。 このスレだと、比較分析されて当然。 93 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 13:36:04 ] >>91 > >>90 > 違う違う、 > > cd 1.1; ./foo --test > test.result; cd .. > cd 1.2; ./foo --test > test.result; cd .. > diff -u 1.1/test.result 1.2/test.result > > とか、あとは勝手に入れてコミットには絶対含めないprintfデバッグ用 > コードとか、ローカルで動かすための設定ファイルetcetc... > 最初から最後まで一切バージョン管理には含めないゴミだけど > 作業中は残しておきたいファイルだよ。 これこそMercurialのMQの目的なのだが。 gitにも輸出されているそうだし。 94 名前：methane mailto:sage [2011/01/27(木) 13:49:43 ] >>93 うん、だから、 > もちろんそういったデータを管理するためのプラグインもある(pipeline) > んだけど管理するよりディレクトリ分けた方が楽だと思ってるから > 分けてるだけ。 って言ってる。 作業ツリーを分けるのは僕が楽と思ってるスタイルであって、別にbzrが推奨 しているわけではないし、bzrの機能不足で仕方なくこのスタイルをとっている わけでもない。 ディレクトリを分けるのが面倒という意見に対する反例としてディレクトリを 分けるのが楽と感じる人もいるんだよという意味で自分のスタイルを紹介した だけで、別にこれがbzrのスタイルではない。 bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では どのスタイルも推奨していない。 が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、 bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる 可能性が高い。 95 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 13:51:58 ] 自由度の高さがわかりづらさを助長してる部分はあるよね、Bazaar。 といいつつ愛用しているけれど。 96 名前：デフォルトの名無しさん [2011/01/27(木) 15:24:29 ] bzr init --append-revisions-only したリポジトリに対して pull をすると、以下のようにでる。 No revisions to pull. しかし、push しようとすると、以下のようになる。 bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/var/tmp/bazaar/trunc/". これ、もしかしてuncommitして編集しなおさないとpush不可能？ 不便すぎない？ Bazaarの--append-revisions-onlyを使っている人いるの？ 97 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 15:51:15 ] Bazaarは色物だな。 98 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 15:53:11 ] >>56 > （作業中のブランチを数か月放置して復帰するときにやりかけの > 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を > 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） これって、Trac/Redmineを使えば良いだけでは？ 99 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 16:39:14 ] >>94 > bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では > どのスタイルも推奨していない。 > が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、 > bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる > 可能性が高い。 Bazaarの言う自由度の高さとGitのこれとは何が違うの？ Pro Git 5.1 Git での分散作業 分散作業の流れ progit.org/book/ja/ch5-1.html 100 名前：methane mailto:sage [2011/01/27(木) 16:45:30 ] >>96 branch, merge, push で運用したいなら、 append-revisions-only は設定しちゃだめ。 例えば github のグラフとか見ると、 push したら一番上のラインがゴソっと入れ替わる ことがあるけど、それを防止するのが append-revisions-only だから。 append-revisions-only を使って運用したら、履歴がこういう風に、ほかのブランチのマージだけになる。 bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes bzr-colo 使わない場合は、bzr checkout example.com/repo/trunk; cd trunk; して、 bzr merge ../my_own_branch; bzr commit; のように、「trunkがローカルブランチを取り込む」 ようにしないといけない。 大規模プロジェクトでは、この trunk に merge して commit は、限られたコミッタが 手動でやるか、PQMみたいなシステムが自動的にレビューが完了したブランチを取り込む。 TortoiseBZR の開発では、細かい修正は直接 trunk の checkout 上でやってしまっている。 bzr-colo を使って作業ツリー1つでローカルブランチ使いたい場合は、多分こんな感じになる。 bzr colo-ify --trunk-name=local # (初回のみ)colo化して、今のブランチを local という名前にする bzr branch example.com/repo/trunk colo:upstream --bind # (初回のみ)trunkを upstream という名前で持ってくる bzr switch colo:upstream bzr merge colo:local bzr commit -m "Add XXX feature." 2回目以降は、bzr switch, bzr merge, bzr commit で良くなる。 ただし、coloは常用してないので嘘ついてるかも。後でやってみる。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef