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

1 ：11/01/20

バージョン管理システムについて語りましょう
●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/
バージョン管理システムについて語るスレ7
http://hibari.2ch.net/test/read.cgi/tech/1283780922/

2 ：11/01/20

●関連スレ
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1254838551/
Git 2 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1284467898/
【分散型バージョン管理】 Mercurial 【hg】
http://hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/

3 ：11/01/20

●関連サイト
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 ：11/01/20

立てました。

5 ：11/01/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 ：11/01/20

5. GUIやEclipseでの利用を重視しますか？
　│
　├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
　↓
6. シンプルな操作がお好みですか？
　│
　├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
　↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。
（チェンジセット: 4:ae4c01d241ab）

7 ：11/01/20

811 名前：デフォルトの名無しさん [sage]： 2011/01/01(土) 17:45:53
皆様のレスを読んだ上で、再度、大雑把に特性をまとめてみた。
Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・分岐時は、無名ブランチが自動で切られる。名前付ブランチもつくる事ができるが、目印なので必須では無い。
・ブランチ内のチェンジセットは木構造に並ぶ。
・分岐したブランチは、元のブランチに依存する。あるブランチ内のチェンジセットを消すと、別のブランチにある子孫チェンジセットも消える。
・複数のリポジトリで変更を行いpushしても、分岐しているので衝突はしない。ただし、解消が要求されるmulti-head状態になるので、先にpullが望ましい。
Git:
・一つのリポジトリで複数のブランチが扱える。
・分岐時に、ブランチ名を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のリポジトリで変更を行いpushすると、衝突が発生する。先にpullが必要。
Bazaar:
・ブランチだけで運用を行える。リポジトリを作ると、複数ブランチでデータを共有して省スペース、ブランチ作成などの高速化ができる。
・分岐時に、ブランチのディレクトリ配置を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・マージするときは、自分のリポジトリのコミットをメインライン、他のリポジトリのを傍流として記録。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のブランチで変更を行いpush/pullすると、衝突が発生する。先にpullが必要。

8 ：11/01/20

589 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:31:11
お前らこの「svnが遭遇してきた問題点とその解決策」を共有したいのでどこに記述あるか教えてください
【bzr】Bazaarでバージョン管理 Rev 2
http://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
こっちでいいじゃん
http://d.hatena.ne.jp/hnw/20081024
592 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:42:16
ここも
http://www23.atwiki.jp/selflearn/pages/55.html
593 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:44:57
あとここ
http://hibari.2ch.net/test/read.cgi/tech/1251208950/466-474

9 ：11/01/20

MacHgがなかなか良い。

10 ：11/01/20

749 名前：デフォルトの名無しさん [sage]： 2010/12/30(木) 19:23:52
append_revisions_only
“True”に設定されていればリビジョンはログにのみ追加され、削除されません。
この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。
通常これは bzr init --append-revisions-only によって設定されます。
http://twitter.com/#!/methane/status/11806331434442752
append_revisions_only = True に設定したブランチでは、連番のリビジョン番号が固定され、ID替わりに使えること。
中央リポジトリ上のブランチはこの設定がおすすめ。

11 ：11/01/20

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 ：11/01/20

そろそろ、zipを超えるバージョン管理システムがでるかな？

13 ：11/01/20

それならzipよりもmkdirっていうバージョン管理システムの方がずっと強い

14 ：11/01/20

しばらく見てなかったけどJGitが、結構使えるようになってるな。
JVM上で動くので、WindowsやLinuxでも、UTF-8環境の native Gitとでも
日本語ファイル名も含めて今のところ相互運用に問題は無い。
まだ実装されてない機能もあるし、GUIで扱うなら eclipse のEGit plug-in
に頼らないといけないところが難点。EGit の UI は悪くないけどね。

15 ：11/01/20

20110120最新-2.zip みたいな悪夢見さすな。

16 ：11/01/21

インストールすると自動的にhomeに公開、ダウンロード、音楽、ビデオ、デスクトップ、
文書、テンプレート、画像、なんてディレクトリが作られちゃうんで是非ともutf8のマルチ
バイト文字列のファイル・ディレクトリ名をきちんと操作・バージョン管理できるよう、おな
がいします。

17 ：11/01/21

他人と共同作業じゃなくて、自分用のバックアップ目的で使うには、Bazaarが最強との結論に達した。

18 ：11/01/21

俺は個人で使うのはgit、他人と共同作業で使わせるのはbzrという結論になった
本当は一つにしたかったし、もし無理矢理一つにするんだったらhgを選んだろうけど

19 ：11/01/21

前スレでTeam Foundation Server使用したことある人がいたようなので
使用感はどんな感じか聞いてみたい。
特に大きなリソースを扱うプロジェクトでのパフォーマンスなど。
Perforceの対抗馬になるようなら嬉しいんだけど

20 ：11/01/21

>>19
それを書いたのは俺だが……すまん、実務ではまだ使ってないんよ。今年中にはVSSからの移行先としてTFS2010を評価する予定だけど。
まだホワイトペーパー（http://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 ：11/01/22

sshの公開鍵をくださいと言ったら、秘密鍵と公開鍵の両方がメールで送られてきた。
BASIC認証でしか運用ができないので、Gitではなく、hgwebがあるMercurialを採用することにした。

22 ：11/01/24

TracやRedmineを併用している？

23 ：11/01/25

>>8
http://svn.apache.org/viewvc/subversion/trunk/notes/unicode-composition-for-filenames?view=markup
ちなみに、2月リリースのbzr-2.3のベータ版ではもう直ってるっぽい。

24 ：11/01/26

>>23
これで「社会が憎い.properties」が使えるわけですね。

25 ：11/01/26

>>23-24
誰得アプリに磨きがかかったのですね

26 ：11/01/26

>>25
リポジトリの構造や、ブランチ操作の手軽さはMercurialの方が優位だと思うが、弊社の以下の状況はBazaar優位になっています。
・PM佐藤は「英語わからんし」とつぶやいて、日本語ファイル名を作る。
・PG田中はマカーなので、Windowsは手が汚れると言って触りもしない。
・PG茶谷はLinuxでvimを使うことだけがアイデンティティ。
・ﾃﾞｻﾞｲﾅ鈴木はWindows以外は分からないと言って、Macintosh OS Xを直視もしない。

27 ：11/01/26

全員クビにしろよ

28 ：11/01/26

>>26
リポジトリの構造ってMercurial優位だっけ？
bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
いつの間にか新しいリポジトリフォーマットが出てきてたのかな。

29 ：11/01/26

>>28
表現方法が悪いのかも知れないけど、以下の理由でMercurialの方が優位だと思う。
・チェンジセットの関係が木構造で操作が直感的。
・名前無しブランチがあるので、ブランチを作るのが容易。
・名前付ブランチも、まとめてpush/pullできる。
GitもBazaarもブランチは直線的で、分岐するのには操作がいる。clone、push、pullもブランチ単位。
特にBazaarは、ブランチの扱いでディレクトリ配置を意識する必要がある。

30 ：11/01/26

>>29
あぁ、 .bzr とか .hg 内部のファイル／データ構造という意味じゃないのね＞リポジトリの構造
そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。

31 ：11/01/26

>>28
> bzrの方がファイル数少なくて容量小さいし、
hgはコピーをサポートしていて、ファイルの移動はコピーと削除だから
大幅にディレクトリ構成を変更した場合、必然的にリポジトリがでかくなる。
あまりにも大幅な構成の変更の場合、convertをした方が良い
bzrはコピーをサポートしている？
FATの場合、でかいファイルの方がフラグメントやらで都合が悪くない？
gitの場合、packするしないはユーザの自由だが、bzrは勝手にパックしちゃうのか？
> やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
cygwin
あと、例の拡張
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
進化している
マイナーチェンジで基本は全く変わっていないけど

32 ：11/01/26

>>31
bzrはコピーは今はサポートしていない。
代わりに、移動はサポートしていて移動しても容量は増えない。
FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
パックは10、100、1000コミットごとに自動で行われる。
>cygwin
>あと、例の拡張
Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
例の拡張ってなんだろう？

33 ：11/01/26

>>32
> >>31
> bzrはコピーは今はサポートしていない。
> 代わりに、移動はサポートしていて移動しても容量は増えない。
>
> FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
> ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
> パックは10、100、1000コミットごとに自動で行われる。
2GB制限は？
> >cygwin
> >あと、例の拡張
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
> 例の拡張ってなんだろう？
当然知っているでしょ？
MAX_PATHのことを言っているんでしょ？
ANSI APIを使うという方針なんだから仕方がない。
それを横取りしている拡張

34 ：11/01/26

>>33
bzr関連のブランチを格納しまくってるshared repositoryの中をのぞいてみたら、
pack数が12個で最大のものが31MBだから、ソースコード管理では2GB制限は
気にしないで良さそう。動画ファイルとか大容量のファイルの扱いは確かに苦手。
MAX_PATHはANSIとは直交した制限で、CreateFileWとか使っても同じUTF-16の
コードポイント数が制限を受ける。
この制限を回避するためには "\\?\c:\" みたいな書きかたでWin32APIのチェックを
スルーしてファイルシステムにアクセスしないといけないんだけど、これをやると
カレントディレクトリとか一切使えなくなる。
例の拡張ってのが、もしfix-utf8の事を言っているのであれば、僕が昔触ってた時は
utf8<=>utf16の変換をしていただけで、 "\\?\" は使ってなかった。

35 ：11/01/26

hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
って、これも知っているよね？
もう１つの拡張の方も横取りしている。
パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
そこがANSI APIになっている。

36 ：11/01/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 ：11/01/26

>>36の続きだが、Bazaarの「リポジトリ」もあまり良いコンセプトに思えない。
準備無しにBazaarでブランチを切ると、ディスク占有サイズが倍増する。
「リポジトリ」を作っておけば、ブランチを切っても実ファイルはシェアするが、事前準備がいる。GitやMercurialには不要な作業。
後から「リポジトリ」を使うこともできるが、移行作業はいる。

38 ：11/01/26

>>36
Git (3ステップ):
git checkout -b NewBranch 0b70750b
[編集]
git commit -m "以前のバージョンから分岐"

39 ：11/01/26

>>36
git checkout -b NewBranch 0b70750b

40 ：11/01/26

>>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 ：11/01/26

>>36-37
つbzr-colo

42 ：11/01/26

>>41
何それ？

43 ：11/01/26

>>40
> >>35
> >hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
> >って、これも知っているよね？
>
> bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を
> 用意してて、同じファイルシステムで clone した後に push / pull したら共有できない
> という制限もない。
http://foozy.bitbucket.org/hgbook-ja/d6ca1334a19d/hgbookch4.html#x27-790004.5
何人かの構成管理ツールの開発者により、この方法 完全にリポジトリ固有のものとしてファイルを複製する
が ディスク使用量削減にそれほど効果的でないとの指摘を受けています。それは事実ではありますが、
ディスク容量の 確保は安価であり、 OS への複製要求を遅延することにより高い性能を得ることができます。
別な仕組みを用いる場合、性能が低下しソフトウェアの複雑さが増しますので、
日々の利用における “体感” に非常に影響を及ぼします。
訳注: つまり、 Mercurial でのハードリンクの使用は、複製を行うことによるディスクヘッドのシークを
低減するのが主眼で、ディスク使用量の低減が主眼ではな い、ということです。

44 ：11/01/26

>>42
簡単に言えば、gitみたいな名前付きブランチを実現するもの。
bzr自体は作業ツリー、ブランチ、リポジトリを分離して自由に構成できるけど、
逆に自由すぎるのが面倒なので、1リポジトリ, 複数のブランチ、1つの作業ツリーの
組み合わせを git のように扱えるようにしてくれるもの。
>>36 で言えば、
bzr colo-branch -r30 NewBranch
の1ステップになる（現在のブランチ=OldBranchのr30からNewBranchを作って、
作業ツリーを新しいブランチのチェックアウトに切り替える）

45 ：11/01/26

>>44
> >>42
> 簡単に言えば、gitみたいな名前付きブランチを実現するもの。
　　　　　　　　　＼　　　∩─ｰ､ 　　　====
　　　　　　　　　　 ＼／　●　､_ ｀ヽ 　　======
　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　|　　 X_入__ノ 　 ミ　　　そんな餌で俺様が釣られクマ――
　　　　　　　　　　　 ､　(＿／　　　ノ　/⌒l
　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　=====
　　　　　　　　　 　 〈　　　　　　　　 ＿_ノ　　====
　　　　　　　　　　　 ＼　＼＿　　　　＼
　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　　　　　　　　　　＼　　 ＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　　　　　　　　　　 ＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ

46 ：11/01/26

誤解を恐れずに言えば、Gitにはブランチは存在しない
旧来のブランチの機能を果す何物かがあるだけ

47 ：11/01/26

mercurialの設計で一番の間違いはブランチを名前で管理できると思ったところだと思う。

48 ：11/01/27

え、じゃぁ
http://progit.org/book/ja/ch3-2.html
ここでいう 'master' ブランチ とかいうのは名前付きブランチじゃないの？
まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
なるのが bzr-colo

49 ：11/01/27

突然だけど、Meld と Diffuse ってどっちが使いやすい？
プラットホームは Linux で。ほかにも何かおすすめがあれば。

50 ：11/01/27

>>48
bzrはよく分かんないんだけど、
gitは>>46の通りで、SHA1ハッシュに対するエイリアスをブランチと呼んでいるだけで、
内部的には「ブランチを作る」という機能は無いと言っていい。
ただUIとしては「ブランチ」と特化した表現をしたほうが分かりやすいので
「ブランチを作る」というコマンドは存在する（エイリアスを作るだけのコマンド）

51 ：11/01/27

>>50
うん、で、今は内部構造じゃなくてワークフローの話をしているんだから、
>>44 の発言って別に間違ってないよね。 >>45-47 の突っ込みは気にしなくて
いいよね。

52 ：11/01/27

>>50
馬鹿なの？
ブランチの意味知らないんなら喋らないほうがいいよｗｗｗ

53 ：11/01/27

極端な例だけど下記のような分岐をした場合、各VCSはどのようにbranchを管理するでしょうか？
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿branch1
＿×＿×＿×＿×＿×＿×＿×＿branch2
×＿×＿×＿×＿×＿×＿×＿＿branch3
＿×＿×＿×＿×＿×＿×＿×＿branch4
×＿×＿×＿×＿×＿×＿×＿＿branch5

54 ：11/01/27

>>52
は？

55 ：11/01/27

MercurialやGitのようなブランチの操作をするのに、bzr-coloが必要となる時点でBazaarは使いづらい。
「ブランチ」に対するアプローチが、
・ディレクトリ名を指定
・共有リポジトリ作成後、その下にあるディレクトリ名を指定
・bzr-coloを利用
と3種類もある。
GitやMercurialはシンプルなコンセプトで実装が見えない所が、SVNに似ているので見えてしまうのがBazaarという印象が拭えない。

56 ：11/01/27

>>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 ：11/01/27

>>47
Mercurialの「名前付きブランチ」は「おまけ」
リポジトリの分離と名無しブランチでも運用可能
cvsのブランチのように消さないことを前提としている
名前付きブランチを乱発すると収集が付かなくなるからcloseする機能が後から出来た
「名前付きブランチ」と「リビジョン番号」はgitには無い

58 ：11/01/27

>>48
> まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
> なるのが bzr-colo
用語はどうでもよいから、bzrは意味不明な用語を乱発しているのか

59 ：11/01/27

>>56
> 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が
> 安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
大量のごみブランチが発生するのは害でしかない
マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
ブランチとやらがbzrの売りらしいが、
大規模コミュニティの開発では何のメリットも無い

60 ：11/01/27

>>58
いちいち突っかかるなぁ。。。
僕が git が定義している用語を知らないし興味もないってだけだよ。
gitはgithubクライアントにしか使ってないから。
bzr ではきちんと用語を定義して使い分けてるよ。
で、git で refs 以下で「コミットに対する名前による参照」を提供しているけど、
この「コミットに対する名前による参照」って git はなんて定義しているの？
「ローカルブランチ」だとブランチが存在する場所が焦点になってしまって、
hgの無名ブランチと違って「名前で参照されている」という点に焦点を当てたかったから
hgの用語を拝借して「名前付きブランチ」と呼んだんだけど。

61 ：11/01/27

>>60
ローカルブランチ、リモートブランチを勉強してから出直してきな

62 ：11/01/27

>>59
> 大量のごみブランチが発生するのは害でしかない
> マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
だからこういう個人の主観による優劣で議論する気ないんだってば。
**俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」
ってならないし、本当に要らないものを整理する気になるから好きってだけで、
別にbzrはそれを強制してないから、 >>59 が bzr を使うときには俺と違う使い方をすればいい。
> github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
意味が分からない。
リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？

63 ：11/01/27

>>60
> 僕が git が定義している用語を知らないし興味もないってだけだよ。
bzr開発者はgitに興味が無いから、bzrは使い勝手の悪い誰得アプリになってしまったのか

64 ：11/01/27

>>61
gitも一応githubクライアントとして少しは使ってるから、
ローカルブランチとリモートブランチは使ってるよ。
どちらもコミットのハッシュ値ではなくて名前で参照できるという点では、
hgでいう「名前付きブランチ」だね。
もちろん完全に同じものとは言ってないよ。

65 ：11/01/27

>>63
本当にそうなら bzr-colo なんて存在しないよ。

66 ：11/01/27

>>62
> **俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」ってならない
Gitはブランチの一覧ができる。
Mercurialはブランチやヘッドの一覧ができる。
Bazaarはディレクトリを見て、「これブランチだっけ？」と考える必要がある。
目につくところに無いのは、Bazaarとしか思えない。

67 ：11/01/27

>>62
> > github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
> 意味が分からない。
> リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？
意味が分からない
「個人所有のブランチ」って何？

68 ：11/01/27

>>62
> だからこういう個人の主観による優劣で議論する気ないんだってば。
「個人の主観」ではなく、VCS運用の基本ではないか。
Git、Mercurialとも基本機能は単純だが、プロジェクト毎に方法論を確立している。
Bazaarはオープンソースでの実績があまりにも乏しいのもあって、方法論が確立しているように見えない。

69 ：11/01/27

>>66
だから **俺は** って言ってるじゃん。別にbzrがgit,hgより優れてるなんて言ってないよ。
**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
「これブランチだっけ？」なんて考えないし、そもそもコミットしてないデバッグ目的の変更や、
addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
そこに残しているの。
bzrならこんな使い方もできるというだけで、一般的にこの方法が優れているなんて思ってないし、
bzrもこの使い方を強制しているわけじゃない。
>>67
自分がpushできるブランチ
>>68
個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
ワークフローか？個人が便利に使えたらそれで良いじゃん。

70 ：11/01/27

>>69
> >>68
> 個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
> ワークフローか？個人が便利に使えたらそれで良いじゃん。
bzrは個人でしか使えないという認識で良いのですね？

71 ：11/01/27

なんか煽るだけしかできない奴が張り付いてるな

72 ：11/01/27

お前らってホント色んなネタで宗教戦争できるのな

73 ：11/01/27

>>70
そもそもこの議論の発端が俺の 「ブランチがディレクトリにひもづく」 発言なんだから、
最初からローカル作業の話なんだけど？
開発サイトでのブランチの管理と、ローカルでの作業ツリー＋ブランチの管理は別物。

74 ：11/01/27

methaneたんﾍﾟﾛﾍﾟﾛ

75 ：11/01/27

>>69
> そもそもコミットしてないデバッグ目的の変更や、
> addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
> そこに残しているの。
Subversionの欠点をそのまま踏襲しているのか？

76 ：11/01/27

>>69
>**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
GitやMercurialと比較して、Bazaarは運用にmethane氏のようなコツがいるわけだね。

77 ：11/01/27

なんで普通に読めばbzrの不便な点が書いてあるだけなのに、それを個人に対する批判と捉えちゃうんだろう

78 ：11/01/27

Twitterでやれ

79 ：11/01/27

>>77
bzr特有の概念の「ブランチ」をあたかも普遍的な概念としていて、
誰も理解できないことを書いているのだから、批判と捉えても仕方がない

80 ：11/01/27

話がかみ合ってなくないか

81 ：11/01/27

>56
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
svnでrepo/projectname/trunkをチェックアウトするのではなく、
repo/projectnameをチェックアウトしてたって事？
変わった使い方だな。

82 ：11/01/27

>>81
project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
をそれぞれ並列にチェックアウトして作業したい事ってない？
僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
というかこれもう完全にbzrの話じゃないよね。
hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。

83 ：11/01/27

>82
> hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。
いや、あんたがsvn, bzrの特徴として言い出したんだが。

84 ：11/01/27

>>82
> project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
> をそれぞれ並列にチェックアウトして作業したい事ってない？
> 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
hgは同じファイルシステムだとリポジトリはハードリンクだからコストがかからなし、
gitもhgもcheckoutで切り替えればいいだけ
わざわざ全部チェックアウトするメリットは？

85 ：11/01/27

>>83
単に、ブランチごとに作業ツリー作るのが楽と感じる人もいるんだよという
ことが言いたかっただけなんだが、 >>56 を見るとそれが bzr の特徴って
思われても仕方ないな。すまん。

86 ：11/01/27

>>81
> svnでrepo/projectname/trunkをチェックアウトするのではなく、
> repo/projectnameをチェックアウトしてたって事？
> 変わった使い方だな。
なるほど、bzrは"svn switch"も簡単にできないから全部チェックアウトする必要があるのか

87 ：11/01/27

>>84
だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
持っておきたい場合があるんだって。
コミットしない変更とか、バージョン管理下に無いテストデータとか、
色々なゴミファイルが作業ツリー配下にできるから。
別に git stash; git checkout; とかでも良いんだけど、ファイルシステム上に
合った方がテキストエディタで開くにもgrepするにも何かと便利だったりするんだよ。
というかこれもう完全にバージョン管理ツールの話じゃなくて個人の
作業スタイルの話だからやめようぜ。

88 ：11/01/27

Mercurialは、BazaarやGitとはちょっと違う。ブランチもまとめてclone/push/pullになる。

89 ：11/01/27

>>86
bzr switch そのものズバリのコマンドがある。

90 ：11/01/27

>>87
> だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
> 持っておきたい場合があるんだって。
> コミットしない変更とか、バージョン管理下に無いテストデータとか、
> 色々なゴミファイルが作業ツリー配下にできるから。
分散型で「コミットしない変更とか、バージョン管理下に無いテストデータとか」が
発生すること自体が理解できないのだが
MercurialのMQや"git merge --squash"のような機能が無いってことなのか？

91 ：11/01/27

>>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 ：11/01/27

> bzrが使いにくくないと何か困ることがあるんだろうか？
Bazaarが使いづらいと、指摘している人が多いだけ。
このスレだと、比較分析されて当然。

93 ：11/01/27

>>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 ：11/01/27

>>93
うん、だから、
> もちろんそういったデータを管理するためのプラグインもある(pipeline)
> んだけど管理するよりディレクトリ分けた方が楽だと思ってるから
> 分けてるだけ。
って言ってる。
作業ツリーを分けるのは僕が楽と思ってるスタイルであって、別にbzrが推奨
しているわけではないし、bzrの機能不足で仕方なくこのスタイルをとっている
わけでもない。
ディレクトリを分けるのが面倒という意見に対する反例としてディレクトリを
分けるのが楽と感じる人もいるんだよという意味で自分のスタイルを紹介した
だけで、別にこれがbzrのスタイルではない。
bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
どのスタイルも推奨していない。
が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
可能性が高い。

95 ：11/01/27

自由度の高さがわかりづらさを助長してる部分はあるよね、Bazaar。
といいつつ愛用しているけれど。

96 ：11/01/27

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 ：11/01/27

Bazaarは色物だな。

98 ：11/01/27

>>56
> （作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
これって、Trac/Redmineを使えば良いだけでは？

99 ：11/01/27

>>94
> bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
> どのスタイルも推奨していない。
> が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
> bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
> 可能性が高い。
Bazaarの言う自由度の高さとGitのこれとは何が違うの？
Pro Git 5.1 Git での分散作業 分散作業の流れ
http://progit.org/book/ja/ch5-1.html

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

関数型言語Part5 (851)
スレ立てるまでもない質問はここで 118匹目 (233)
おまいら最強のシストレFXプログラムをしてみろよ (391)
VB.NET質問スレ(Part38) (607)
【O3D】HTML5用 3D API WebGL 【Canvas:3D】 (367)
Eclipse統合M32【Java/C++/Ruby/Python/Perl】 (719)
--log9.info------------------
OpenLDAP (305)
エディタ作ったよ！見てみて！ (229)
X window system (959)
OpenBSD入門の心得 (179)
全文検索エンジン Hyper Estraier 2 (300)
【ウホッ！】twmを語ろう！！【いいWM】 (495)
性善説のUNIXサーバVI (702)
FreeBSDの最後を見届けるスレ (393)
▲DHCPスレ (278)
恋愛をUNIXにたとえると (387)
今までにオライリー本何冊買いましたか？ (457)
BSD/OS (189)
ports, bootstrap-pkgsrcでトラブったらageるスレ (401)
もしもＵＮＩＸが存在しなかったら (102)
Jaris (697)
SONY NEWS-OS (439)
--log55.com------------------
電子レンジを使用している人の寿命は１０年縮む
遠赤外線パネルヒーターについて語るスレ Part2
日本も家電製品220V/60Hzで統一しねえ？
【暖房】電気 vs ガス vs　石油 part1
電子タバコ 総合スレ 94本目【タール0mg】
シュレッダー総合スレ
【遠赤】ダイキン　セラムヒート ３【焼き芋】
【ドラム】シャープドラム式洗濯機 1台目【SHARP】