1 名前:デフォルトの名無しさん [2008/07/08(火) 21:38:48 ] バージョン管理システムについて語りましょう。 関連スレ CVS 1.3 [UNIX板] pc11.2ch.net/test/read.cgi/unix/1093611448/ CVS導入スレ〜 Rev.3 [プログラム板] pc11.2ch.net/test/read.cgi/tech/1113141518/ Subversion r9 [プログラム板] pc11.2ch.net/test/read.cgi/tech/1202086238/ subversion バージョン管理【サブバージョン】 [Linux板] pc11.2ch.net/test/read.cgi/linux/1154701996/ git スレッド [Linux板] pc11.2ch.net/test/read.cgi/linux/1197798039/ 前スレ バージョン管理システムについて語るスレ pc11.2ch.net/test/read.cgi/tech/1193332500/
673 名前:デフォルトの名無しさん mailto:sage [2008/11/14(金) 06:51:19 ] 使えるかどうかだったらhg, git, bzrのどれも使える。 ファイル毎にファイル名のencodingが違うとどれもダメだけど。 windowsだけならcp932だけになるのでどれもOK。 ただしTortoiseSVNのようなものを期待しているなら、 Hgにあるけどhgkだけが表示上は文字化けする、けど問題なく使えてる。 日本語ファイル名を使いたいならSVNが一番いいけど、 分散型でどれを選択すべきかはどれも微妙。
674 名前:デフォルトの名無しさん mailto:sage [2008/11/14(金) 12:57:31 ] svn, bzrは基本的に問題ないだろう。
675 名前:デフォルトの名無しさん mailto:sage [2008/11/14(金) 23:29:09 ] sourceforge.jp/forum/forum.php?forum_id=16362 >新規プロジェクトでは Git が標準で有効、CVS が無効に変更されました。 なんかすごいな。
676 名前:デフォルトの名無しさん mailto:sage [2008/11/14(金) 23:32:56 ] >>675 おいおい、本家ではGit対応してなかったはずじゃ…と思ったら書いてある記事があった(下)。とはいえgithubやlaunchpadのように使えないと旨味が少ない気が。 SourceForge.JP、Gitのサポートを開始 www.itmedia.co.jp/enterprise/articles/0811/14/news055.html
677 名前:デフォルトの名無しさん mailto:sage [2008/11/14(金) 23:37:01 ] gitはWindowsで日本語ファイルはダメダメですよ その前に、gitは日本語ファイル名を使うようなユーザー間ではまともに使えないと思うよ
678 名前:デフォルトの名無しさん mailto:sage [2008/11/14(金) 23:44:59 ] 集中型は svn、分散型は git になるのが加速されるのだろうか?
679 名前:デフォルトの名無しさん mailto:sage [2008/11/14(金) 23:45:45 ] gitはないな つうかいつまで集中型使われるんだ
680 名前:デフォルトの名無しさん mailto:sage [2008/11/14(金) 23:46:17 ] ☆ チンチン 〃 ∧_∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ヽ ___\(\・∀・) < Bazaarの対応まだー? \_/⊂ ⊂_ ) \_____________ / ̄ ̄ ̄ ̄ ̄ ̄ /| | ̄ ̄ ̄ ̄ ̄ ̄ ̄| |
681 名前:デフォルトの名無しさん mailto:sage [2008/11/14(金) 23:48:41 ] これで日本語ファイルのエンコード対応パッチも投げられるか。
682 名前:デフォルトの名無しさん mailto:sage [2008/11/15(土) 00:24:51 ] 国際化するなら、内部ではunicodeで処理、それぞれの環境でファイル名変換が妥当?
683 名前:デフォルトの名無しさん mailto:sage [2008/11/15(土) 00:35:10 ] 集中型はずっと使われると思うよ、svnで充分なこと多いし。 分散型はしばらく戦国時代だろうな。天下統一は遠いとみた。
684 名前:デフォルトの名無しさん mailto:sage [2008/11/15(土) 01:04:10 ] Pythonで実装されてるやつは、Python3.0ベースになれば 文字コード問題は解決されそうだけどなぁ。 俺は、hgもgitも天下を取らないうちに次の新星が出てきて そっちが天下を取ると思っているw
685 名前:デフォルトの名無しさん mailto:sage [2008/11/15(土) 06:22:47 ] >>684 十分ありえそうな話ですね。 つうかgitでもhgでもbzrでもいいから、 一番優れた物がさっさと天下取ってほしい。 戦乱状態だと、使いつづけるのに不安が残る。
686 名前:デフォルトの名無しさん mailto:sage [2008/11/15(土) 08:47:33 ] 集中型は今はsvnって決まったも同然だから楽なんだけどね
687 名前:デフォルトの名無しさん mailto:sage [2008/11/15(土) 12:52:08 ] >>677 Windows(Cygwin)のgitで日本語ファイル名を普通に使ってるけど
688 名前:デフォルトの名無しさん mailto:sage [2008/11/15(土) 13:27:15 ] でも、やっぱプロジェクト内に浸透させるにはtortoise*が必要だわ
689 名前:デフォルトの名無しさん mailto:sage [2008/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 名前:デフォルトの名無しさん mailto:sage [2008/11/15(土) 23:28:10 ] >>689 普通に、と書いてしまいましたが少しウソ。 Cygwin は ntf-8パッチの dllを使っています。 git は core level でファイル名の encode は考慮しません。 なので、ファイル名は utf-8 で統一します。 だた、これは subversion 等でも同じこと。 ツール群が良きに図らってくれるか、自分でそうするかという違い。 結局(ファイルの中身以外)utf-8で統一するなら、何使っても問題無い ということですけど。
691 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 00:28:43 ] > Cygwin は ntf-8パッチの dllを使っています。 はあ。そうですよね。まだ対応してませんもんね。 > ツール群が良きに図らってくれるか、自分でそうするかという違い。 こりゃまた「敷居」って言葉を考えさせる発言ですね。
692 名前:デフォルトの名無しさん [2008/11/16(日) 00:46:20 ] >>690 Subversionはファイル名のエンコードはロケールに合わせてくれるので、 日本語ファイル名はOSXでのNFD問題以外は問題はないな。 > 結局(ファイルの中身以外)utf-8で統一するなら、何使っても問題無い これはOSXとLinuxで日本語の濁点を含むファイル名を利用してみれば、 そんなに簡単ではないということが分かるハズ。
693 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 00:51:10 ] sourceforge.jp/forum/forum.php?forum_id=16362
694 名前:689 mailto:sage [2008/11/16(日) 00:59:26 ] >>690 なるほど、過去レスでも出てたCygwinのUTF-8パッチですね。 これは、試してみないとあかんなあ。 >>692 そこまで考えてなかたよ >>693 ニュース: Gitサポートを開始しました - SourceForge.JP - SourceForge.JP sourceforge.jp/forum/forum.php?forum_id=16362 ソースフォルゲは相変わらず、Windows軽視だよなあw
695 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 02:28:02 ] Windows(笑)
696 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 05:40:03 ] >>684 Mercurialは3.0待ちかもしれないけど、Bazaarはもう日本語まったく問題ないよ。 TortoiseBzrも日本語ちゃんと扱えてる。 (参考) ttp://dsas.blog.klab.org/archives/51344422.html
697 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 09:25:01 ] 全角英数字使う奴は信用ならん
698 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 09:30:12 ] とはいえBzrにTotoiseがでたんだね。試してみる価値はありそう。 あとは速度がhg以上なら乗り換えるんだが。
699 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 10:21:09 ] >>696 やっぱり日本語だめだったよ。 TortoiseBzrで Init して日本語ファイル名をTortoiseBzrでaddし、 ファイルの中も日本語にしした結果、 TortoiseBzrでdiff → ファイル名は日本語で表示されるが中身が文字化け cmd.exe上でdiff→中身は日本語で表示されるがファイル名が文字化け ちなみに1.9のレポジトリフォーマットにしてみた。 あとGeneral Bazaar Options.. が開かないがバグかな。 それと、デスクトップ上でInitしようとしたらできなかった。 空文字入りパスは対応できない様だ。 ちょっと使っただけでこれだけ不具合が見つかる様じゃ、 まったく実用に耐えないね。まぁ、今後に期待はするが。
700 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 11:09:39 ] >>696 MercurialはUnicodeベースに変更できるからもう問題ないだろ どこに問題があるんだ?
701 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 11:22:35 ] TortoiseBzr入れてみたんだが、そもそも日本語フォルダで Init できないのは なんか設定ミスってる?
702 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 11:29:59 ] つかこれだけ国際化についての問題意識が広まっていながら この体たらくって一体なんなんだろうね
703 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 11:44:30 ] 海の向こうの変な文字のことなんて気にしないニダ
704 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 12:16:05 ] 海の向こうはマジで 「『漢字』などという象形文字を使っている国は文化レベルが低い」 と思ってるらしいぜ。
705 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 12:29:26 ] 自分らの文字は letter で漢字は character ですって。笑わせますよね。
706 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 12:38:03 ] よく体に漢字を彫ったりしてるじゃんw 自分にないものは格好良く見えるのか
707 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 12:39:08 ] 全角英数字使う奴は信用ならないというのは正解だったということか。
708 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 12:43:00 ] >>706 あれはイラスト
709 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 13:20:05 ] >>699 あー、diffは仕方ないね。Subversionだって同じだろ? ああ、「ファイル名」は日本語に対応しているけど、「ファイルの内容」は 文字コードとか気にせずにそのまま記録しているだけだから、 文字コードの自動認識してくれないdiffで見ると中身文字化けする。 WinMergeのような、文字コードを自動認識してくれる外部diffを使わないと いけないな。
710 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 13:44:17 ] デスクトップ上でも空文字(スペース?)入りパスでもInitできたけど、なにが違うんだろ
711 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 14:28:10 ] >>709 すべてwindows上でやってるのにそれはないだろ。 subversionで同じ事やっても文字化けなどしないよ。
712 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 15:38:08 ] 文句言うだけじゃなくて、日本人がもっと開発に参加して 日本語バッチリにしてやろうぜ。
713 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 15:50:37 ] Tortoise BZR doesn't support repos with non-latin characters in path https://bugs.launchpad.net/tortoisebzr/+bug/267098
714 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 15:55:10 ] >>711 いやいや、俺Windowsでも普段UTF-8でテキストファイル書くし。 エンコーディングの自動判別していない限り、「たまたま」テキストファイルの エンコーディングと表示に使うエンコーディングが一致したときに化けずに 表示されるだけ。
715 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 16:14:08 ] つーか中国でも普段使いの文字コードはだいたい1つだし、 環境によって文字コードを3種類から使い分ける必要がある国なんて日本ぐらいなんじゃね 日本人が対応するしかないだろ
716 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 16:18:12 ] >>700 設定の煩雑さ。 …使ってるけどさ。
717 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 16:32:36 ] >>715 何言ってんだ 中国のほうが環境によって使われる文字コードは多いだろ 日本語の EUC-JP(UNIX系),シフトJIS(DOS系),JIS(メール)に対応するものが 中国にもある上、繁体字・簡体字の区別もある
718 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 16:48:02 ] repo.or.cz/w/TortoiseGit.git
719 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 17:05:02 ] >>718 Windowsでまともに動かないのにwww 作ったやつは頭がいかれてんじゃねwww
720 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 18:46:33 ] >>717 中国の 繁体字 簡体字 は文字体系そのものが違うから関係無い話 繁体字で保存したテキストを簡体字で読むこともあるとか考えてたなら帰れ
721 名前:デフォルトの名無しさん [2008/11/16(日) 22:34:07 ] >>720 バカの言い訳は見苦しい そもそも何の話をしてるか理解してるか?
722 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 22:52:07 ] >>720
723 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 22:59:30 ] >>721-722 何の話をしてるか理解していないようだから言っておくが 中国では繁体字 は big5 簡体字は EUC で FA だ 日本のように保存したファイルを別の文字コードに変換して表示したい =Windows でコミットしたファイルを Unix でも見たい と言った状況でも何ら問題無いため文字コードの変換という実装は必要無い =現在の実装でも運用にさしたる問題は生じない =運用に問題が生じる日本から声を出していかないと開発側には問題が伝わらない 分かったなら俺と一緒に英語メールの書き方勉強しろや
724 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 23:04:45 ] 簡体字はgbの方が主流。適当に語るのはやめれ。
725 名前:デフォルトの名無しさん mailto:sage [2008/11/16(日) 23:10:06 ] EUC-CN と GB は同じだから。
726 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 00:00:04 ] bzrのdiffがコードページを無視してutf8を使ってるという話が、 文字コード自動判別の話になり、 中国語の文字コードの話になって、 文字コードを勝手に変換してプラットフォーム間の差異を吸収して欲しいという話になりました。 終わり。
727 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 00:06:21 ] 出力時にコンソールのコードページをcp65001にすればいいだけじゃ?
728 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 00:17:32 ] 中国はどうでもいい。 日本語環境だけが興味あるんだが。
729 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 00:20:22 ] 日本語環境 svn >> git > hg >> bzr でFA?
730 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 00:28:56 ] svn = bzr > hg = git
731 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 00:39:26 ] gitとhgは中身がロケール依存なので個人的にはなしの方向だな
732 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 01:32:34 ] gitがその位置ってのはありえないだろう
733 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 01:34:08 ] ごめんgitありえないだろうは、>>729 ね。
734 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 07:19:22 ] おいおい、windows環境だけで化け化けの bzrはどう見ても最下位だろう
735 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 09:04:21 ] >>734 化けて見えるのはdiffの表面上の問題だけで、リポジトリの中身はしっかりしてるから。 diff も、 bzr diff | vim - みたいにエディタで見れば問題ない。 svn, bzr: ファイルの内容はそのまま、ファイル名はUnicode (Windows と Linux で日本語ファイル名のファイルを行き来させても大丈夫) git, hg: ファイルの内容はそのまま、ファイル名もそのまま (Windows と Linux で日本語ファイル名を行き来させるとどっちかで化ける)
736 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 09:38:33 ] svnもcygwin版じゃダメだぞ
737 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 09:44:32 ] >>736 cygwinはlocaleないからなぁ。。。 UTF-8版cygwinならなんとかなるのかな。
738 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 12:19:57 ] >>735 ログは皆UTF-8かな?
739 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 12:20:23 ] 結局どれやねーん
740 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 12:36:08 ] >>739 わかるぞ、その気持ち
741 名前:デフォルトの名無しさん mailto:sage [2008/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を使っておけば良いと思うよ^^
742 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 15:53:35 ] たぶん、日本国内だと、日本語解説サイトの数や充実度と、解説本の数で 勝負が決まってしまうと思う。Fedoraが日本でだけ万人向けディストロとして 流行ったみたいに。
743 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 17:46:56 ] hg のフォローしておくと、まず Mozilla や Sun では使われてる。 あと、コマンドが少なくて良い。同じことをやるのに迷う必要が無い。 一番良いのが基本的に push pull が HTTP で完結してること。 FW の設定いらんから大概使える。 Tortoise も一応あるし、速度 git 拡張 bzr 可搬 hg ってことにしといて。
744 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 18:08:02 ] >Mozilla や Sun では使われてる いや、そうでなくVCS自体の開発の後ろ盾の話。gitならLinuxのカーネルコミュニティ、bzrならCanonicalだけど、hgはどうだっけか。 >コマンドが少なくて良い --helpに出てくるコマンド多くね? むしろいくつかの面白いコマンドがあるところがhgの利点だと思うが。 >push pull が HTTP で完結 bzrもgitも対応してね?
745 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 19:23:02 ] hg mercurial >> bzr bazaar ttp://www.google.com/trends?q=hg+mercurial%2Cbzr+bazaar git >> hg mercurial ttp://www.google.com/trends?q=git%2Chg+mercurial git > subversion ttp://www.google.com/trends?q=git%2Csubversion subversion >> git (in japan) ttp://www.google.com/trends?q=git%2Csubversion&geo=JP
746 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 19:29:59 ] git って HTTP で完結してたの?
747 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 19:33:08 ] >>746 en.wikipedia.org/wiki/Comparison_of_revision_control_software Bazaar: HTTP, SFTP, FTP, custom, custom over ssh, email bundles, WebDAV (with plugin) Git: custom, custom over ssh, rsync, HTTP, email, bundles Mercurial: HTTP, custom over ssh, email bundles (with standard plugin)
748 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 20:43:18 ] >>747 FTP, SFTPがあることにびっくりだよBazaar!
749 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 22:20:07 ] 主観は入りまくりだけど、そこがよい >>741 乙
750 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 22:39:12 ] >>735 表面が化けてちゃ、おいしさも半減なわけですが。 いちいちvimでなんかみたくないし、Tortoiseで化けるのは 設定でなんとかなるの?
751 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 23:11:22 ] >>750 Tortoiseの方は.bzr/.branch/branch.confで 「encoding = エンコーディング」を指定したら logメニューからの表示は文字化けしなくなった。 diffメニューからの表示は文字化けするようだ。 コマンドラインから起動する場合はbzr qdiff --encoding=ARGで 一回実行すればエンコーディングのオプションはbranch.confに記録される。
752 名前:デフォルトの名無しさん mailto:sage [2008/11/17(月) 23:15:17 ] >>741 Gitのマージアルゴリズムはhgやbzrよりも劣るんじゃなかったっけ。 最近はそうでもないのかな?
753 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 02:47:52 ] Mercurialで、不要になったbranchを閉じるって、今のところ実装されてないんだね。 ↓一応、対策は提案されてるけど。 www.selenic.com/mercurial/wiki/index.cgi/PruningDeadBranches 開発チーム内に余計なbranchを作る奴が居ても、ずっと放置か。 hg branchしてない、名無しのheadでも同じ事だよね。 今のところは、リポジトリのcloneによる(概念的)branchの方が整理をつけやすくて 安全って事なのかな。
754 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 03:01:03 ] >>748 そう。さくらのレンタルサーバーとか、FTPやsftpが使えれば、サーバーに bzrをインストールしなくてもクライアントにだけbzrがあれば使えるのが強み。 これに慣れると、gitとかサーバー側にインストールするの面倒。
755 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 03:06:22 ] >>750 中身がしっかりしてれば、表面なんてどうにでもなる。 あるひとつの条件で、たまたまsvnが化けずにbzrが化けたからって、 svnの方が良いと考えるのは軽率すぎる。 bzrで化けるときの対策方は>>751 が教えてくれたけど、TortoiseBzrで WinMerge使えるようにはしたいね。今忙しいけど、手の空いたときに 試してみる。
756 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 03:17:06 ] >>754 sshfs でマウントしてしまえば git だろうが hg だろうが自由自在だと思うが.
757 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 03:25:17 ] Windowsでsshfsとかできないじゃん sshfsする一手間が面倒じゃん そもそも、安いレンサバだとssh使えないでFTPだけ使えるとかあるじゃん。
758 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 06:49:18 ] >>755 bzrは日本語全く問題ないんではなかったのか? 問題ありありなわけだが。嘘つき。 単一プラットホームで化けるなんて、中身がどうのこうの以前の問題だろ。 いくら、小手先の対策示しても意味ない。
759 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 11:33:44 ] >>758 そもそもdiffってのは、二つのファイルのエンコーディングと、ファイル名のエンコーディング、 合計3つのエンコーディングが混ざってるから、「完全」なんてありえないんだよ。 たとえば、コンソールでdiff出力してファイル名が化けるのは、ファイル名をUTF-8で出してるから。 svnで化けないって事は、svnはlocaleやコードページに変換してるんだろうな。 でも、そのdiffで作ったパッチを、メールでLinuxユーザーに送ったらどうなると思う? 「問題ない」といってるのは、「ソ連」みたいな0x5c問題や、環境依存のファイル名エンコーディングを そのままリポジトリにぶち込んでしまってほかの環境でファイル名が化けたりといった、日本語 ファイル名を扱う上での話をしてるんだよ。
760 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 15:21:47 ] それってdiff一般の話じゃないよね。 bzrのdiffの実装がそうなってるってこと?
761 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 20:01:04 ] >>760 コンソール上のdiff一般の話だよ。 diffが化けないのは、(1)コンソール、(2)ファイル名、(3)二つの入力ファイルの内容 すべてのエンコーディングが一致したときのみ。 ファイル名に関しては、diffで作ったパッチを送信したりすることを考えるとエンコーディングを 統一するべきで、統一するならUTF-8が妥当。なので、コマンドプロンプトをchcpでUTF-8 モードにするか、 diff | gvim - みたいにテキストエディタで見るしかない。 Linux でも、 diff の出力はリダイレクトでファイルに保存するかパイプで直接エディタで見るのが基本。 Bazaar Plugin の extdiff を使えば、外部の diff プログラムと連携できる。Windowsなら WinMergeとか使うと吉。
762 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 20:02:56 ] >>755 せっかくなので外部コマンドとエイリアスの使い方を書いておきます。 当面はコマンドツールとの併用になるでしょうから。 bzr diffでWinMergeを使いたいならオプションとして--using=WinMergeを指定します。 WinMergeの注意事項としてはmlang.dllによるコードページの検出オプションを 有効にしていないと付けないと文字化けします。 オプションの入力を省略したければbazaar.confファイルを 編集してエイリアスを設定します。 設定ファイルの位置はbzr versionで見つかります。 [ALIASES] diff=diff --using=WinMerge
763 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 20:10:06 ] ちなみに、GUIのdiffプログラムだとテキストエディタと同じで文字コード指定が 簡単にできたり自動認識したりすると良くて、その点 TortoiseBzr の中の qdiff は 機能不足。(これはBazaarの問題ではないが、周辺環境が揃ってない一例) 俺はソースをはじめテキスト類は全部UTF-8で書いてるから qdiff でも全く文字化け しない。 Windowsも早く日本語の標準マルチバイトエンコーディングをUTF-8にすれば良いのに、 いつまでcp932なんて使ってるんだろう・・・
764 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 23:43:44 ] cp932なのはwindowsが悪いけど、 今のbzrだと文字コードのせいですんなり使えないね。
765 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 01:05:57 ] Mercurialのレポジトリをhgwebdir.fcgiで公開してるんだけど,これってすごく重くない? うちのサーバがボロってのもあるかもしれないけど,大きめのファイルを開くと一気に ロードアベレージが跳ね上がってしまう. pdfファイルに至っては選択するといつまでたっても応答が返ってこないでCPU食いつぶしてるし. これってこういうもんなの?
766 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 01:51:29 ] >>765 スペック、構成、設定、ロードアベレージは具体的にどのプロセスが、IOとCPUのどちらで 重いのか、hg serve と比べてどれくらい遅いのか。 これくらいまとめてから質問しようぜ。
767 名前:765 mailto:sage [2008/11/19(水) 10:04:11 ] >>766 単に愚痴るだけのつもりだったんだけど,そのくらいの情報は出しとかないと 毒にも薬にもならんわな.すまん. サーバ機のスペックは CPU: Celeron 2.4GHz (詳しいことは忘れた.4年前くらいのセレロン) メモリ: 256MB OS: Ubuntu 8.10 このマシン上でlighttpdからhgwebdir.fcgiを呼び出してる. hgwebdir.fcgiはHGENCODINGをUTF-8に指定したくらいで, 他は特ににいじってない. 各レポジトリはbz2,gz,zipでのダウンロードを許可していて, pushにはDigest認証が必要にしてある で,pdfを開くと応答が返ってこないんだけど,このときCPU使用率が 跳ね上がっていることを確認済みで,IOなどは特に異常な数値は示し ていない.原因になっているプロセスはwebサーバを走らせているユー ザの権限で動いている python /usr/share/hg/cgi-bin/hgwebdir.fcgi 他の形式(テキスト形式のファイルや画像)だと,pdfよりサイズが 大きい場合でも一時的にCPU使用率があがるものの,きちんと表示される. あと,hg serveだと動作が軽快にはなってるみたいなんだけど, pdfを開こうとすると上で書いたのと同じような症状になって応答が 返ってこなくなる.
768 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 10:12:13 ] >767 知らんけど、内部でPDFをテキスト化するツールとか、Ghostscriptとかを 呼び出そうとしてトラブってるんじゃないの? Prostscriptの記述がバグって 無限ループしてるとか、展開サイズが大きすぎてメモリ不足になってるとか。
769 名前:デフォルトの名無しさん [2008/11/19(水) 12:10:57 ] TortoiseHg 0.5での質問があります。 ・日本語ログがupdate revisionで化けるので、事実上日本語ログが使えなくない? ・GUIで hg mv する方法はないのでしょうか? ・pushした日本語ファイル名がWindows以外の環境で化ける、というのは本当でしょうか?
770 名前:766 mailto:sage [2008/11/19(水) 12:21:38 ] >>767 ん、メモリが少なめだから、全体的にロードアベレージが高いのは リポジトリがキャッシュからすぐに消えちゃってる可能性がある。 pdfに関してはIOが低いならメモリの問題じゃないんだけど、Mercurialは「pdfだけ」 という処理はしてない。変なプラグインは入れてないよね? ということで、こっからエスパー。 pdfって、ブラウザプラグインで、ブラウザの画面内に表示してない? その場合、HTTPクライアントはブラウザじゃなくてプラグインになってるから、 それが分割ダウンロードとかしようとして負荷をかけてる可能性がある。 Adobe Readerのブラウザプラグインを無効にして、ブラウザが 「テンポラリファイルに保存→スタンドアロンのAdobe Reader 起動」 するようにしてみて。 あと、hg serveで軽くなるなら、fcgiの設定が良くない(メモリ食い)という可能性がある。 fcgi使ったこと無いんだけど、スレッド数やプロセス数を減らせない? lighttpd も同時接続数を3くらいに減らしてみて。
771 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 12:31:35 ] >>769 最後の問題、ファイル名エンコーディングをロケールから判別して、リポジトリに 入れる前にUnicodeへデコードするパッチを日本人が本家MLに送ったんだけど、 「ファイル名はファイルの内容と同じでバイナリ弄らない」とか言われてrejectされた。 なので、今は win32mbcs という拡張で対応しないといけない。一人でも対応してない ヤツがpushしたら、そのリポジトリはcp932ファイル名で汚される。 ただし、これはコンソールのエンコーディングがUTF-8じゃない場合の話で、 TortoiseHgだと最初からUnicodeでファイル名を使ってるかもしれない。 俺は TortoiseHg 使ってないんだけど、コンソールとTortoiseで日本語ファイル名を やり取りしてみたら?
772 名前:769 [2008/11/19(水) 12:36:20 ] > ・pushした日本語ファイル名がWindows以外の環境で化ける、というのは本当でしょうか? そもそも、Mercurialでは日本語ファイル名がコミットできないようです。 TortoiseHgでは、コミットウインドウでファイルを追加してもcommitボタンが押せず、 全選択チェックボックスを押すとcommitボタンが押せるのですが、 正常コミット時のように閉じてくれず、hg stで確認しても変化なしでした。 コマンドラインのhgでは、 > hg ci -A -m "initial commit from command line" adding ・が怖い、・の・フトSJIS.txt removing ・が怖い、・の・フトSJIS.txt ・が怖い、・の・フトSJIS.txt not tracked! ・が怖い、・の・フトSJIS.txt does not exist! nothing changed というように言われ、hg stで確認しましても変化ありません。 実はWindowsでのhgは日本語ファイル名に対応してなかったのですね・・・。 TortoiseHg 0.5と付属のコマンドラインのhgで確認しました。 ファイル名:表が怖い、噂のソフトSJIS.txt 中身は適当な感動コピペをSJISで保存です。
773 名前:769 mailto:sage [2008/11/19(水) 12:40:13 ] >>771 ああ、わかりました。 標準でSubversionのようにUnicodeへのデコードなどはやってないわけですか。 で、ロケール(日本語WindowsだとSJIS?)で入ってしまう、と (そもそも入りすらしなかったけどw) ファイル名とかログのエンコード周りは基本的なことだと思うのになあ。 OSSで使うならなお更なのに・・・