1 :デフォルトの名無しさん:2011/02/15(火) 02:28:03
分散型で多言語対応のバージョン管理システム Bazaar (bzr) のスレです。

■本家
http://bazaar.canonical.com/en/
■チュートリアル
http://doc.bazaar.canonical.com/latest/ja/mini-tutorial/index.html
■ユーザーズガイド
http://doc.bazaar.canonical.com/latest/ja/user-guide/index.html

【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/

12 :デフォルトの名無しさん:2011/02/16(水) 23:46:07
Bazaarでござ~る。猿でもできる分散バージョン管理“超”入門 (1/4) - @IT
http://www.atmarkit.co.jp/fjava/rensai4/devtool20/devtool20_1.html

167 :デフォルトの名無しさん:2011/03/16(水) 07:46:32.48
https://launchpad.net/bzr/+download
bzr-2.3.1-1-setup.exe Downloads 19
bzr-2.3.0-0-setup.exe Downloads 11,192

http://code.google.com/p/tortoisegit/downloads/list
Tortoisegit-1.6.5.0-64bit.msi 8317
Tortoisegit-1.6.5.0-32bit.msi 9478

https://bitbucket.org/tortoisehg/thg/downloads
tortoisehg-2.0.2-hg-1.8.1-x64.msi 4765 times
tortoisehg-2.0.2-hg-1.8.1-x86.msi 4465 times
tortoisehg-2.0.0-hg-1.8-x64.msi 10424 times
tortoisehg-2.0.0-hg-1.8-x86.msi 9772 times

225 :methane:2011/03/25(金) 00:41:31.87
bzrの開発者にはPythonのコミッタもいるからね。
Mercurial のすばらしさの勉強会というか、単にモデルの整理をしているだけで
Mercurial より git がいい部分も語られてるから、 bzr-colo がデフォルトに
なるときには Mercurial と git のいいとこ取りになると思うよ。

226 :デフォルトの名無しさん:2011/03/25(金) 09:28:01.15
>>225
gitの良い所はhgがすでに取り込んでいる。
gitのブランチに相当するものはhgではbookmarkというものだが、
1.7までは本体にバンドルされている拡張だったのが、
1.8ではコア機能になった。

hgの名前付きブランチに相当するものはgitには無い。

gitのブランチは利点もあるが欠点もある。
利点はローカルブランチを気軽に作れて消せること。
欠点はリモートブランチを意図的にせよ事故にせよ消せること。
この事故によるリモートブランチの削除が
google codeがgitでなくhgを選んだ理由。

227 :methane:2011/03/25(金) 10:14:51.48
>>226
> google codeがgitでなくhgを選んだ理由。
リポジトリフォーマットの BigTable への対応させやすさと、
選択時に http 経由のプロトコルが一番よくサポートされていたのが
hg だったからという理由だと思うけど?

Alex が git の remote mirror ブランチのスタイルは hg のスタイルよりも
好きだっていってるけど、僕も同意する。
bzr 使うときも、 local の作業用 branch と remote からの checkout (コミットが
リモートに対して行われる)を使ってブランチを管理している。

237 :デフォルトの名無しさん:2011/03/25(金) 16:08:32.94
>>227
> Alex が git の remote mirror ブランチのスタイルは hg のスタイルよりも
> 好きだっていってるけど、僕も同意する。
どこに書いてある?

目に見えて流量の減っているbzrのMLが活況ついていると思ったら、
hgの主要コミッタとhgを使っているXEmacsの人が投稿しているのか。

238 :methane:2011/03/25(金) 18:10:08.07
>>237
https://lists.ubuntu.com/archives/bazaar/2011q1/071988.html

239 :デフォルトの名無しさん:2011/03/25(金) 18:40:18.64
>>238
> The hg model of named branches seems very rigid and fragile, I saw many
> criticism on it. Anonymous heads idea is also contradicts to bzr branch
> model, I really do think names are important, but names should not be
> immutable.

だから、これはhgの名前付きブランチのコストが高いという問題があって、
gitのブランチ相当のhgのbookmarkが1.8からコアに含まれたということを、
bzrの人々が知っていないってこと。

CPythonの2.7、3.2という名前付きブランチは、svnからの移行ということで、
もっと具体的に言うと、hgsubversionで変換したから、そうなっているってこと。

CPythonは、2.xと3.xを同時にメンテナンスしなければならないという特殊なアプリ。

CPythonの名前付きブランチの方針はここに書かれている。
http://www.python.org/dev/peps/pep-0385/

240 :デフォルトの名無しさん:2011/03/25(金) 18:48:05.18
bzr-colo入れるよりリポジトリに対してコマンドを受け付けるようにした方がいいようなきがする

241 :methane:2011/03/25(金) 20:08:31.58
>>239
>>227 で言ってたのはその部分じゃなくて、その1つ上の段落。

> I like git model more than hg model. As I understand it, in git you have
> origin/master as pristine mirror and just master for your development.
> The separation between remote branches and local branches can be very
> useful. Actually bzr-colo patially adapted this model.

ちなみに、 bzr-colo の場合、ミラーは bound branch になるから常に
リモートと同期され、

bzr switch colo:upstream-trunk
bzr merge colo:my-feature
bzr commit

ってしたら、直接リモートにコミットされる。他の人が先にコミットしたら
commit が失敗するから、 merge commit push(失敗) pull merge commit ではなく、
merge commit(失敗) update commit になり、最終的に履歴は1回のマージの
コミットだけで済む。

>>240
具体的に教えて。

243 :デフォルトの名無しさん:2011/03/25(金) 20:16:36.69
>>241
gitのremote/masterとローカルのmasterには基本的には関連は無い。
remote/masterが他の人が更新していれば、git push masterは失敗する。
でもgit push master:hogehogeとやればpushはできる。
これはhgの場合、リモートに無名ブランチ=ヘッドが新しくできる状態。
hgの無名ブランチとgitのブランチは同等。
だから、bzrの人のgitとhgの理解が足りない。

244 :methane:2011/03/25(金) 21:03:06.59
>>243
「ちなみに」以下の部分は僕が bzr と git の違いについて勝手に補足しただけで、
もとのMLの人もその違いはちゃんと認識していると思うよ。

245 :デフォルトの名無しさん:2011/03/25(金) 21:42:13.24
>>244
"As I understand it, in git you have origin/master as pristine mirror"が勘違い。
gitはcloneして特に設定を変えなければ、
pullしたとき、fast forwardが可能な場合、勝手にマージされるからそう勘違いされる。
hgはpullしても勝手にはマージされない。

http://mercurial.selenic.com/wiki/GitConcepts
にある通り、
git pull = hg fetch
git fetch = hg pull

247 :methane:2011/03/26(土) 00:01:49.17
>>245
別に勘違いしてるわけじゃないと思うけどな。
fastforward 云々以前に、 checkout して commit してもまた
origin/master に push しないといけないことくらい基礎だし。

というか、もし勘違いしていたとして、だから何?

249 :デフォルトの名無しさん:2011/03/26(土) 07:42:08.77
>>247
"I like git model more than hg model."のあとがこの人の勝手な解釈で、
hgの主要コミッタからhgの名前付きブランチについての指導が入っている。
だから、この人はこの時点で何も分かっていない。

さらにそれを引き合いにして「同意する」なんて書いているのは無知の上乗せ。

250 :methane:2011/03/26(土) 11:24:22.57
>>249
> "I like git model more than hg model."のあとがこの人の勝手な解釈で、
> hgの主要コミッタからhgの名前付きブランチについての指導が入っている。
> だから、この人はこの時点で何も分かっていない。

この段落に対する返信なんて無いけど?
この後に始まる Mercurial 開発者による名前付きブランチの話は
https://lists.ubuntu.com/archives/bazaar/2011q1/071985.html
Alexに対する返信じゃなくてMartinに対するものだし、
「お前のMercurialに対する理解は間違ってるぞ」じゃなくて、
「Bazaar が colo 相当の機能をコアに入れるなら Mercurial の
モデルを参考にしてみたら?」ていう程度の話。


> さらにそれを引き合いにして「同意する」なんて書いているのは無知の上乗せ。

結局、俺やBazaar開発者が無知なバカだって見下したいだけ?
俺が Mercurial に対して無知なのは認めるよ。Bazaar開発陣も、
全員が Mercurial に精通しているわけじゃないかもね。
はい、おしまい。

426 :methane:2011/04/29(金) 23:42:20.91
MLでコマンドラインのi18nが話題になってたから、TortoiseBZRや
Mercurialの仕組みを流用して基本部分だけ作ってみた。
うまく行けば bzr 2.4 には入りそう。

443 :デフォルトの名無しさん:2011/05/02(月) 22:10:23.96
>>426
ファイル名がロケールに依存するという間違った設計のため、まともな実装が出来ないのであった。

445 :methane:2011/05/02(月) 22:24:07.05
>>443
ヘルプテキストやメッセージを翻訳するのとファイル名がどう関係するの?
僕が試しに作ったi18n機能は、LANG=ja_JP.eucJPな人には翻訳メッセージは
ファイル名と同じくEUC-JPで表示するし、これで問題ないと思うんだが。

446 :デフォルトの名無しさん:2011/05/02(月) 22:29:43.75
>>445
methaneさんよ。いい加減スルーを覚えましょう

447 :デフォルトの名無しさん:2011/05/02(月) 22:30:07.52
>>445
https://lists.ubuntu.com/archives/bazaar/2011q2/072310.html

448 :デフォルトの名無しさん:2011/05/02(月) 22:31:58.83
>>445
BZR_USERENCODINGという環境変数がファイルをチェックアウトしたロケールと違った場合、
文字コードは何を出力すべきなのでしょうか?

449 :デフォルトの名無しさん:2011/05/02(月) 22:38:11.66
>>445
~/.bzr.logも複数の文字コードが混在する可能性があります。
さて、文字コードは何を指定すべきでしょうか?

451 :methane:2011/05/03(火) 00:16:26.67
>>446
スルーばかりしてたら本当の問題報告を見逃してしまうかもしれないので、、、
>>447
それって全然i18nの実装と関係ない話だよね?
もちろん、ロケールが登録されてないサーバーで使えるようになるのはいい事だけど、
ロケール登録されてないって結構レアケースだし、困っている人どれくらいいるんだろ?
ウチの会社はbzrインストールしているサーバーではロケールを登録した。
>>448
ファイルシステムエンコーディングと出力エンコーディングは別。
ロケールがeuc-jpでチェックアウトして、出力エンコーディングをUTF-8にしたら、
標準出力に出力されるファイル名はUTF-8になる。
そもそもそこら辺はオフトピックで、i18nの実装に絡む部分じゃない。
>>449
.bzr.log の中は出力エンコーディングは無関係でutf-8固定

452 :デフォルトの名無しさん:2011/05/03(火) 01:10:12.21
>>451
> それって全然i18nの実装と関係ない話だよね?

全角半角は関係ないのでしょうか?

> ロケールが登録されてないサーバー

マシンのロケール(/etc/sysconfig/i18n)とログインシェル(~/.profile)は別。
LANG=en_US.ISO-8859-1のロケールのコンソールで日本語のログメッセージはどうやって読むのでしょう?

> ファイルシステムエンコーディングと出力エンコーディングは別。
> ロケールがeuc-jpでチェックアウトして、出力エンコーディングをUTF-8にしたら、
> 標準出力に出力されるファイル名はUTF-8になる。

あれ?MLではWindowsでchcp 65001が効かないってあったけど?

453 :methane:2011/05/03(火) 01:21:52.72
>>452
>全角半角は関係ないのでしょうか?
はい、関係ありません。

>> ロケールが登録されていないサーバー
> マシンのロケール(/etc/sysconfig/i18n)とログインシェル(~/.profile)は別。
ロケールが登録されていないっていうのは、そもそも /usr/share/locale 自体が
スッカラカンで、LANGに何を設定してもutf-8のロケールにできない状況だから、
マシンのロケールとログインシェル以前の問題。

> LANG=en_US.ISO-8859-1のロケールのコンソールで日本語のログメッセージはどうやって読むのでしょう?
LANG=en_US.utf-8 bzr log とか。
で、いちいちそれをするのが面倒だったり、utf-8なロケールが一切存在しない
場合に困るから、BZR_USERENCODINGとか、 --encoding オプションができたら
良いねというのがMLで言ってた話題。

> あれ?MLではWindowsでchcp 65001が効かないってあったけど?
どの話題のことだろう?
今まで話してたのは基本的にUnix系の話題の話で、Windowsでは言語設定にかかわらず
ファイルパスは全部W系APIを使ってUnicodeで扱うから、チェックアウト時と違う
言語設定にしてもファイルパスには全く影響ない。

454 :デフォルトの名無しさん:2011/05/03(火) 01:45:19.01
>>453
> >全角半角は関係ないのでしょうか?
> はい、関係ありません。

Mercurialをパクるなら全て正しくパクりましょう。

> > あれ?MLではWindowsでchcp 65001が効かないってあったけど?
> どの話題のことだろう?
> 今まで話してたのは基本的にUnix系の話題の話で、Windowsでは言語設定にかかわらず
> ファイルパスは全部W系APIを使ってUnicodeで扱うから、チェックアウト時と違う
> 言語設定にしてもファイルパスには全く影響ない。

https://lists.ubuntu.com/archives/bazaar/2011q2/072308.html

455 :methane:2011/05/03(火) 02:12:42.31
>>454
> Mercurialをパクるなら全て正しくパクりましょう。
意味不明。

で、そのMLの話題が、
>> ファイルシステムエンコーディングと出力エンコーディングは別。
>> ロケールがeuc-jpでチェックアウトして、出力エンコーディングをUTF-8にしたら、
>> 標準出力に出力されるファイル名はUTF-8になる。
> あれ?MLではWindowsでchcp 65001が効かないってあったけど?
これに繋がるのは、出力エンコーディングをUTF-8にする=chcp65001、という認識だったんですね。
そのメールにあるとおり、chcp 65001してもcp65001がUTF-8だと判別出来ていないので、
出力エンコーディングはUTF-8になっていません。
sitecustomize.pyなどでエイリアスを登録すればいけるかもしれませんが、
bzr 自体はWindowsで出力エンコーディングをUTF-8にする有効な手段を提供して
いないので、このオプションなり環境変数が導入されるといいですね。

457 :デフォルトの名無しさん:2011/05/03(火) 06:42:34.26
>>455
> >>454
> > Mercurialをパクるなら全て正しくパクりましょう。
> 意味不明。

MBCS 文字列の折り返し - その 1
http://d.hatena.ne.jp/flying-foozy/20100515/1273916524


459 :methane:2011/05/03(火) 10:48:03.78
>>457
i18nと折り返し機能は別物。

bzrは自動折り返しとかしてなくて、もとのヘルプメッセージが折り返されている
だけなので対策不要と思ってたけど、よく考えたら help commands が折り返し
してるからここで対策必要だったわ。さんくす。
bzr はそもそも mbcs じゃなくて unicode で扱うつもりだから対策も楽だな。

461 :デフォルトの名無しさん:2011/05/03(火) 10:57:42.48
>>459
> bzr はそもそも mbcs じゃなくて unicode で扱うつもりだから対策も楽だな。

空白詰めと符号化方式
http://d.hatena.ne.jp/flying-foozy/20100703/1278170570

> 更に崩れた表示に目を凝らしてみると....値表示が必要なオプションの表示の際に、
> 値の翻訳文字列の文字数に応じてカラムがずれているっぽい気が....
>
> わかった!オプション説明文の字下げ幅算出は、オプション表示部分
> (例: "-I --include パターン [+]" 部分)の文字列に対して単純に len() を適用しているのだけど、
> UTF-8 の日本語文字はバイト数≠文字数だから、Python の len() による算出だと駄目なんだ!


464 :methane:2011/05/03(火) 11:11:53.63
>>461
いや、それくらいちゃんと解ってるから。
Unicode で扱うから楽っていうのは、
http://d.hatena.ne.jp/dayflower/20100212/1265960099
にある TextWrapper だとバイト文字列が渡された時もわざわざ
Unicodeにデコードしてから処理してエンコードしているけど、
bzrの場合はバイト文字列が来た場合はそもそもコマンド名などの
US-ASCII文字だって仮定できるので、入力がUnicodeのときだけ
対応すれば良いから楽だってこと。

517 :デフォルトの名無しさん:2011/05/21(土) 05:49:28.08
bzr-gitやdocdiffをpluginとしてBazaarに入れ込もうとしたときに
会社のXPだとうまくBazaar Explorerが認識しましたが、
家のWindows7(64bit)だとうまくいきません。
同じような現象の方いらっしゃいますか?どのように解決しましたか?
原因はWindows7だから?それとも64bitだから?

518 :デフォルトの名無しさん:2011/05/21(土) 06:51:48.73
>>517
認識しないというのはBazaar ExplorerのBazaarメニュー>プラグインで
インストールしたプラグインが表示されないというのであっていますでしょうか?
BZR_HOMEを設定してそちらにプラグインを入れてみては?
プラグインを置くディレクトリは %BZR_HOME%\.bazaar\bazaar\2.0\plugins
になります

733 :デフォルトの名無しさん:2011/11/26(土) 23:26:40.60
Windows Server で簡単に(インストーラでインストールするだけで)
 Bazaarのサーバーを構築する方法ってありますか?

734 :デフォルトの名無しさん:2011/11/27(日) 12:10:50.78
なんのこっちゃ。単にフォルダ共有しとけばいいんじゃないか?

811 :デフォルトの名無しさん:2012/01/03(火) 21:41:14.84
つまらん質問で悪いが教えてくれ
次のように理解したんだがあってる?
1. 「checkout と branch の違いは単に bind されてるかどうかだけで、これはあとからでも適宜いじれる」
2. 「checkout に commit するとローカルとリモートの両方に適用され、branch に commit するとローカルのみに適用される」

812 :デフォルトの名無しさん:2012/01/03(火) 21:56:20.30
>>811
本当は怖い軽量チェックアウトの話
http://d.hatena.ne.jp/methane/20111223/1324637451

813 :デフォルトの名無しさん:2012/01/03(火) 22:28:39.14
>>812
ありがとう
一つ手前の、チェックアウトとブランチの使い分け と合わせて読んで、
なんとかわかったような気になった

git は commit しないまま branch をまたいだ作業しにくくて、
作業コピーが branch ごとに独立してる bzr のが自分の運用に合ってるんだけど、
bzr は公式ドキュメントのほとんどが理由不明のノウハウ集ばっかりなのが辛い…

「そーゆーのがしたい時はこーゆーコマンドを打てばいいよ」と言われても困るというか
「このコマンドはこれに対してこのような操作を行う」というのが明示されてたらいいんだけど

872 :デフォルトの名無しさん:2012/03/07(水) 23:49:23.33
すいませんけど困ってることがあるので教えて下さい
SubversionもBazaarも勉強を始めたばかりで詳しくありません(´・ω・`)

Subversionで管理されていたソースコードを持ってきて(チェックアウトではなく)、
そのソースコードをBazaarで管理して修正を始めました。

このBazaarで管理を始めたソースコードを元のSubversionの履歴とつなげることってできますかね(´・ω・`)

例えば持ってきた時点でSubversionの中でリビジョン100、
Bazaarに突っ込んだ時点で、Bazaarの中でリビジョン1から始まってるわけですけど、
これを元のSubversionの101からの履歴にできますかね(´・ω・`)

元のSubversionのリポジトリは捨ててもいいので、
今後はBazaarで管理して、かつてのSubversionの1~100をBazaarに持ってきて、
今回の101~をつなげられるなら、そうしてもいいのですが。

Bazaarで無理なら、gitでもMercurialでも構いません。


http://toro.2ch.net/test/read.cgi/tech/1297704483/l50/../人気ブログランキングへ