[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/21 17:38 / Filesize : 230 KB / Number-of Response : 918
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



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/

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で使うならなお更なのに・・・

774 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 12:46:20 ]
>>773
入りすらしないのは、0x5c問題だと思うよ。
0x5cが入ってないファイル名だと、コミットはできるけど、そのままリポジトリに入っちゃう。
(から、win32mbcs が必要。 mercurial.ini の [extensions] で win32mbcs= という一行を追加)

そもそも「ファイル名はバイト列として変更せずに扱う」というポリシーが間違ってると思うけど、
外国人には伝えにくいからねぇ。gitは最初からWindowsなんて気にしてないし。

Python3.0になると、文字列=unicodeになるから、「ファイル名のバイト列」自体消滅する。
MercurialもPython3.0対応する時点で嫌でもポリシーを修正するはず。
その前にBazaarに乗り換えたほうが幸せな気もする。

775 名前:765 mailto:sage [2008/11/19(水) 13:03:46 ]
>>768
Mercurialのレポジトリブラウザってpdfをテキスト化して表示するの?
コード眺めた感じそれっぽい部分は見当たらなかったけど.

>>770

> pdfに関してはIOが低いならメモリの問題じゃないんだけど、Mercurialは「pdfだけ」
> という処理はしてない。変なプラグインは入れてないよね?

そうなんだよね.なんでpdfに限ってこんなことになるのかがよくわかんない.
プラグインもなにも入れてないです.

> Adobe Readerのブラウザプラグインを無効にして、ブラウザが
> 「テンポラリファイルに保存→スタンドアロンのAdobe Reader 起動」
> するようにしてみて。

やってみたけど,症状はかわらずです.
というか,テキスト表示できないタイプのファイルってチェンジセットから
選択すると,最初に"これはバイナリファイルですよ"みたいなページに
遷移するよね?そのページのrawの項目を選択するとダウンロードが始まる,
みたいな.
pdfの場合,チェンジセットから選択したあとの最初の遷移の段階でとまって
しまうので,そのあたりは関係ないような気もする.

> あと、hg serveで軽くなるなら、fcgiの設定が良くない(メモリ食い)という可能性がある。
> fcgi使ったこと無いんだけど、スレッド数やプロセス数を減らせない?
> lighttpd も同時接続数を3くらいに減らしてみて。

いちおうlighttpd側でmaxprocsを3にはしてあるんですけど,だめですね.

776 名前:769 mailto:sage [2008/11/19(水) 13:05:29 ]
>>774
> (から、win32mbcs が必要。 mercurial.ini の [extensions] で win32mbcs= という一行を追加)
いけますタ!
hg と TortoiseHgの両方でいけることを確認しました。
どうやらすごいFAQみたいですね。

それにしても、TortoiseHgがコミットログやらファイル名やら化けまくりで実用に耐えられないなあ・・・
プログラマはそんなでもないけど、デザイナとか複数人で使う時に、
英語ファイル名、英語ログ強制はまず使ってもらえないわ w

バージョン管理ソフトとかこういう環境的な物の導入には、
手回しが一番重要だということはわかっているつもりだけど、さすがに致命的すぎる。

> その前にBazaarに乗り換えたほうが幸せな気もする。
そちらを検討してみます。

いろいろ教えてくれてありがとう。

777 名前:769 mailto:sage [2008/11/19(水) 13:06:19 ]
> バージョン管理ソフトとかこういう環境的な物の導入には、
> 手回しが一番重要だということはわかっているつもりだけど、さすがに致命的すぎる。

バージョン管理ソフトとかこういう環境的な物の導入には、
ソフトウェアの使い勝手よりも、むしろ
手回しが一番重要だということはわかっているつもりだけど、さすがに致命的すぎる。

778 名前:766 mailto:sage [2008/11/19(水) 14:24:59 ]
>>775
あらら、エスパー失敗か。

じゃぁ、その pdf ファイルの先頭 4096 バイト内に 0 というバイトが存在しないと予測。
Mercurialは先頭4096バイトの中に 0 が有るかどうかでバイナリとテキストを判別しているから、
テキストだと思って頑張って表示しようとしている可能性がある。

779 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 14:33:54 ]
>>774
> (から、win32mbcs が必要。 mercurial.ini の [extensions] で win32mbcs= という一行を追加)

環境変数 HGENCODING に cp932 を設定するのとでは何か違いある?



780 名前:765 mailto:sage [2008/11/19(水) 17:35:50 ]
>>778

それであたりっぽい.util.binaryが問題の部分だね.
開発ブランチだとファイル全体で0というバイトの有無を判定してるので,
そっちを使ってみることにするよ.

今サーバが落ちてるので,結果がわかり次第また書き込むわ.

781 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 17:57:13 ]
Mercurialは、どんなにTortoiseの完成度が高くなっても
デザイナーには使えない。概念的な部分の複雑度が高すぎる、
ってのが俺の印象だな。
プログラマーさえ、チームの2割もまともに理解できる奴いないと思う。

782 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 19:14:28 ]
PDFってテキストファイルの中に一部バイナリ埋まってるような構造だからなぁ

783 名前:765 mailto:sage [2008/11/19(水) 20:44:14 ]
765です。>>766さんの指摘で問題解決したので報告します。

問題の原因はファイルがバイナリかテキストかを判定するutil.binaryが、ファイルの先頭4096バイ
ト中に0というバイトがあるかどうかをチェックしていたことでした。

なので、この問題はutil.binaryを書き換えることで解決可能です。最初は開発版を使おうかと思って
いたけど、書き換えのみでとりあえず解決できたのでそうしました。ちなみに、バージョン1.0.1
のものを書き換えました。

書き換え自体は簡単なのでここには書かないけど、わからなければ開発版のコードを見れば大丈夫。

以上報告でした。付き合ってくれた方々ありがとう。

784 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 21:04:22 ]
git format-patch でできたパッチを適用するのは git am しかないんでしょうか。
メールボックスとかシランので、単に git format-patch でできたパッチを適用したいだけなんですけど。

785 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 21:17:51 ]
>>784
git am 0001-patch-name.patch
でいけました。メールボックスじゃなくてもいけますね。すんません。

786 名前:デフォルトの名無しさん mailto:sage [2008/11/19(水) 21:51:03 ]
hgのwin32mbcs拡張は前見たときは単に0x5c問題だけ回避してるように見えたんだけど
リポジトリに記録されるエンコーディングをユニコードにしてるって本当?

787 名前:デフォルトの名無しさん mailto:sage [2008/11/20(木) 01:09:34 ]
>781
基本的に理解力の低い人は、理解できない部分は無視してくれるので(例外は居るが)
まずはバックアップ支援ツールとして広め、ちょっとずつ高度化してくのが吉かと。

788 名前:デフォルトの名無しさん mailto:sage [2008/11/20(木) 14:48:10 ]
>概念的な部分の複雑度が高すぎる

ってのを読んだ限りだと、こいつは自分で使ったことが無いんだろうな

789 名前:デフォルトの名無しさん mailto:sage [2008/11/20(木) 19:27:17 ]
>788
いや、使ってみた感想だよ。俺が主に使ったのはLinux版のコマンドラインでだが。
他のメンバーは、より簡単なSubversion + TortoiseSVNでさえ、何度も繰り返し教えて
やっと使えるようになった状態だし、デザイナーが触るファイルにはロック機構が要ると思う。

プログラマでさえ、衝突時のマージがうまく出来ない奴も居るし、別branchの変更点を
trunkに取り込む為のマージ操作が出来る奴も限られてる。

で、この現状を見た時、より難解なMercurialを無事に導入出来るとは思えなかった。



790 名前:デフォルトの名無しさん mailto:sage [2008/11/20(木) 19:34:37 ]
svnの操作がどうこうよりもSCMについての根本的な理解が欠けてるだけなのでわ

791 名前:766 mailto:sage [2008/11/20(木) 21:03:38 ]
>>789
Subversion から

792 名前:デフォルトの名無しさん mailto:sage [2008/11/20(木) 23:18:43 ]
>789
だからまずはバックアップツールとして使って貰えと。
いきなりコンフリクトの解決方法云々は、性急過ぎる。
SCMの歴史を追うように、RCS的な使い方から順に、
少しづつ教えていった方が理解は早いぞ。

というか、いきなり高度な事を教えると基礎がおろそかに…

793 名前:デフォルトの名無しさん mailto:sage [2008/11/21(金) 08:40:27 ]
>>789
俺もチーム内で広めようと思っているんだけど、
こんなの使えねー、っていうのをなるべく避けるいい方法ないかね。

まずは、
バックアップツール=個人で使ってもらう




補完キボン

794 名前:デフォルトの名無しさん mailto:sage [2008/11/21(金) 11:08:45 ]
バックアップツール=個人で使ってもらう

毎日終業後に、SCMボランティアとして >793 が各メンバーのワーキングディレクトリを
チェックして回り、trunkとマージしてあげる

「>793 っていい人だよね」

795 名前:デフォルトの名無しさん mailto:sage [2008/11/21(金) 11:30:55 ]
1年くらい前にSubversionを使わせるようになったけど
使わせるにあたって最近は分散型が流行ってて
こんな事が出来るようになると言っておいた

慣れてくると、こんな事が出来るようになると便利なのにって
思うようになるから、予めそう言う知識の断片だけを
頭に入れて貰ってから使わせてる

で、最近は分散型にも徐々に興味を持ってくれるようになった


問題は俺がSVKしか使えないことなんだけど

796 名前:デフォルトの名無しさん mailto:sage [2008/11/21(金) 15:17:05 ]
svnのコマンドを拡張して分散型として使わせてくれたらうれしいんだけどね。
そもそもコンセプトが違うし無理か。

797 名前:デフォルトの名無しさん mailto:sage [2008/11/21(金) 15:45:44 ]
>>796
それが svk
ただし、サイズ的にも速度的にも効率悪い。

798 名前:デフォルトの名無しさん mailto:sage [2008/11/21(金) 15:47:16 ]
あ、あと、Bazaarリポジトリを svn:// プロトコルで見せようというプロジェクトもある。
まともに開発されてるのかは知らないけど。

799 名前:デフォルトの名無しさん mailto:sage [2008/11/21(金) 16:30:50 ]
つ git-svn
google code projectでもgit使える。

Google Open Source Blog: Develop with Git on a Google Code Project
google-opensource.blogspot.com/2008/05/develop-with-git-on-google-code-project.html




800 名前:デフォルトの名無しさん mailto:sage [2008/11/21(金) 16:54:15 ]
gitはコマンド違いすぎるだろjk






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<230KB

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