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

バージョン管理システ ..

540:デフォルトの名無しさん
08/10/21 09:11:04
>>539
ありがとう

どの辺の章に書いてありましたか？以下で「排他」「file://」あたりで検索したのですが、
見つけられませんでした

Distributed revision control with Mercurial
URLﾘﾝｸ(ursm.jp)

541:デフォルトの名無しさん
08/10/21 09:58:55
>>540
4.5.3 並行アクセス

542:デフォルトの名無しさん
08/10/21 15:53:31
>>541
Thanks!! 見つけられました。安心したっす

4 Behind the scenes
URLﾘﾝｸ(ursm.jp)

543:デフォルトの名無しさん
08/10/25 14:06:51
hg convert がうごかないんだが、なんでかな?
% hg convert -s svn svn://svn.freebsd.org/base
assuming destination base-hg
initializing destination base-hg repository
Subversion python bindings could not be loaded
abort: svn://svn.freebsd.org/base: unknown repository type

% hg convert -s svn freebsd-head
assuming destination freebsd-head-hg
initializing destination freebsd-head-hg repository
Subversion python bindings could not be loaded
abort: freebsd-head: unknown repository type

544:デフォルトの名無しさん
08/10/25 14:57:01
>>543
Subversion python bindings could not be loaded

545:デフォルトの名無しさん
08/10/25 23:48:26
開発やってる奴でその質問はどうなんだ(´・ω・｀)

546:デフォルトの名無しさん
08/10/26 00:27:27
＞バージョン管理システムについて語るスレ2

547:デフォルトの名無しさん
08/10/26 01:55:24
>>546
エラーメッセージ完全スルーで2ch丸投げとか、
流石に情けないんじゃないのか、って話だと思うんだが。

548:デフォルトの名無しさん
08/10/26 17:11:14
んなこと全員分かってるわ

549:543
08/10/26 21:23:22
みなさんぼろくそいってくれてありががとう
devel/py-subversionをインストールしたら動き出しました。
エラーメッセージは読み違えていて
convert/subversion.pyが見つからないのかとおもってました。
ktraceしても原因は見つけられず。
どこかにconvert subversionはプロセスを起動するとあったので
てっきりsvnをforkexecするものだと...

550:デフォルトの名無しさん
08/10/26 23:11:53
おまい、おもろい。ｗ

551:デフォルトの名無しさん
08/10/27 06:54:35
TortoiseHgのリポジトリがBitbucketに移動してた

552:デフォルトの名無しさん
08/10/27 10:59:33
Python 2.5 の公式ドキュメント日本語訳完成
URLﾘﾝｸ(www.python.jp)

553:デフォルトの名無しさん
08/10/27 21:53:54
hgでパーミッションが保存されないんですが仕様ですか?
% hg init a
% cd a
% date>file
% date>file2
% chmod a-w file2
% ls -al
total 8
drwxr-xr-x 3 hoge hoge 5 10 27 21:44 ./
drwxr-xr-x 7 hoge hoge 9 10 27 21:43 ../
drwxr-xr-x 3 hoge hoge 5 10 27 21:43 .hg/
-rw-r--r-- 1 hoge hoge 40 10 27 21:43 file
-r--r--r-- 1 hoge hoge 40 10 27 21:44 file2
% hg add file file2
% hg commit -m "init"
% cd ..
% hg clone a b
updating working directory
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
% cd b
% ls -al
total 8
drwxr-xr-x 3 hoge hoge 5 10 27 21:44 ./
drwxr-xr-x 8 hoge hoge 10 10 27 21:44 ../
drwxr-xr-x 3 hoge hoge 9 10 27 21:44 .hg/
-rw-r--r-- 1 hoge hoge 40 10 27 21:44 file
-rw-r--r-- 1 hoge hoge 40 10 27 21:44 file2
%

554:デフォルトの名無しさん
08/10/31 11:56:13
>>553
パーミッションは保存されません。
hgに限らず、SubversionやVSSでもパーミッションは保存されません。
パーミッションはリビジョン管理システムの外側にある概念です。

555:デフォルトの名無しさん
08/10/31 11:58:59
>>554
Subversionはpropertyとして保存してくれるんだが。

556:デフォルトの名無しさん
08/10/31 13:28:25
だからなに？って話

557:デフォルトの名無しさん
08/10/31 14:48:20
>>556
>パーミッションはリビジョン管理システムの外側にある概念です。
というのが大間違いっていう話。

558:デフォルトの名無しさん
08/10/31 16:33:51
Subversionが自動的にパーミッション保存してくれるなんて初めて聞いたんだが

559:デフォルトの名無しさん
08/10/31 22:01:35
sccsは保存してくれたなぁ、と古い話。

560:デフォルトの名無しさん
08/10/31 22:04:06
svnが保存するのは実行ビットだけであってる?

561:553
08/10/31 23:30:12
hgのソースをみてみたら
どうもexec bitとsymlinkしかあつかえないようだ。

562:デフォルトの名無しさん
08/10/31 23:41:03
なんか問題あんの？
hook で chmod すればそれで終わりじゃん

563:デフォルトの名無しさん
08/11/02 09:12:41
hg はパーミッションは保持しないクソツール、と。

564:デフォルトの名無しさん
08/11/02 11:19:53
ここで煽ってみたところでなにも変わりはしないぞ

565:デフォルトの名無しさん
08/11/02 12:07:38
そもそも644になって問題がある開発環境なんて存在するのか？

566:デフォルトの名無しさん
08/11/03 01:06:15
>>565
というより、SCMとしての機能を考えると、実行属性以外のパーミッションとかACLとかを保存される方が困る気がする。

567:デフォルトの名無しさん
08/11/03 02:53:28
OSやfsによってマチマチだからなぁ

568:デフォルトの名無しさん
08/11/03 13:01:37
POSIX標準くらいサポートしてもバチは当たらない

569:デフォルトの名無しさん
08/11/03 14:17:51
属性を用意したからあとは勝手にやってくれって思想だよな

svn:permissionsを追加したってパッチはみつかったけど
設計や互換性の面で却下されてるようだ

570:デフォルトの名無しさん
08/11/04 18:32:59
TortoiseHGでBitbucketでssh経由でpushしたいのですが、上手くいかず困っています。
ToritoiseSVNでは同じようにして上手くいったのですが・・・

やったこと
・Bitbucketのアカウントをとる
・Bitbucketにssh公開鍵を追加
・setting->repogitoryの設定ダイアログにて、Pathのdefaultを
　ssh://(ユーザー名)@bitbucket.org/(ユーザー名)/(project名)/
に設定（＝ .hg/hgrcの[paths] の default = に上記パスを設定することと等価）
・TortoiseHGのpageantを起動し、対応する秘密鍵を追加
・コマンドラインから hg push → pageantで設定してあるのに何故かパスワードを聞かれる　→
　２回ほど入力したら pagelinkが落ちる。
出力：
　*** no suitable response from remote hg[command interrupted]
・GUIの Synchronize... から push 選択
　コマンドラインの時と同様になる

571:デフォルトの名無しさん
08/11/04 18:35:38
>>570
ToritoiseSVNでBitbucketでssh経由でpushする方法kwsk

572:デフォルトの名無しさん
08/11/04 18:49:33
ああ、スマソ。BitbucketではTortoiseSVNは使ってません・・・。
別のローカル鯖でTortoiseSVNのssh+svnで上手くいったという話です。

573:デフォルトの名無しさん
08/11/04 19:11:00
>>570
追記：
・hg push や GUIでsynchroize->push でパスワード聞かれるときは、
ユーザー名@bitbucket.org's password と言われる。
(鍵の場合 passphraseだったはず？)
・puttyで秘密鍵を指定してBitbucket に接続すると、passwordを聞かれ、
アカウントのパスワードや秘密鍵のパスワードを入れても接続できない。

状況がどうもおかしい気がします・・・

574:570
08/11/04 19:53:47
解決しますた。

>・setting->repogitoryの設定ダイアログにて、Pathのdefaultを
>　ssh://(ユーザー名)@bitbucket.org/(ユーザー名)/(project名)/
ここが間違ってました。
正しくは、
　ssh://hg@bitbucket.org/(ユーザー名)/(project名)/

以下に書いてありました。

Using SSH - Help ? bitbucket.org
URLﾘﾝｸ(www.bitbucket.org)

リポジトリページの https://をそのままコピペしてssh://に変えていたせいなのと、
上記ページの例をサンプルだからユーザーがhgになってるのかと思ってた・・・

575:デフォルトの名無しさん
08/11/05 23:58:24
mercurialはtransactionを意識しているのにfsyncしないのはなぜか?

576:デフォルトの名無しさん
08/11/06 18:55:10
SubversionからMercurialに変換したいのですが、
hg convert が動かない？のですが、何か必要なものがありますでしょうか？

> hg help convert
hg: unknown command 'convert'

> hg convert
hg: unknown command 'convert'

TortoiseHgの付属のhgです。

577:576
08/11/06 18:56:00
追記です。

> hg -v
Mercurial Distributed SCM (version 1.0.2+tortoisehg)

578:576
08/11/06 19:12:52
Mercurial.iniに以下を書き込んだら hg convert 自体はうごくようでした。

[extensions]
hgext.convert=

ConvertExtension - Mercurial
URLﾘﾝｸ(www.selenic.com)

ここ読め、オレ・・・

579:デフォルトの名無しさん
08/11/06 20:03:02
hg convertで、Subversionリポジトリからコンバートしているのですが、
もしかして、日本語ログを含んでいると壊れますか？

変換後のリポジトリをTortoiseHgのView Change Logで見ると、
アスキーのみのログのところでは問題なく履歴が見られますが、
日本語ログのリビジョンでは、まったく異なる履歴が表示されます。
（ファイル一覧、差分などがsvnのとは異なります）

これを回避して日本語ログのものもコンバートすることはできないのでしょうか？

580:デフォルトの名無しさん
08/11/06 20:28:33
>>579
TortoiseHgのことは知らないけど、Unix上では日本語ログもきれいに変換され
たよ

581:579
08/11/06 20:48:48
hgsvnも試したけど、hgimportsvnはおｋ。
hgpullsvnが、以下のエラーで途中死亡します orz

transaction abort!
rollback completed
abort: decoding near '縺阪↑縺・ｈ縺・↓菫': 'utf8' codec can't decode byte 0x82
in position 138: unexpected code byte!

>>580
ええ、まじすかー。

svnの日本語ログが変なのかなあ？TortoiseSVNで入れたログのはずですけど

582:579
08/11/06 21:02:40
2008-09-15 - kokiyaの日記
URLﾘﾝｸ(d.hatena.ne.jp)

こちらのサイトの

> 2.hgsvnの文字コードの変更

を行うと上手くいったような気がしました。
TortoiseSVNでのログはUTFとかで入ってないのかなぁ？
今時間がないので後でまた確かめて見ます。

583:579
08/11/07 07:59:05
日記みたいで、すいません。

hgsvnでsvnからhgへの変換が上手くいったかなーと思ったのですが、
trunk指定すると branchesとかtags 考慮してくれない orz
trunkの親ディレクトリを指定すると、今度はtrunk,branches,tagsと全部できてしまうし・・・

やっぱり、svnと連携するためのものか、これは・・・。

hg convertでなんとか変換する方法を模索したほうがよいようですね。

584:579
08/11/07 08:36:28
>>579の件ですが、
どうやら、壊れると思っていたsvnリポジトリは、hg convert で変換後、
問題のあるリビジョンを hg log -r2 -p などで見ると特に問題ない様子でした。
TortoiseHgのView Changelogのバグ？みたいですね。

585:デフォルトの名無しさん
08/11/07 17:27:47
git rebase origin
を実行すると
README.txt: needs update
とでてくるのですが、これはどういう意味ですか。
README.txtは変更されているのですが、updateが必要というのがよくわかりません。
またこのような状態のときにgit rebase originを問題なく実行するにはどうしたらいいですか。

586:デフォルトの名無しさん
08/11/07 23:37:48
>>583
そもそもsubversionにタグやブランチがないのが原因

587:デフォルトの名無しさん
08/11/08 03:27:23
>>585
README.txtを変更したままなんじゃない？
変更してるファイルがある状態ではrebaseは出来ないよ。
README.txtをコミットするかresetするかstashに追い出すかしてからrebase。

588:デフォルトの名無しさん
08/11/08 04:22:58
>>586
cvs done wrong

589:デフォルトの名無しさん
08/11/08 10:25:48
もっとも使われているらしいsvnはhgやgitよりもそんなに優れているの？

590:デフォルトの名無しさん
08/11/08 11:56:21
優劣ではなくそれぞれに特徴があるんだから、好きなの使えばいい

591:デフォルトの名無しさん
08/11/08 18:40:11
ここ最近のsvnマンセー祭りに吐き気を感じているアルファギークは多いだろうね

592:デフォルトの名無しさん
08/11/08 18:49:39
gitを使うぜみたいな話は最近目に余るようになってきたが、
いまさらsvnマンセーなんて言い出してるトコあるか?

593:デフォルトの名無しさん
08/11/08 18:54:09
アルファギークとかいっちゃってるやつに吐き気を感じる

594:デフォルトの名無しさん
08/11/08 19:29:14
svnマンセーはないだろうｗ
素晴らしい所は、ToritoiseSVNの完成度の高さぐらいだな。

595:デフォルトの名無しさん
08/11/08 19:37:27
アルファギークとか、スイーツ（笑）と同類だろ

596:デフォルトの名無しさん
08/11/08 20:58:46
嫉妬丸出しのレスばかりで笑った

>>593
底辺で蠢いてる奴発見ｗ

アルファギークはもう何歩先も行ってるからｗ

597:デフォルトの名無しさん
08/11/08 22:28:22
Pythonがsvnから移行したがってるようだけど
BazaarになるかMercurialになるか……もしかしてGitもあり?

598:デフォルトの名無しさん
08/11/08 22:28:58
集中管理の svn でも、「なんか変なツール」とか言われてるのに
このレベルで分散システムとか絶対無理だな、うちは

599:デフォルトの名無しさん
08/11/08 22:32:22
Windowsを軽視していないPythonなら、gitはまずないだろう。
MercurialがPython製ということを考えると、Mercurialが優勢ではなかろうか

600:デフォルトの名無しさん
08/11/08 22:35:59
>>599
BazaarもPython製ですよ

↓ソース。まだ検討始まったばかりだけど
URLﾘﾝｸ(www.python.org)

601:デフォルトの名無しさん
08/11/08 22:54:22
svnからの移行を検討するなら
　遅くてもレポジトリ効率で選ぶならbazaar
　そこそこ速くて使いやすさで選ぶならhg
　速くて機能で選ぶならgit

602:デフォルトの名無しさん
08/11/08 22:56:17
pythonで書かれているツールってことでbzrが有利だろうな

603:デフォルトの名無しさん
08/11/08 23:07:35
>>602
MercurialもPython製ですよ

604:デフォルトの名無しさん
08/11/08 23:34:12
Mercurialが優勢ということか

605:デフォルトの名無しさん
08/11/09 01:14:45
水銀党なのでhgの一択なのだが・・・

606:デフォルトの名無しさん
08/11/09 02:06:54
UNIX系で使って他(Windowsとか)を、それほど考慮しないとか
LinuxやLinusが個人的に嫌いじゃなかったら git
上記に当てはまるなら、他かな？
あてはまる人が結構いるから分かれるんだが

607:デフォルトの名無しさん
08/11/09 02:11:00
分散型って、ゲーム開発みたいに画像などのバイナリデータが容量のほとんどを
占めてスナップショットでも数ギガに行くようなプロジェクトでも、 Subversion より良いの？

それともプログラムソースがメインなプロジェクトに限って良いの？

608:デフォルトの名無しさん
08/11/09 02:18:36
607じゃないが、分散型に興味がある。
今までcvsとsvnしか使ったことがないが、どんなときにどんなメリットがあるのか。
またどんなデメリットがあるのか。
どんな点に注意して使えばよいのか。
そこら辺を具体的に解説したページはないだろうか？

「慣れろ」と言われるかも知れないが、
誰も知らない状態でいきなり本番プロジェクトに導入は出来ないし、
一人gitとかで試してみてもあんまり意味なさそうで・・・

609:デフォルトの名無しさん
08/11/09 02:27:43
分散型のメリット
すべてを手許に置けるのでオフラインででも開発可能でマージもバックアップも気楽にできる

分散型のデメリット
オリジナルの証明が難しい(事実上無い)

610:デフォルトの名無しさん
08/11/09 02:34:01
結局巨大バイナリを一番上手に扱えるのはどれ？
どうせテキストなんかサイズも小さいしある意味バイナリだし。

611:デフォルトの名無しさん
08/11/09 03:48:00
>>607-608
テキスト向きかバイナリ向きかっていうのは集中型か分散型かの差っていうより
ツールごとの差が大きい。開発形態が伽藍的かバザール的か、開発者が一箇所に
いるのか離れてるのかって観点で選んだほうがいいと思ってる。

会社である程度きっちり設計して2～3人で実装していくって形態ならsvnで十分まわせてるけど、
開発者が数人以上いるOSSのコントリビュータって立場のときはまじ分散型導入してくれって感じ

612:608
08/11/09 07:13:50
>>609
「オリジナルがない」という点は大きなデメリットだと思うのですが使用していてどうでしょうか？
皆が同じソースを見ることが出来ない＝AさんとBさんで同じソースについて認識が異なってしまう　ということで。
Aさん：rev329で試験したけど、これこれこういう動作がおかしいよ。直しておいて。
Bさん：それrev332で修正済みです
みたいな会話をどうやるのかがわからない。
仕事の現場なら非常に良くある話だと思うのですが。
メリットの方はsvn+svk(使ったことはないですが)でも可能なような。

>>611
仕事のプロジェクトなので伽藍方式オンリーですね。
開発者は大体同じ拠点にいますが、東京3人北海道3人大阪・・・ということもありました(svnで問題なく回っていました)。
2～3人で実装していく現場ってのは経験無いですなぁ。実装チームは5～10人が普通。

613:デフォルトの名無しさん
08/11/09 07:31:10
>>612
あなたのような「分散型使ってないけどどうなの？」っていう人は定期的に見かけるけど
チュートリアル見ながら触ってみるぐらいやってみたらどうだろう。たいした手間じゃないよ。

＞メリットの方はsvn+svk(使ったことはないですが)でも可能なような。
私はGitの前にsvkを使ってたけど、svkは遅すぎると思った。

あとオリジナルが無いという点については、Gitの場合はツリーに一意なIDが付くので問題ないと思う。

614:デフォルトの名無しさん
08/11/09 07:35:45
>>612
> 「オリジナルがない」という点は大きなデメリットだと思うのですが使用していてどうでしょうか？

オリジナルは決めとけばいいんじゃないか。集中管理のときと同じように、オリジナル用のサーバーってのを。
議論はそのサーバーにあるものに対してする。
push し忘れとか、pull した後 update し忘れとかが当面の問題になるんじゃないかなあ。

Mercurial 導入を提案しようかと自分で試用中だけど、ほかの人たちが使いこなせるとは思えないので、
今までどおり CVS にしようと思ってる。プロジェクト(リポジトリ)ツリーの好きなところからちぎって
持ってきて組み合わせられるような SCM はほかにはなさそうだし。

615:デフォルトの名無しさん
08/11/09 08:50:25
オリジナルが無いって語弊があるんじゃない?
svnと同じように中央レポジトリを作ればそれがオリジナルになる。

616:デフォルトの名無しさん
08/11/09 09:11:32
>>605
そいやmercurialだけ単独スレないな

617:デフォルトの名無しさん
08/11/09 12:03:16
Linux板にgitスレあったのか。CVSはUNIX板だし…。
スレも分散管理ですか。

618:デフォルトの名無しさん
08/11/09 12:12:36
>>616
何がそいやなんだｗ

619:デフォルトの名無しさん
08/11/09 12:22:20
どうもありがとうございます。
>>587
>変更してるファイルがある状態ではrebaseは出来ないよ。

この制約はどういう理由からきてるんでしょうか。
変更したファイルがあっても merge はできるんだから、rebase ぐらいできてもよさそうですが。

620:デフォルトの名無しさん
08/11/09 12:26:37
上の話が本当なら Python が hg か bzr になるかってのは試金石だな

621:デフォルトの名無しさん
08/11/09 13:31:09
リトマス？

622:デフォルトの名無しさん
08/11/09 13:40:35
普通に考えて分散型の方が良いとしか思えないなあ

623:デフォルトの名無しさん
08/11/09 13:51:49
>>622
bazaar＝分散型とはいえない

624:デフォルトの名無しさん
08/11/09 14:11:09
>>623
くわしく

625:デフォルトの名無しさん
08/11/09 14:18:44
>>608
分散型はローカルでもバージョン管理ができるというメリットがある。

よくプロジェクト全体でSVN使っていてローカルではRCSというような
使い方をしている人がいるが、分散型なら1つのシステムで対応できる。

626:デフォルトの名無しさん
08/11/09 15:00:35
>>625
>よくプロジェクト全体でSVN使っていてローカルではRCSというような
>使い方をしている人がいるが、分散型なら1つのシステムで対応できる。

GitやMercurialは、RCSの代わりに使えるのがいいよね。
プロジェクト全体はSVNで管理して、自分用のブランチはGitやMercurialで管理するのが楽でいいや。

627:デフォルトの名無しさん
08/11/09 15:10:32
>>626
Bazaar も仲間に入れてあげてください(´・ω・｀)

628:デフォルトの名無しさん
08/11/09 15:14:54
>>624
URLﾘﾝｸ(doc.bazaar-vcs.org)

629:デフォルトの名無しさん
08/11/09 15:27:23
俺いままでずっとバザールって読んでたよ
ダサイ名前だと思ってた

630:デフォルトの名無しさん
08/11/09 15:46:53
分散型はバージョン管理の入門用にうってつけなんだよね
スタンドアロンで使う場合最も敷居が低い

631:デフォルトの名無しさん
08/11/09 15:54:20
>>629
え、違うの?なんとなくエリックレイモンドの
「伽藍とバザール (The Cathedral and the Bazaar)」
から来てるんじゃないかと思ってたが。

632:デフォルトの名無しさん
08/11/09 16:07:50
>>618
そういえば →(口語化)→ そういやぁ →(短縮)→ そいや
かけ声じゃないよｗ

633:デフォルトの名無しさん
08/11/09 16:11:27
>>619
rebaseは、reset ＋ cherry-pick×n回を自動化してるだけだから、マージとは違う。
たしかに、現在の変更をstashしてrebase後にstashから戻す、という作業も、
rebaseで自動でやってくれれば、もっといいかもしれないね。

634:デフォルトの名無しさん
08/11/09 17:26:06
URLﾘﾝｸ(www.thefreedictionary.com)
敢えてカタカナにするなら、「バザール」以外にどうしろというのだろう。

635:デフォルトの名無しさん
08/11/09 17:30:15
ござーる

636:デフォルトの名無しさん
08/11/09 17:44:37
>>632で>>618の意味がわかってﾜﾛﾀ

637:デフォルトの名無しさん
08/11/09 17:44:48
おおいなるマンション　セザーーール
というのがあったな。

638:デフォルトの名無しさん
08/11/09 19:20:30
>>633
ありがとうございます。
変更したファイルがある状態で rebase したいとき、stashする方法と、ダミー commit + reset HEAD^ を使う方法を思いついたんですが、
どっちがいいと思いますか。
つまり

$ git stash
$ git rebase origin
$ stash apply
$ stash clear

または

$ git ci -a -m 'dummy'
$ git rebase origin
$ git reset HEAD^

のどっちがいいかという話です。
Git はまだよくわからんので、たとえばダミーでもcommitするのはイクナイ！とかあれば教えてください。

639:デフォルトの名無しさん
08/11/09 19:35:26
セザールはカエサル(シーザー)のフランス語読み。

640:デフォルトの名無しさん
08/11/09 20:19:12
おおいなるマンションバザールでござーるの巻

641:デフォルトの名無しさん
08/11/09 22:20:02
github についてなんですが…
誰か他人のプロジェクト
(1) git://github.com/誰か/プロジェクト.git
をforkしてできた
(2) git://github.com/自分/プロジェクト.git
をいじっても、(1)にpull requestを出してマージされない限りは
(1)に反映されることはないってことでいいんでしょうか？

642:デフォルトの名無しさん
08/11/10 09:57:54
hg qinit+qnewした状態でhg pushすると面倒なことになるんだけど
安全装置が付いてないのはなぜ?

643:デフォルトの名無しさん
08/11/10 11:03:26
>>641
はい、そうです。
他のひとのリポジトリを汚さないためのforkなので、当然です。
他のひとのリポジトリに書き込みしたいなら、そのリポジトリへのアクセス権をもらう必要があります。

644:デフォルトの名無しさん
08/11/10 19:27:04
>>628
ごめん、何がいいたいのかわかんない。
３行でまとめてくれ。
これじゃあBazaarのよさがわかんない。

645:デフォルトの名無しさん
08/11/10 23:30:17
>>642
面倒な事についてkwsk

646:デフォルトの名無しさん
08/11/11 00:12:47
>>644
リンク先は読んだ？　図解までされてものすごく解りやすかったぞ。

647:デフォルトの名無しさん
08/11/11 07:13:45
>>643
ありがとうございます。
やっぱりそうですよね…
こないだ自分のリポジトリを更新したら、勝手にfork元の
リポジトリも更新されたように見えて焦ったんですが
相手がpullしたってことなんだろうか。。

648:642
08/11/11 12:29:09
>>645 pushじゃなくてpullだった
rm -rf repo myrepo
HGUSER=alice@example.jp
export HGUSER
hg init repo
cd repo
date >file
hg commit -A -m "start"
hg clone . ../myrepo
hg qinit
hg qnew PATCH
for X in 1 2 3; do
date >>file
hg qrefresh
cd ../myrepo
hg pull
cd ../repo
done
hg glog --style=compact
cd ../myrepo
hg glog --style=compact

649:642
08/11/11 12:30:08
+ hg glog --style=compact
@ 1[qtip,qbase,tip,PATCH] 1a93f26efdf7 2008-11-11 12:27 +0900 alice
| [mq]: PATCH
|
o 0[qparent] c96ce7235e6b 2008-11-11 12:27 +0900 alice
start

+ cd ../myrepo
+ hg glog --style=compact
o 3[tip]:0 1a93f26efdf7 2008-11-11 12:27 +0900 alice
| [mq]: PATCH
|
| o 2:0 b3c2e24e33e9 2008-11-11 12:27 +0900 alice
|/ [mq]: PATCH
|
| o 1 b6fb28c1e4ff 2008-11-11 12:27 +0900 alice
|/ [mq]: PATCH
|
@ 0 c96ce7235e6b 2008-11-11 12:27 +0900 alice
start

650:デフォルトの名無しさん
08/11/11 22:45:30
subversionでｺﾐｯﾄしてる内容を、Google Codeみたくブラウザでも見れるようにしたいんだけど、
それってTracﾅﾝﾁｬﾗみたいなのに移行しないとダメ？

651:デフォルトの名無しさん
08/11/11 22:47:15
>>650
WebDAV

652:デフォルトの名無しさん
08/11/11 22:48:13
ﾎｹﾞｰｯ!!!ごめんなすって！viewﾅﾝﾁｬﾗってので出来る感じね！
ｺﾞﾒﾝﾈｺﾞﾒﾝﾈ

653:デフォルトの名無しさん
08/11/11 22:49:04
>>651
ありがDo！＿|＼○_

654:デフォルトの名無しさん
08/11/11 22:59:27
>>646

>>623
>>>622
>bazaar＝分散型とはいえない

>>628のリンク先を読んだけど、
bazaarはやはり分散型だと思うのだが、
分散型ではないという根拠は何？

655:デフォルトの名無しさん
08/11/11 23:04:02
>>654
分散型を分散型として使わなくても良いって意味じゃね？

656:デフォルトの名無しさん
08/11/11 23:45:26
>>638
どちらでもいいと思いますよ。
私は普段git-svn使ってるので、よくrebaseすることになるんだけど、最近使うのはstashかな。
少し前のバージョンまではstashが無かったので、ダミーコミットしてやってましたが、
stashの機能自体、内部では同じようなことをやってるんだと思う。ソース見てないですが。

657:デフォルトの名無しさん
08/11/12 01:19:03
すごい遅レスだけど、分散型のメリットは一言で言うなら、
「リポジトリ同士で」履歴のマージ等の操作ができるという点では。

非分散型=集中型でも、手元にリポジトリ作ればローカル管理はでき、
ファイル自体は他のリポジトリに移せるけれども、
履歴等を他のリポジトリに移すとかってのはできない。

違うかな?

658:デフォルトの名無しさん
08/11/12 01:42:50
分散型は分散した運用が可能な設計であるが、集中型の運用も可能ということだよね。
反対に集中型が基本のシステムで分散的な運用が必要になる時はものすごく苦痛。

集中型のシステムで開発してたのが、会社合併、アウトソーシング等で分散型の運用が
必要になったことが二回ほどあるがかなり苦労した。　

659:デフォルトの名無しさん
08/11/12 03:48:01
使ったことないが、bzrにはwikipediaにこういう記述があるから

> 中央サーバを使わない純粋な分散型バージョン管理システムと比べて、
> Bazaarは中央サーバ有り・無しの両方での動作をサポートしており、
> 同じプロジェクトに対し同時に両方の方法を使うことも可能である。

>>623が言いたかったのはそのこと(そういう機能？)じゃないか。

660:デフォルトの名無しさん
08/11/12 07:41:00
自分の作業するところは細かくコミットしたいから、こんなことやってる。
ちょっと面倒だし、もっと良い方法はあると思うけど。。

中央サーバ-からcheck out - A
coしたやつからbranch 　　 - B
Bをいじって適当にコミット
適当なところで、AでBの変更を取り込み
Aをコミットして中央サーバへ

更新を持ってくるときは、Aでupdateして, Bでpullする。

661:デフォルトの名無しさん
08/11/12 18:03:09
>>659
>> 同じプロジェクトに対し同時に両方の方法を使うことも可能である。
これすごいな。bzr++

662:デフォルトの名無しさん
08/11/13 01:42:08
集中型の利点は、チェックアウト→コミットの間の
ネットワーク転送量が少ない（記憶領域の使用量も少ない）ということかな。

分散型だと、リポジトリ全体を持ってきたりして、転送量がすごいことになったりするでしょ。
たとえば100GBのリポジトリをcloneすることを考えてみて。

663:デフォルトの名無しさん
08/11/13 01:55:40
　　　　　　　|
　　　＼　　__　　／
　　　＿　（ｍ）　＿ﾋﾟｺｰﾝ
　　　　　　|ミ|　　　　　torrentみたいに分散させれば
　　　　／　　｀´　　＼
　　　　　('A`)
　　　　　ノヽノヽ
　　　　　　　くく

664:デフォルトの名無しさん
08/11/13 06:44:35
CoreserverにTracってのを入れてみたいんだけど難しくて判んないよ～(´･ω･`)

665:デフォルトの名無しさん
08/11/13 07:02:40
>>664
レンタルサーバーか。
コンパイルしてホームにつっこむだけじゃないの？

666:デフォルトの名無しさん
08/11/13 08:04:20
Tracは依存関係がものすごいからな。
レン鯖の制限があると苦労しそうだ

667:デフォルトの名無しさん
08/11/13 10:08:28
Tracの話題はこっちじゃないかな

【バグ管理】 BTS使ってる？【追跡ﾞ】２
ｽﾚﾘﾝｸ(tech板)

668:デフォルトの名無しさん
08/11/13 10:59:24
>>667
ありがとう。いってきまーす。なにかヒントがあると良いな～(´･ω･`)

669:デフォルトの名無しさん
08/11/13 11:25:05
mantisっていうのは、TracやGoogle Codeみたいにファイル変更の差分が見れるものではない？(´･ω･`)

670:デフォルトの名無しさん
08/11/13 16:47:29
>>662
それ分散型か集中型かに関係なく仕組みによる。独立(standalone)なら全部取得だし、軽量(lightweight)なら一部のみ取得。

svnは軽量チェックアウト。
mercurialは独立ブランチ。
gitは軽量ブランチ。
bzrは独立チェックアウト(bzr co)、軽量チェックアウト(bzr co --lightweight)、独立ブランチ(bzr branch)。軽量ブランチはbzr cbranch --lightweightやbzr branch --stackedが当てはまるのかなぁ、良く分からね。

671:デフォルトの名無しさん
08/11/13 16:51:35
ああ、bzr cbranch --lightweightは勘違い。
他にも間違いありそうだから補足頼む。

672:デフォルトの名無しさん
08/11/14 01:35:44
日本語ディレクトリとかファイル名をバリバリに使ってるプロジェクトを
分散型バージョン管理システムで管理したいのですが、何を選択すべきでしょうか？
ちなみに環境はwindowsです。
（svkは試したのですが、あれは重すぎたのでそれ以外で）

673:デフォルトの名無しさん
08/11/14 06:51:19
使えるかどうかだったらhg, git, bzrのどれも使える。
ファイル毎にファイル名のencodingが違うとどれもダメだけど。
windowsだけならcp932だけになるのでどれもOK。
ただしTortoiseSVNのようなものを期待しているなら、
Hgにあるけどhgkだけが表示上は文字化けする、けど問題なく使えてる。
日本語ファイル名を使いたいならSVNが一番いいけど、
分散型でどれを選択すべきかはどれも微妙。

674:デフォルトの名無しさん
08/11/14 12:57:31
svn, bzrは基本的に問題ないだろう。

675:デフォルトの名無しさん
08/11/14 23:29:09
URLﾘﾝｸ(sourceforge.jp)
＞新規プロジェクトでは Git が標準で有効、CVS が無効に変更されました。

なんかすごいな。

676:デフォルトの名無しさん
08/11/14 23:32:56
>>675
おいおい、本家ではGit対応してなかったはずじゃ…と思ったら書いてある記事があった(下)。とはいえgithubやlaunchpadのように使えないと旨味が少ない気が。
SourceForge.JP、Gitのサポートを開始
URLﾘﾝｸ(www.itmedia.co.jp)

677:デフォルトの名無しさん
08/11/14 23:37:01
gitはWindowsで日本語ファイルはダメダメですよ
その前に、gitは日本語ファイル名を使うようなユーザー間ではまともに使えないと思うよ

678:デフォルトの名無しさん
08/11/14 23:44:59
集中型は svn、分散型は git になるのが加速されるのだろうか？

679:デフォルトの名無しさん
08/11/14 23:45:45
gitはないな
つうかいつまで集中型使われるんだ

680:デフォルトの名無しさん
08/11/14 23:46:17
　　　　　 ☆　ﾁﾝﾁﾝ　〃 ∧＿∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　ヽ　＿＿_＼（＼・∀・）　＜　Bazaarの対応まだー？
　　　　　　　＼＿／⊂　⊂＿ )　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／￣￣￣￣￣￣／|　　
　　　　　　　　|￣￣￣￣￣￣￣|　 |　

681:デフォルトの名無しさん
08/11/14 23:48:41
これで日本語ファイルのエンコード対応パッチも投げられるか。

682:デフォルトの名無しさん
08/11/15 00:24:51
国際化するなら、内部ではunicodeで処理、それぞれの環境でファイル名変換が妥当？

683:デフォルトの名無しさん
08/11/15 00:35:10
集中型はずっと使われると思うよ、svnで充分なこと多いし。

分散型はしばらく戦国時代だろうな。天下統一は遠いとみた。

684:デフォルトの名無しさん
08/11/15 01:04:10
Pythonで実装されてるやつは、Python3.0ベースになれば
文字コード問題は解決されそうだけどなぁ。

俺は、hgもgitも天下を取らないうちに次の新星が出てきて
そっちが天下を取ると思っているw

685:デフォルトの名無しさん
08/11/15 06:22:47
>>684
十分ありえそうな話ですね。
つうかgitでもhgでもbzrでもいいから、
一番優れた物がさっさと天下取ってほしい。
戦乱状態だと、使いつづけるのに不安が残る。

686:デフォルトの名無しさん
08/11/15 08:47:33
集中型は今はsvnって決まったも同然だから楽なんだけどね

687:デフォルトの名無しさん
08/11/15 12:52:08
>>677
Windows(Cygwin)のgitで日本語ファイル名を普通に使ってるけど

688:デフォルトの名無しさん
08/11/15 13:27:15
でも、やっぱプロジェクト内に浸透させるにはtortoise*が必要だわ

689:デフォルトの名無しさん
08/11/15 18:38:18
>>687
gitで日本語周りどういう風に運用してます？参考までに教えてください。

私が以前試したときの話ですが、

・UTF-8対応ターミナル用意した上で(もしくは、nkfとか通す前提で)
・コミットログは UTF-8
・エディタ(GIT_EDITOR)はデフォルトでUTF-8で起動させる必要がある
（UTF-8で起動できるソフトを使う。例：GreenPadなど）
・日本語ファイルは？ >>312 の問題があって、ここでオレはあきらめてしまった口だけど・・・
SJISだとWindows上ではOKだけど、
別プラットフォームだと×とかだったりしそうで

俺の周りだと、UTF-8ターミナル+cygwin+コマンドラインという環境用意させるのと、
日本語ファイル使う運用が矛盾をきたしたので結局やめてしまった。
（個人的にはオプソとかの開発とかパッチ作ったりには使ってる）

690:デフォルトの名無しさん
08/11/15 23:28:10
>>689
普通に、と書いてしまいましたが少しウソ。
Cygwin は ntf-8パッチの dllを使っています。
git は core level でファイル名の encode は考慮しません。
なので、ファイル名は utf-8 で統一します。
だた、これは subversion 等でも同じこと。
ツール群が良きに図らってくれるか、自分でそうするかという違い。
結局(ファイルの中身以外)utf-8で統一するなら、何使っても問題無い
ということですけど。

691:デフォルトの名無しさん
08/11/16 00:28:43
> Cygwin は ntf-8パッチの dllを使っています。

はあ。そうですよね。まだ対応してませんもんね。

> ツール群が良きに図らってくれるか、自分でそうするかという違い。

こりゃまた「敷居」って言葉を考えさせる発言ですね。

692:デフォルトの名無しさん
08/11/16 00:46:20
>>690
Subversionはファイル名のエンコードはロケールに合わせてくれるので、
日本語ファイル名はOSXでのNFD問題以外は問題はないな。

> 結局(ファイルの中身以外)utf-8で統一するなら、何使っても問題無い
これはOSXとLinuxで日本語の濁点を含むファイル名を利用してみれば、
そんなに簡単ではないということが分かるハズ。

693:デフォルトの名無しさん
08/11/16 00:51:10
URLﾘﾝｸ(sourceforge.jp)

694:689
08/11/16 00:59:26
>>690
なるほど、過去レスでも出てたCygwinのUTF-8パッチですね。
これは、試してみないとあかんなあ。

>>692
そこまで考えてなかたよ

>>693
ニュース: Gitサポートを開始しました - SourceForge.JP - SourceForge.JP
URLﾘﾝｸ(sourceforge.jp)
ソースフォルゲは相変わらず、Windows軽視だよなあｗ

695:デフォルトの名無しさん
08/11/16 02:28:02
Windows（笑）

696:デフォルトの名無しさん
08/11/16 05:40:03
>>684
Mercurialは3.0待ちかもしれないけど、Ｂａｚａａｒはもう日本語まったく問題ないよ。
ＴｏｒｔｏｉｓｅＢｚｒも日本語ちゃんと扱えてる。
(参考) URLﾘﾝｸ(dsas.blog.klab.org)

697:デフォルトの名無しさん
08/11/16 09:25:01
全角英数字使う奴は信用ならん

698:デフォルトの名無しさん
08/11/16 09:30:12
とはいえBzrにTotoiseがでたんだね。試してみる価値はありそう。
あとは速度がhg以上なら乗り換えるんだが。

699:デフォルトの名無しさん
08/11/16 10:21:09
>>696
やっぱり日本語だめだったよ。

TortoiseBzrで Init して日本語ファイル名をTortoiseBzrでaddし、
ファイルの中も日本語にしした結果、
TortoiseBzrでdiff → ファイル名は日本語で表示されるが中身が文字化け
cmd.exe上でdiff→中身は日本語で表示されるがファイル名が文字化け
ちなみに1.9のレポジトリフォーマットにしてみた。

あとGeneral Bazaar Options.. が開かないがバグかな。
それと、デスクトップ上でInitしようとしたらできなかった。
空文字入りパスは対応できない様だ。

ちょっと使っただけでこれだけ不具合が見つかる様じゃ、
まったく実用に耐えないね。まぁ、今後に期待はするが。

700:デフォルトの名無しさん
08/11/16 11:09:39
>>696
MercurialはUnicodeベースに変更できるからもう問題ないだろ
どこに問題があるんだ？

701:デフォルトの名無しさん
08/11/16 11:22:35
TortoiseBzr入れてみたんだが、そもそも日本語フォルダで Init できないのは
なんか設定ミスってる？

702:デフォルトの名無しさん
08/11/16 11:29:59
つかこれだけ国際化についての問題意識が広まっていながら
この体たらくって一体なんなんだろうね

703:デフォルトの名無しさん
08/11/16 11:44:30
海の向こうの変な文字のことなんて気にしないニダ

704:デフォルトの名無しさん
08/11/16 12:16:05
海の向こうはマジで
「『漢字』などという象形文字を使っている国は文化レベルが低い」
と思ってるらしいぜ。

705:デフォルトの名無しさん
08/11/16 12:29:26
自分らの文字は letter で漢字は character ですって。笑わせますよね。

706:デフォルトの名無しさん
08/11/16 12:38:03
よく体に漢字を彫ったりしてるじゃんｗ
自分にないものは格好良く見えるのか

707:デフォルトの名無しさん
08/11/16 12:39:08
全角英数字使う奴は信用ならないというのは正解だったということか。

708:デフォルトの名無しさん
08/11/16 12:43:00
>>706
あれはイラスト

709:デフォルトの名無しさん
08/11/16 13:20:05
>>699
あー、diffは仕方ないね。Subversionだって同じだろ？

ああ、「ファイル名」は日本語に対応しているけど、「ファイルの内容」は
文字コードとか気にせずにそのまま記録しているだけだから、
文字コードの自動認識してくれないdiffで見ると中身文字化けする。

ＷｉｎＭｅｒｇｅのような、文字コードを自動認識してくれる外部diffを使わないと
いけないな。

710:デフォルトの名無しさん
08/11/16 13:44:17
デスクトップ上でも空文字(スペース？)入りパスでもInitできたけど、なにが違うんだろ

711:デフォルトの名無しさん
08/11/16 14:28:10
>>709
すべてwindows上でやってるのにそれはないだろ。
subversionで同じ事やっても文字化けなどしないよ。

712:デフォルトの名無しさん
08/11/16 15:38:08
文句言うだけじゃなくて、日本人がもっと開発に参加して
日本語バッチリにしてやろうぜ。

713:デフォルトの名無しさん
08/11/16 15:50:37
Tortoise BZR doesn't support repos with non-latin characters in path
URLﾘﾝｸ(bugs.launchpad.net)

714:デフォルトの名無しさん
08/11/16 15:55:10
>>711
いやいや、俺Windowsでも普段UTF-8でテキストファイル書くし。
エンコーディングの自動判別していない限り、「たまたま」テキストファイルの
エンコーディングと表示に使うエンコーディングが一致したときに化けずに
表示されるだけ。

715:デフォルトの名無しさん
08/11/16 16:14:08
つーか中国でも普段使いの文字コードはだいたい１つだし、
環境によって文字コードを３種類から使い分ける必要がある国なんて日本ぐらいなんじゃね
日本人が対応するしかないだろ

716:デフォルトの名無しさん
08/11/16 16:18:12
>>700
設定の煩雑さ。

…使ってるけどさ。

717:デフォルトの名無しさん
08/11/16 16:32:36
>>715
何言ってんだ
中国のほうが環境によって使われる文字コードは多いだろ
日本語の EUC-JP(UNIX系),シフトJIS(DOS系),JIS(メール)に対応するものが
中国にもある上、繁体字・簡体字の区別もある

718:デフォルトの名無しさん
08/11/16 16:48:02
URLﾘﾝｸ(repo.or.cz)

719:デフォルトの名無しさん
08/11/16 17:05:02
>>718
Windowsでまともに動かないのにwww
作ったやつは頭がいかれてんじゃねwww

720:デフォルトの名無しさん
08/11/16 18:46:33
>>717
中国の繁体字簡体字は文字体系そのものが違うから関係無い話
繁体字で保存したテキストを簡体字で読むこともあるとか考えてたなら帰れ

721:デフォルトの名無しさん
08/11/16 22:34:07
>>720
バカの言い訳は見苦しい
そもそも何の話をしてるか理解してるか？

722:デフォルトの名無しさん
08/11/16 22:52:07
>>720

723:デフォルトの名無しさん
08/11/16 22:59:30
>>721-722
何の話をしてるか理解していないようだから言っておくが
中国では繁体字は big5 簡体字は EUC で FA だ
日本のように保存したファイルを別の文字コードに変換して表示したい
＝Windows でコミットしたファイルを Unix でも見たい
と言った状況でも何ら問題無いため文字コードの変換という実装は必要無い
＝現在の実装でも運用にさしたる問題は生じない
＝運用に問題が生じる日本から声を出していかないと開発側には問題が伝わらない
分かったなら俺と一緒に英語メールの書き方勉強しろや

724:デフォルトの名無しさん
08/11/16 23:04:45
簡体字はgbの方が主流。適当に語るのはやめれ。

725:デフォルトの名無しさん
08/11/16 23:10:06
EUC-CN と GB は同じだから。

726:デフォルトの名無しさん
08/11/17 00:00:04
bzrのdiffがコードページを無視してutf8を使ってるという話が、
文字コード自動判別の話になり、
中国語の文字コードの話になって、
文字コードを勝手に変換してプラットフォーム間の差異を吸収して欲しいという話になりました。
終わり。

727:デフォルトの名無しさん
08/11/17 00:06:21
出力時にコンソールのコードページをcp65001にすればいいだけじゃ?

728:デフォルトの名無しさん
08/11/17 00:17:32
中国はどうでもいい。
日本語環境だけが興味あるんだが。

729:デフォルトの名無しさん
08/11/17 00:20:22
日本語環境
svn >> git > hg >> bzr
でFA?

730:デフォルトの名無しさん
08/11/17 00:28:56
svn = bzr > hg = git

731:デフォルトの名無しさん
08/11/17 00:39:26
gitとhgは中身がロケール依存なので個人的にはなしの方向だな

732:デフォルトの名無しさん
08/11/17 01:32:34
gitがその位置ってのはありえないだろう

733:デフォルトの名無しさん
08/11/17 01:34:08
ごめんgitありえないだろうは、>>729ね。

734:デフォルトの名無しさん
08/11/17 07:19:22
おいおい、windows環境だけで化け化けの
bzrはどう見ても最下位だろう

735:デフォルトの名無しさん
08/11/17 09:04:21
>>734
化けて見えるのはdiffの表面上の問題だけで、リポジトリの中身はしっかりしてるから。
diff も、 bzr diff | vim - みたいにエディタで見れば問題ない。

svn, bzr:
　ファイルの内容はそのまま、ファイル名はUnicode
　(Windows と Linux で日本語ファイル名のファイルを行き来させても大丈夫)

git, hg:
　ファイルの内容はそのまま、ファイル名もそのまま
　(Windows と Linux で日本語ファイル名を行き来させるとどっちかで化ける)

736:デフォルトの名無しさん
08/11/17 09:38:33
svnもcygwin版じゃダメだぞ

737:デフォルトの名無しさん
08/11/17 09:44:32
>>736
cygwinはlocaleないからなぁ。。。
UTF-8版cygwinならなんとかなるのかな。

738:デフォルトの名無しさん
08/11/17 12:19:57
>>735
ログは皆UTF-8かな?

739:デフォルトの名無しさん
08/11/17 12:20:23
結局どれやねーん

740:デフォルトの名無しさん
08/11/17 12:36:08
>>739
わかるぞ、その気持ち

741:デフォルトの名無しさん
08/11/17 15:08:35
名前 bzr >>> hg >> git # ギット(笑) 商売の神マーキュリーから取った"気が変わりやすい"(笑)
コマンド名 hg >> git >>>>> bzr # 打ちやすさから。hgとmercurialの差が大きすぎるのは考慮してない。
使いやすさ ??? # 主観入るだろうから省略
Webインターフェース bzr > git >>>> hg # bzrはloggerhead(hgwebの派生)ね。hgwebの使いにくさは異常。
ホスティングサービス bzr >>>> git >>>> hg # launchpadはバグトラッカー付きでいたれりつくせり、githubは普及している、bitbucketは…
拡張性 bzr >>>> hg >> git # gitはC言語だからしゃーねーわな、でもgit-svnの酷さはフォローしない。あとhgは内部APIがショボいとか。プラグインの数の少なさからも裏付けられる。
設計の良さ bzr >> git > hg # 抽象化度
実装の良さ git >>>> bzr > hg # diffやmergeのアルゴリズムとか
SVNとの親和性 bzr >> git >>>>>>>> hg # bzrはbzr-svn、gitはgit-svnで評価。
使用率 git >>>> hg > bzr # Debianのpopconのデータからなので正確では無い
速度 git >>>> hg = bzr(1.9) >>>>> bzr(pack-0.92) # ちゃんと計測していない…。ちゃんと計測したいが…。
将来性 git >>> bzr >>> hg # gitはLinux Kernelで使われ続ける、bzrはUbuntuで使われ続ける、hgは…?
国際化 ??? # どれも完璧じゃない。cygwinに関してはcygwin側の問題だからそちら側で解決してもらえ…と言いたいけど、確か開発元がRHだから無理だろうなぁ(RH/Fedoraは未だに閉鎖的と感じる)。

とりあえず速度厨はgitを、拡張厨はbzrを、どっちつかずはhgを使っておけば良いと思うよ^^

次ページ