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

1 ：デフォルトの名無しさん：2011/01/20(木) 12:26:04

バージョン管理システムについて語りましょう

●過去スレ
バージョン管理システムについて語るスレ
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 ：デフォルトの名無しさん：2011/01/20(木) 12:26:45

●関連スレ
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 ：デフォルトの名無しさん：2011/01/20(木) 12:27:35

●関連サイト
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 ：デフォルトの名無しさん：2011/01/20(木) 12:28:25

立てました。

5 ：デフォルトの名無しさん：2011/01/20(木) 12:30: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 ：デフォルトの名無しさん：2011/01/20(木) 12:31:24

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

（チェンジセット: 4:ae4c01d241ab）

7 ：デフォルトの名無しさん：2011/01/20(木) 12:32:11

811 名前：デフォルトの名無しさん [sage]： 2011/01/01(土) 17:45:53
皆様のレスを読んだ上で、再度、大雑把に特性をまとめてみた。

Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・分岐時は、無名ブランチが自動で切られる。名前付ブランチもつくる事ができるが、目印なので必須では無い。
・ブランチ内のチェンジセットは木構造に並ぶ。
・分岐したブランチは、元のブランチに依存する。あるブランチ内のチェンジセットを消すと、別のブランチにある子孫チェンジセットも消える。
・複数のリポジトリで変更を行いpushしても、分岐しているので衝突はしない。ただし、解消が要求されるmulti-head状態になるので、先にpullが望ましい。

Git:
・一つのリポジトリで複数のブランチが扱える。
・分岐時に、ブランチ名を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のリポジトリで変更を行いpushすると、衝突が発生する。先にpullが必要。

Bazaar:
・ブランチだけで運用を行える。リポジトリを作ると、複数ブランチでデータを共有して省スペース、ブランチ作成などの高速化ができる。
・分岐時に、ブランチのディレクトリ配置を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・マージするときは、自分のリポジトリのコミットをメインライン、他のリポジトリのを傍流として記録。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のブランチで変更を行いpush/pullすると、衝突が発生する。先にpullが必要。

8 ：デフォルトの名無しさん：2011/01/20(木) 12:35:22

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 ：デフォルトの名無しさん：2011/01/20(木) 15:00:23

MacHgがなかなか良い。

10 ：デフォルトの名無しさん：2011/01/20(木) 15:14:59

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 ：デフォルトの名無しさん：2011/01/20(木) 15:15:43

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 ：デフォルトの名無しさん：2011/01/20(木) 18:04:24

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

13 ：デフォルトの名無しさん：2011/01/20(木) 18:44:34

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

14 ：デフォルトの名無しさん：2011/01/20(木) 22:46:02

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

15 ：デフォルトの名無しさん：2011/01/20(木) 22:59:57

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

16 ：デフォルトの名無しさん：2011/01/21(金) 00:10:52

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

17 ：デフォルトの名無しさん：2011/01/21(金) 00:43:44

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

18 ：デフォルトの名無しさん：2011/01/21(金) 00:55:06

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

19 ：デフォルトの名無しさん：2011/01/21(金) 01:41:43

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

20 ：前スレ989：2011/01/21(金) 23:57:50

>>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 ：デフォルトの名無しさん：2011/01/22(土) 04:43:43

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

22 ：デフォルトの名無しさん：2011/01/24(月) 17:36:10

TracやRedmineを併用している？

23 ：methane：2011/01/25(火) 16:58:26

>>8
http://svn.apache.org/viewvc/subversion/trunk/notes/unicode-composition-for-filenames?view=markup

ちなみに、2月リリースのbzr-2.3のベータ版ではもう直ってるっぽい。

24 ：デフォルトの名無しさん：2011/01/26(水) 06:51:31

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

25 ：デフォルトの名無しさん：2011/01/26(水) 10:39:24

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

26 ：デフォルトの名無しさん：2011/01/26(水) 11:49:05

>>25
リポジトリの構造や、ブランチ操作の手軽さはMercurialの方が優位だと思うが、弊社の以下の状況はBazaar優位になっています。

・PM佐藤は「英語わからんし」とつぶやいて、日本語ファイル名を作る。
・PG田中はマカーなので、Windowsは手が汚れると言って触りもしない。
・PG茶谷はLinuxでvimを使うことだけがアイデンティティ。
・ﾃﾞｻﾞｲﾅ鈴木はWindows以外は分からないと言って、Macintosh OS Xを直視もしない。

27 ：デフォルトの名無しさん：2011/01/26(水) 11:51:09

全員クビにしろよ

28 ：methane：2011/01/26(水) 12:28:18

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

29 ：デフォルトの名無しさん：2011/01/26(水) 12:36:33

>>28
表現方法が悪いのかも知れないけど、以下の理由でMercurialの方が優位だと思う。

・チェンジセットの関係が木構造で操作が直感的。
・名前無しブランチがあるので、ブランチを作るのが容易。
・名前付ブランチも、まとめてpush/pullできる。

GitもBazaarもブランチは直線的で、分岐するのには操作がいる。clone、push、pullもブランチ単位。
特にBazaarは、ブランチの扱いでディレクトリ配置を意識する必要がある。

30 ：methane：2011/01/26(水) 12:44:09

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

31 ：デフォルトの名無しさん：2011/01/26(水) 12:51:50

>>28
> bzrの方がファイル数少なくて容量小さいし、
hgはコピーをサポートしていて、ファイルの移動はコピーと削除だから
大幅にディレクトリ構成を変更した場合、必然的にリポジトリがでかくなる。
あまりにも大幅な構成の変更の場合、convertをした方が良い

bzrはコピーをサポートしている？

FATの場合、でかいファイルの方がフラグメントやらで都合が悪くない？
gitの場合、packするしないはユーザの自由だが、bzrは勝手にパックしちゃうのか？

> やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、

cygwin
あと、例の拡張

> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。

進化している
マイナーチェンジで基本は全く変わっていないけど

32 ：methane：2011/01/26(水) 13:02:40

>>31
bzrはコピーは今はサポートしていない。
代わりに、移動はサポートしていて移動しても容量は増えない。

FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
パックは10、100、1000コミットごとに自動で行われる。

>cygwin
>あと、例の拡張
Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
例の拡張ってなんだろう？

33 ：デフォルトの名無しさん：2011/01/26(水) 13:12:22

>>32
> >>31
> bzrはコピーは今はサポートしていない。
> 代わりに、移動はサポートしていて移動しても容量は増えない。
>
> FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
> ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
> パックは10、100、1000コミットごとに自動で行われる。

2GB制限は？

> >cygwin
> >あと、例の拡張
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
> 例の拡張ってなんだろう？

当然知っているでしょ？
MAX_PATHのことを言っているんでしょ？
ANSI APIを使うという方針なんだから仕方がない。
それを横取りしている拡張

34 ：methane：2011/01/26(水) 13:31:30

>>33
bzr関連のブランチを格納しまくってるshared repositoryの中をのぞいてみたら、
pack数が12個で最大のものが31MBだから、ソースコード管理では2GB制限は
気にしないで良さそう。動画ファイルとか大容量のファイルの扱いは確かに苦手。

MAX_PATHはANSIとは直交した制限で、CreateFileWとか使っても同じUTF-16の
コードポイント数が制限を受ける。
この制限を回避するためには "\\?\c:\" みたいな書きかたでWin32APIのチェックを
スルーしてファイルシステムにアクセスしないといけないんだけど、これをやると
カレントディレクトリとか一切使えなくなる。

例の拡張ってのが、もしfix-utf8の事を言っているのであれば、僕が昔触ってた時は
utf8<=>utf16の変換をしていただけで、 "\\?\" は使ってなかった。

35 ：デフォルトの名無しさん：2011/01/26(水) 13:40:40

hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
って、これも知っているよね？

もう１つの拡張の方も横取りしている。
パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
そこがANSI APIになっている。

36 ：デフォルトの名無しさん：2011/01/26(水) 13:48: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 ：デフォルトの名無しさん：2011/01/26(水) 13:59:05

>>36の続きだが、Bazaarの「リポジトリ」もあまり良いコンセプトに思えない。

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

38 ：デフォルトの名無しさん：2011/01/26(水) 14:07:06

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

39 ：デフォルトの名無しさん：2011/01/26(水) 14:09:15

>>36
git checkout -b NewBranch 0b70750b

40 ：methane：2011/01/26(水) 14:12:49

>>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 ：methane：2011/01/26(水) 14:13:42

>>36-37
つbzr-colo

42 ：デフォルトの名無しさん：2011/01/26(水) 14:53:47

>>41
何それ？

43 ：デフォルトの名無しさん：2011/01/26(水) 15:19:30

>>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 ：methane：2011/01/26(水) 18:32:36

>>42
簡単に言えば、gitみたいな名前付きブランチを実現するもの。

bzr自体は作業ツリー、ブランチ、リポジトリを分離して自由に構成できるけど、
逆に自由すぎるのが面倒なので、1リポジトリ, 複数のブランチ、1つの作業ツリーの
組み合わせを git のように扱えるようにしてくれるもの。

>>36 で言えば、
bzr colo-branch -r30 NewBranch
の1ステップになる（現在のブランチ=OldBranchのr30からNewBranchを作って、
作業ツリーを新しいブランチのチェックアウトに切り替える）

45 ：デフォルトの名無しさん：2011/01/26(水) 19:00:02

>>44
> >>42
> 簡単に言えば、gitみたいな名前付きブランチを実現するもの。

　　　　　　　　　＼　　　∩─ｰ､　　　====
　　　　　　　　　　＼／　●　､_ ｀ヽ　　======
　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　|　　 X_入__ノ　ミ　　　そんな餌で俺様が釣られクマ――
　　　　　　　　　　　､　(＿／　　　ノ　/⌒l
　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　=====
　　　　　　　　　　〈　　　　　　　　＿_ノ　　====
　　　　　　　　　　　＼　＼＿　　　　＼
　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　　　　　　　　　　＼　　＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　　　　　　　　　　＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ

46 ：デフォルトの名無しさん：2011/01/26(水) 23:34:10

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

47 ：デフォルトの名無しさん：2011/01/26(水) 23:54:13

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

48 ：methane：2011/01/27(木) 00:12:55

え、じゃぁ
http://progit.org/book/ja/ch3-2.html
ここでいう 'master' ブランチとかいうのは名前付きブランチじゃないの？

まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
なるのが bzr-colo

49 ：デフォルトの名無しさん：2011/01/27(木) 00:40:14

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

50 ：デフォルトの名無しさん：2011/01/27(木) 00:43:20

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

51 ：methane：2011/01/27(木) 00:47:49

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

52 ：デフォルトの名無しさん：2011/01/27(木) 00:54:56

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

53 ：デフォルトの名無しさん：2011/01/27(木) 01:10:01

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

54 ：デフォルトの名無しさん：2011/01/27(木) 02:27:26

>>52
は？

55 ：デフォルトの名無しさん：2011/01/27(木) 04:46:40

MercurialやGitのようなブランチの操作をするのに、bzr-coloが必要となる時点でBazaarは使いづらい。
「ブランチ」に対するアプローチが、

・ディレクトリ名を指定
・共有リポジトリ作成後、その下にあるディレクトリ名を指定
・bzr-coloを利用

と3種類もある。
GitやMercurialはシンプルなコンセプトで実装が見えない所が、SVNに似ているので見えてしまうのがBazaarという印象が拭えない。

56 ：methane：2011/01/27(木) 07:43:19

>>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 ：デフォルトの名無しさん：2011/01/27(木) 07:44:04

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

「名前付きブランチ」と「リビジョン番号」はgitには無い

58 ：デフォルトの名無しさん：2011/01/27(木) 07:46:13

>>48
> まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
> なるのが bzr-colo

用語はどうでもよいから、bzrは意味不明な用語を乱発しているのか

59 ：デフォルトの名無しさん：2011/01/27(木) 07:54:07

>>56
> 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が
> 安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）

大量のごみブランチが発生するのは害でしかない
マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない

github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
ブランチとやらがbzrの売りらしいが、
大規模コミュニティの開発では何のメリットも無い

60 ：methane：2011/01/27(木) 07:58:51

>>58
いちいち突っかかるなぁ。。。
僕が git が定義している用語を知らないし興味もないってだけだよ。
gitはgithubクライアントにしか使ってないから。
bzr ではきちんと用語を定義して使い分けてるよ。

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

61 ：デフォルトの名無しさん：2011/01/27(木) 08:04:16

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

62 ：methane：2011/01/27(木) 08:07:51

>>59
> 大量のごみブランチが発生するのは害でしかない
> マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない

だからこういう個人の主観による優劣で議論する気ないんだってば。
**俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」
ってならないし、本当に要らないものを整理する気になるから好きってだけで、
別にbzrはそれを強制してないから、 >>59 が bzr を使うときには俺と違う使い方をすればいい。

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

63 ：デフォルトの名無しさん：2011/01/27(木) 08:09:19

>>60
> 僕が git が定義している用語を知らないし興味もないってだけだよ。

bzr開発者はgitに興味が無いから、bzrは使い勝手の悪い誰得アプリになってしまったのか

64 ：methane：2011/01/27(木) 08:12:07

>>61
gitも一応githubクライアントとして少しは使ってるから、
ローカルブランチとリモートブランチは使ってるよ。

どちらもコミットのハッシュ値ではなくて名前で参照できるという点では、
hgでいう「名前付きブランチ」だね。
もちろん完全に同じものとは言ってないよ。

65 ：methane：2011/01/27(木) 08:13:34

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

66 ：デフォルトの名無しさん：2011/01/27(木) 09:01:24

>>62
> **俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」ってならない

Gitはブランチの一覧ができる。
Mercurialはブランチやヘッドの一覧ができる。
Bazaarはディレクトリを見て、「これブランチだっけ？」と考える必要がある。

目につくところに無いのは、Bazaarとしか思えない。

67 ：デフォルトの名無しさん：2011/01/27(木) 09:05:55

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

68 ：デフォルトの名無しさん：2011/01/27(木) 09:19:32

>>62
> だからこういう個人の主観による優劣で議論する気ないんだってば。

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

69 ：methane：2011/01/27(木) 09:35:19

>>66
だから **俺は** って言ってるじゃん。別にbzrがgit,hgより優れてるなんて言ってないよ。

**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
「これブランチだっけ？」なんて考えないし、そもそもコミットしてないデバッグ目的の変更や、
addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
そこに残しているの。
bzrならこんな使い方もできるというだけで、一般的にこの方法が優れているなんて思ってないし、
bzrもこの使い方を強制しているわけじゃない。

>>67
自分がpushできるブランチ

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

70 ：デフォルトの名無しさん：2011/01/27(木) 09:40:39

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

bzrは個人でしか使えないという認識で良いのですね？

71 ：デフォルトの名無しさん：2011/01/27(木) 09:41:55

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

72 ：デフォルトの名無しさん：2011/01/27(木) 09:42:12

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

73 ：methane：2011/01/27(木) 09:44:07

>>70
そもそもこの議論の発端が俺の「ブランチがディレクトリにひもづく」発言なんだから、
最初からローカル作業の話なんだけど？

開発サイトでのブランチの管理と、ローカルでの作業ツリー＋ブランチの管理は別物。

74 ：デフォルトの名無しさん：2011/01/27(木) 09:49:59

methaneたんﾍﾟﾛﾍﾟﾛ

75 ：デフォルトの名無しさん：2011/01/27(木) 10:00:45

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

Subversionの欠点をそのまま踏襲しているのか？

76 ：デフォルトの名無しさん：2011/01/27(木) 10:20:06

>>69
>**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て

GitやMercurialと比較して、Bazaarは運用にmethane氏のようなコツがいるわけだね。

77 ：デフォルトの名無しさん：2011/01/27(木) 10:23:16

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

78 ：デフォルトの名無しさん：2011/01/27(木) 10:30:24

Twitterでやれ

79 ：デフォルトの名無しさん：2011/01/27(木) 11:01:41

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

80 ：デフォルトの名無しさん：2011/01/27(木) 11:04:12

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

81 ：デフォルトの名無しさん：2011/01/27(木) 12:03:18

>56
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）

svnでrepo/projectname/trunkをチェックアウトするのではなく、
repo/projectnameをチェックアウトしてたって事？
変わった使い方だな。

82 ：methane：2011/01/27(木) 12:19:23

>>81
project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
をそれぞれ並列にチェックアウトして作業したい事ってない？
僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。

というかこれもう完全にbzrの話じゃないよね。
hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。

83 ：デフォルトの名無しさん：2011/01/27(木) 12:24:13

>82
> hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。

いや、あんたがsvn, bzrの特徴として言い出したんだが。

84 ：デフォルトの名無しさん：2011/01/27(木) 12:41:23

>>82
> project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
> をそれぞれ並列にチェックアウトして作業したい事ってない？
> 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。

hgは同じファイルシステムだとリポジトリはハードリンクだからコストがかからなし、
gitもhgもcheckoutで切り替えればいいだけ
わざわざ全部チェックアウトするメリットは？

85 ：methane：2011/01/27(木) 12:41:47

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

86 ：デフォルトの名無しさん：2011/01/27(木) 12:50:52

>>81
> svnでrepo/projectname/trunkをチェックアウトするのではなく、
> repo/projectnameをチェックアウトしてたって事？
> 変わった使い方だな。

なるほど、bzrは"svn switch"も簡単にできないから全部チェックアウトする必要があるのか

87 ：methane：2011/01/27(木) 12:53:10

>>84
だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
持っておきたい場合があるんだって。
コミットしない変更とか、バージョン管理下に無いテストデータとか、
色々なゴミファイルが作業ツリー配下にできるから。

別に git stash; git checkout; とかでも良いんだけど、ファイルシステム上に
合った方がテキストエディタで開くにもgrepするにも何かと便利だったりするんだよ。

というかこれもう完全にバージョン管理ツールの話じゃなくて個人の
作業スタイルの話だからやめようぜ。

88 ：デフォルトの名無しさん：2011/01/27(木) 12:54:05

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

89 ：methane：2011/01/27(木) 12:55:07

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

90 ：デフォルトの名無しさん：2011/01/27(木) 12:59:49

>>87
> だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
> 持っておきたい場合があるんだって。
> コミットしない変更とか、バージョン管理下に無いテストデータとか、
> 色々なゴミファイルが作業ツリー配下にできるから。

分散型で「コミットしない変更とか、バージョン管理下に無いテストデータとか」が
発生すること自体が理解できないのだが
MercurialのMQや"git merge --squash"のような機能が無いってことなのか？

91 ：methane：2011/01/27(木) 13:22:14

>>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 ：デフォルトの名無しさん：2011/01/27(木) 13:26:28

> bzrが使いにくくないと何か困ることがあるんだろうか？

Bazaarが使いづらいと、指摘している人が多いだけ。
このスレだと、比較分析されて当然。

93 ：デフォルトの名無しさん：2011/01/27(木) 13:36:04

>>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 ：methane：2011/01/27(木) 13:49:43

>>93
うん、だから、

> もちろんそういったデータを管理するためのプラグインもある(pipeline)
> んだけど管理するよりディレクトリ分けた方が楽だと思ってるから
> 分けてるだけ。

って言ってる。

作業ツリーを分けるのは僕が楽と思ってるスタイルであって、別にbzrが推奨
しているわけではないし、bzrの機能不足で仕方なくこのスタイルをとっている
わけでもない。

ディレクトリを分けるのが面倒という意見に対する反例としてディレクトリを
分けるのが楽と感じる人もいるんだよという意味で自分のスタイルを紹介した
だけで、別にこれがbzrのスタイルではない。

bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
どのスタイルも推奨していない。
が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
可能性が高い。

95 ：デフォルトの名無しさん：2011/01/27(木) 13:51:58

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

96 ：デフォルトの名無しさん：2011/01/27(木) 15:24:29

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 ：デフォルトの名無しさん：2011/01/27(木) 15:51:15

Bazaarは色物だな。

98 ：デフォルトの名無しさん：2011/01/27(木) 15:53:11

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

これって、Trac/Redmineを使えば良いだけでは？

99 ：デフォルトの名無しさん：2011/01/27(木) 16:39:14

>>94
> bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
> どのスタイルも推奨していない。
> が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
> bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
> 可能性が高い。

Bazaarの言う自由度の高さとGitのこれとは何が違うの？
Pro Git 5.1 Git での分散作業分散作業の流れ
http://progit.org/book/ja/ch5-1.html

100 ：methane：2011/01/27(木) 16:45:30

>>96
branch, merge, push で運用したいなら、 append-revisions-only は設定しちゃだめ。
例えば github のグラフとか見ると、 push したら一番上のラインがゴソっと入れ替わる
ことがあるけど、それを防止するのが append-revisions-only だから。

append-revisions-only を使って運用したら、履歴がこういう風に、ほかのブランチのマージだけになる。
http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes

bzr-colo 使わない場合は、bzr checkout http://example.com/repo/trunk; cd trunk; して、
bzr merge ../my_own_branch; bzr commit; のように、「trunkがローカルブランチを取り込む」
ようにしないといけない。
大規模プロジェクトでは、この trunk に merge して commit は、限られたコミッタが
手動でやるか、PQMみたいなシステムが自動的にレビューが完了したブランチを取り込む。
TortoiseBZR の開発では、細かい修正は直接 trunk の checkout 上でやってしまっている。

bzr-colo を使って作業ツリー1つでローカルブランチ使いたい場合は、多分こんな感じになる。

bzr colo-ify --trunk-name=local # (初回のみ)colo化して、今のブランチを local という名前にする
bzr branch http://example.com/repo/trunk colo:upstream --bind # (初回のみ)trunkを upstream という名前で持ってくる
bzr switch colo:upstream
bzr merge colo:local
bzr commit -m "Add XXX feature."

2回目以降は、bzr switch, bzr merge, bzr commit で良くなる。
ただし、coloは常用してないので嘘ついてるかも。後でやってみる。

101 ：methane：2011/01/27(木) 16:49:44

>>99
svnと同じく checkout, update, commit でリモートと同期がとれるのが
git の中央集権よりも svn チックな使い方かな。

会社で導入したとき、svn に慣れた人には branch, pull, merge, commit, push
の一連の操作が面倒らしく、特に非プログラマには最初はすごい不評だった。

今では基本的に checkout を推奨して、bzrを使いこなしたい人だけ
ローカルにブランチ作るということにしてる。

102 ：デフォルトの名無しさん：2011/01/27(木) 16:53:42

>>101
それって、Subversionに慣れている人はSubversionで、
Gitに慣れている人はgit-svnのGitで、を使えば出来ることだよね

103 ：デフォルトの名無しさん：2011/01/27(木) 17:04:14

>>102
それだとSubversionとgitの両方の環境を維持しなきゃいけないじゃない。
101の方法だとbzrだけに統一できて管理がシンプルになる。
業務でやるなら管理のシンプルさはけっこう重要だと思うがな。

104 ：デフォルトの名無しさん：2011/01/27(木) 17:15:15

>>103
Eclipse, Netbeans, Visual Studio, Trac, Redmine, Hudson
これら全てでBazaarはSubversionと遜色無く動くの？

105 ：103：2011/01/27(木) 18:17:04

知らんよ。
動かないといけない職場なら、それを前提に検討すりゃいい。
それでbzrが候補から落ちるならそれはそれ。

でもそういう状況にないそれが必要ない職場ならbzrでいいし、実際
methaneさんとこはそういう検討の末にbzr選んだだけでしょ?

106 ：デフォルトの名無しさん：2011/01/27(木) 18:51:20

じゃあ、プロジェクト管理は何でやっているの？
もしかしてExcel？
だから日本語ファイル名が必要なの？

append-revisions-onlyを使わないとリビジョン番号が変わるんだよね？
チケット駆動の開発をしていて、どのリビジョンで修正しました、ってのは、
どう指定すれば良いの？

make distでリビジョン番号を埋め込んだりするよね？
これもリビジョン番号変わっちゃうよね？

107 ：methane：2011/01/27(木) 19:02:33

なんか会社での運用の話になってるな。
あまり普通の会社じゃないからどれだけ役に立つか判らないけど、

TortoiseSVNに慣れたユーザーは以外とTortoiseBZR使って文句が無い

Eclipse, Netbeans は使ってる人いるけど、バージョン管理はコマンドライン
bzr-svn で svn プロトコルで serve することができるので、それを使って
trunk から svn としてチェックアウト＆コミットがどれくらい実用に耐えるのかは
今後検討しようと思ってる。

Trac, hudson は問題なし。Redmineは使ってない。

チケットはtracのURLを設定ファイルに書いておけば、 commit --fixes で連携可能だけど、
僕が見てる範囲だとあまりチケットとコミットの連携はしてないでユルく運用してる。

make dist をするプロジェクトは少ないんだけど、 >>101 に書いた通り
基本 checkout でやりたい人だけ branch する運用なので、 append-revision-only
で問題なく運用できてる。

108 ：デフォルトの名無しさん：2011/01/27(木) 19:10:28

bzr send使えばいいし

109 ：96：2011/01/27(木) 19:38:11

オレの問題は解決しないの？

110 ：デフォルトの名無しさん：2011/01/27(木) 19:41:58

>>109
これまでのレスを見ての通り、日本でBazaarを分散型として使っている人はいない

111 ：methane：2011/01/27(木) 19:45:00

>>109
append_revisions_only = False にするか、
trunk をチェックアウトしてそこから merge する。
詳しくは >>100

112 ：デフォルトの名無しさん：2011/01/27(木) 20:05:11

bzrもLaunchpadもばりばり使ってるけどね

113 ：デフォルトの名無しさん：2011/01/28(金) 11:04:08

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

http://mercurial.selenic.com/wiki/Win32LongFileNamesExtension

114 ：デフォルトの名無しさん：2011/01/28(金) 11:14:29

>>32
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。

https://bitbucket.org/remleduff/win32lfn/src/a21c5be76398/src/win32lfn.py#cl-65

115 ：デフォルトの名無しさん：2011/01/28(金) 11:35:20

116 ：デフォルトの名無しさん：2011/01/28(金) 12:41:08

>>111
リビジョン番号が変化するか、不便を強いられるかの2択か。

117 ：デフォルトの名無しさん：2011/01/28(金) 12:46:12

どんなんかなー

118 ：デフォルトの名無しさん：2011/01/28(金) 14:06:25

それは、ChangeLogを書き換えてコミットしたら、もうリポジトリはChangeLogとは
違うバージョンになってるってことと比べて、どの程度の不便さなん？

119 ：デフォルトの名無しさん：2011/01/28(金) 14:11:57

ChangeLogはCVSのバッドノウハウじゃない？
リリースノートは別管理でしょ？
Bazaarにあるか知らないけど$Rev$が意味をなさない弊害は大きいと思うが

120 ：デフォルトの名無しさん：2011/01/28(金) 18:32:49

>>118
ChangeLogって、CVSのログから自動生成するものだと思っていたが、手書きするのか
Subversion以降見かけたことが無いからぐぐってみたら、こんなの見つけた
http://svnlogbrowser.org/demo/

121 ：デフォルトの名無しさん：2011/01/29(土) 10:55:21

>>297
これって何で美乳なの？微乳じゃいかんの？

122 ：デフォルトの名無しさん：2011/01/29(土) 11:18:08

なるほど。乳をバージョン管理か。そいつは思いつかなかったｗ。

123 ：デフォルトの名無しさん：2011/01/29(土) 11:48:47

>>121
美乳　EUCでぐぐってみよう

124 ：デフォルトの名無しさん：2011/01/29(土) 11:55:48

>>121 は落ちたスレへの誤爆と思われ
次スレがあるのでそちらへどうぞ
http://hibari.2ch.net/test/read.cgi/tech/1291075205/

297 名前：デフォルトの名無しさん [sage]： 2010/09/10(金) 12:24:16
>>290
>>292
>>294
単なるZERO WIDTH SPACEだ？
じゃあお前らは編集者が意図した覚えも無いのに、先頭に勝手にunkoって保存されたりされなかったりする環境に何の問題も感じないの？
エンコーディングが明確になるだ？
文字化け対策のかっつーの
いらねーもん無断でつけんなカス

125 ：デフォルトの名無しさん：2011/02/12(土) 12:37:38

gitのイメージカラーってマリオ＆ルイージだよね

126 ：デフォルトの名無しさん：2011/02/13(日) 18:46:29

>>23
直っていない
https://bugs.launchpad.net/bzr/+bug/172383/comments/15

127 ：methane：2011/02/13(日) 22:51:01

>>126
http://irclogs.ubuntu.com/2011/01/25/%23bzr.html#t07:44

128 ：デフォルトの名無しさん：2011/02/15(火) 02:29:43

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

129 ：デフォルトの名無しさん：2011/02/16(水) 16:58:30

Hg/Git/Bzr のシェアってどんなもんなんですかね？

130 ：デフォルトの名無しさん：2011/02/16(水) 17:08:32

Git 6/Hg 3/Bzr 1

131 ：デフォルトの名無しさん：2011/02/16(水) 17:18:08

Git優勢なんすね

132 ：デフォルトの名無しさん：2011/02/16(水) 17:20:26

>>130
githubが目立つからそうかもしれないけど、
hgはbitbucket/google code/codeplexと分散しているのと、
hgwebが簡単に立てられて、自前で立てている所が多いから、
オープンソースでもhgはもっと多いと思う。
hgはWindowsサポートでgitより先に行っていたので、企業内ではさらに多いと思う。

133 ：デフォルトの名無しさん：2011/02/16(水) 17:35:28

http://qa.debian.org/popcon-graph.php?packages=bzr,git-core,mercurial,subversion&show_installed=on&want_legend=on&from_date=2008-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

134 ：デフォルトの名無しさん：2011/02/16(水) 17:49:06

>>133
一面ではあると思うが参考になったthx。

135 ：デフォルトの名無しさん：2011/02/16(水) 22:40:17

大事なのは、
どのVCSを使うかではなく、
VCSを使って何を作るかである、
とジョン・F・ケネディーも言っていたお。

136 ：デフォルトの名無しさん：2011/02/23(水) 13:50:37.67

最近、
思ったけどWindowsのデフォルトロケールをUTF-8に出来ないんだろうかね・・・
Linuxは、UTF-8にできるし、MacはUTF-8
Windowsさえ変えれれば幸せになれるんだけどなぁ・・・(正規化はおいとくとして)

いずれにせよ、GiもHgもバイナリ列でファイル名を扱うってポリシーなんだから
そのバイナリ列を作る部分にフックを置いて変換できるようにしといてくれればいいんだよぉ・・・

137 ：デフォルトの名無しさん：2011/02/23(水) 14:50:33.54

>>136
文字コードスレによれば、WindowsでDBCSが２バイトまでと決まっているから無理だそうだ

Mercurialでは関数のよこどりで実現している。あまり美しくないけど
開発者の問題意識はあるという所まで来ているので、大きい声をあげれば
フックみたいなのも実現できるかもしれない

138 ：デフォルトの名無しさん：2011/02/23(水) 15:47:16.08

>>137
Windows8以降でいいのでその辺り何とかして欲しいです・・・
いい加減、UTF-8を扱えないシステムって旧世代ってイメージが・・・

Mercurialの開発者に問題意識が？前は問題はないんだ、
という姿勢だったところからすれば勉強したのかね。自分の視野の狭さっぷりを。

139 ：デフォルトの名無しさん：2011/02/23(水) 15:54:28.95

Windows は NT のころから Unicode (UCS-2) 対応してて、LinuxやMacよりも
対応全然早かったんだけどな。

互換性のためにMBCSのAPIを残しているだけなんだから、Windowsの視点で言えば
10年以上前から用意しているUnicode API使わないで Windows 95 互換API使ってる
アプリの方が旧世代という事になる。

140 ：デフォルトの名無しさん：2011/02/23(水) 15:56:36.88

そりゃ"Double Byte"が3バイト以上だったりしたら困るわな

141 ：デフォルトの名無しさん：2011/02/23(水) 16:04:56.51

2byte用意しときゃ足りるだろ、というSingleByte圏の連中の発想が罪深い・・・・

142 ：デフォルトの名無しさん：2011/02/23(水) 16:17:51.15

>>141
DBCS=MBCSだからCP932用
UTF-16とは関係ない

143 ：デフォルトの名無しさん：2011/02/23(水) 16:36:34.15

UTF-16でサロゲートペア対応だから2byteじゃねーし。

144 ：デフォルトの名無しさん：2011/02/23(水) 17:29:00.69

>>142
あー、ごめん、Unicode策定してた連中に言ったつもりだった。

145 ：デフォルトの名無しさん：2011/02/23(水) 18:04:01.31

ん？

146 ：デフォルトの名無しさん：2011/02/23(水) 19:37:32.05

Windows対応アプリを作る場合は、APIコールの度に毎回UTF-8→UTF-16変換してW版APIを呼ぶのが正道なんだけど
DBCSで苦労してない言語圏の連中はわかっちゃいないからな。

Windows専用アプリならアプリ内部まで全部UTF-16で統一するのが普通。

147 ：デフォルトの名無しさん：2011/02/23(水) 23:20:04.23

>>141
Windows対応のクロスプラットフォームアプリを作る場合は、内部の
文字コードをUTF-8に統一するケースとUTF-16に統一するケースがある。
gtkは前者だし、Python、Java、CLI、wxWidgets、Qt は後者。

148 ：147：2011/02/23(水) 23:21:23.77

UTF-16というか、UTF-8以外のUnicode表現。UTF-16決め打ちじゃなくて
処理系の wchar_t に合わせる場合や、 Python のように UTF-16 と
UTF-32 を選べる場合もある。

149 ：デフォルトの名無しさん：2011/02/24(木) 23:28:17.70

文字としては、さすがにUCS-4で足りるだろうから
内部表現はUTF-32、外部表現はUTF-8ってのを標準にしてくれたら
スッキリするんだけどなぁ。

150 ：デフォルトの名無しさん：2011/02/24(木) 23:34:29.78

>>149
UTF-32だとメモリ使用量が上がる割には、別に1文字が1コードポイントに
なるわけでもないし、あんまり嬉しくない。
CJK以外はUTF-8が、CJKも含めるとUTF-16がベストバランス。

151 ：デフォルトの名無しさん：2011/02/24(木) 23:36:42.45

>>150
UTF-8 は1コードポイントが何バイトになるか不定だから、内部コーディングと
しては UTF-16 がベストバランス。

152 ：デフォルトの名無しさん：2011/02/24(木) 23:42:06.92

Javaって今は内部UTF-16でインターフェースは好きにできる感じじゃなかったっけ。
WindowsはUTF-16固定？

153 ：デフォルトの名無しさん：2011/02/24(木) 23:46:12.23

普通は内部文字コードは UCS4 じゃないの
UTF-16 は負の遺産という認識だったけど

154 ：デフォルトの名無しさん：2011/02/24(木) 23:49:15.38

UTF-16はサロゲートペアが気持ち悪いのでちょっと・・・
Javaはchar型が16bitだからプリミティブ型でUnicodeの文字全部は扱えないし・・・
無理矢理過ぎるんだよ・・・ASCII圏の人間に理解してもらえる訳ないじゃないか・・・

155 ：デフォルトの名無しさん：2011/02/24(木) 23:49:40.00

つうか、後顧の憂いを残さない為には、内外共にUTF-8にしておくのがベストなんじゃ？

156 ：デフォルトの名無しさん：2011/02/24(木) 23:49:54.49

>>153
>>147 も書いてるように、現役バリバリ。
UCS4にしたら、容量はほとんど倍になるのに、利点はサロゲートペアの
処理が不要になることくらいで、1文字が1コードポイントになるわけじゃない。

157 ：デフォルトの名無しさん：2011/02/24(木) 23:52:04.46

>>155
UTF-8にしたら結合文字やサロゲートペアの処理どころか
マルチバイトの処理まで必要になる。
内部コードをUTF-8の方針をとっているフレームワークも
あるけど少数派。

158 ：デフォルトの名無しさん：2011/02/24(木) 23:52:24.00

>>155
内をUTF-8にしたら処理が重くなると思うよ。
内部形式としては、固定長が幸せになれると思う。

159 ：デフォルトの名無しさん：2011/02/24(木) 23:52:55.00

内部コードを何にするかが、バージョン管理システムにどう影響するんだ？
いい加減スレ違いだからUnicodeスレに行け。

160 ：デフォルトの名無しさん：2011/02/24(木) 23:53:13.04

ってか、こんな問題の関わりたくないからファイル名はバイナリだ、とかいう割り切りになってんだろうね。

161 ：デフォルトの名無しさん：2011/02/24(木) 23:54:28.69

>>160
内部コードを何にするかとファイル名をどう扱うかは全く関係ないが。。。

162 ：デフォルトの名無しさん：2011/02/24(木) 23:57:10.63

>>156
現役なんじゃなくて歴史を引き摺ってるだけでしょ
日本人以外にとっては UTF-16 が救世主に見えた時があったからね

163 ：デフォルトの名無しさん：2011/02/25(金) 00:13:29.48

プログラム用のバージョン管理システムが扱う文字の範囲なんて殆ど ascii の範疇なんだから、
UTF-8 でも重くなりようが無い。UTF-16 はハナから無いでしょ。

164 ：デフォルトの名無しさん：2011/02/25(金) 00:16:13.76

保存用はそりゃUTF-8だろ。
今話してるのは、バージョン管理システムに限らず一般的なアプリケーションの
内部エンコーディングの話。つまりスレ違い。

165 ：デフォルトの名無しさん：2011/02/25(金) 00:26:42.61

元々はWindowsでファイル名が化ける云々…というのが発端で、
どうなれば最適解なんだろね、という話だから、それほど脱線でもないでしょ。
OS依存の話すんな、と言われればそれまでかも知れんが。

166 ：デフォルトの名無しさん：2011/02/25(金) 00:33:43.11

>>165
Windows に限定した話題なら、Unicode APIを使え、でFAだろ。

内部コーディングにUTF-8を使おうがUTF-32を使おうが、Unicode APIを
呼ぶときにUTF-16に変換すれば良い。
Javaが内部ではUTF-16でファイル名を扱ってても、Linuxでファイル名を
指定するときはUTF-8にエンコードしてシステムコール呼ぶのと一緒。

167 ：デフォルトの名無しさん：2011/02/25(金) 07:25:35.98

>>166
Windows以外ではファイル名に'\0'が入るのがアウトだから変換が必要。
JavaのShift_JIS、ms932のカオスをVCSがやる必要があるのか。

168 ：デフォルトの名無しさん：2011/02/25(金) 07:56:03.02

>>167
内部エンコーディングの意味わかってる？
API呼び出すときには、内部エンコーディングをそのプラットフォームの
APIに合わせるんだよ。
QtだってJavaだって、内部ではUTF-16を使って、Linuxでシステムコールを
呼ぶときにはバイト列に変換して呼び出してる。

169 ：デフォルトの名無しさん：2011/02/25(金) 08:05:16.70

>>168
分かっているよ。
VCSはファイルのバージョン管理をするソフトだよね？
git/mecurialはLinux生まれなんだから、内部をUnicodeにする必要は無いよね？
そんなことをしたらLatin-1の人にとってはパフォーマンス劣化して使いづらいものになるよね？

170 ：デフォルトの名無しさん：2011/02/25(金) 08:11:27.04

>>169
そこがパフォーマンス上ボトルネックになるとでも思っているのか…

171 ：デフォルトの名無しさん：2011/02/25(金) 08:18:17.40

>>170
Mercurialのコンソールのutf-8の日本語メッセージ(usageなど)の対応でも、
パフォーマンス劣化したって文句が上がってるんだよ？
Bazaarはいつになったらコンソールの日本語メッセージが出るようになるの？

172 ：デフォルトの名無しさん：2011/02/25(金) 08:33:17.66

>>171
i18n でパフォーマンスが劣化するとしたら、コールドスタート時に
メッセージカタログがディスクキャッシュに載ってない場合くらい。

メッセージのルックアップを繰り返しも少しオーバーヘッドになるから
繰り返して呼ばないようにする必要があるけど、Unicodeからlocale
への変換はさらに低コスト。
実使用には全く問題ないオーバーヘッド。そんなの気にする奴は
ベンチマーク厨だけ。

173 ：デフォルトの名無しさん：2011/02/25(金) 08:39:29.22

>>172
だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの

gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
Linuxカーネルのようにギガを超えているものだと、statusチェックだけでも、
３２ビットOSでは動かなくなるよ？

174 ：デフォルトの名無しさん：2011/02/25(金) 08:45:24.40

>>173
>だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
意味がわかんない。今までの内部エンコーディングの話とどう関係するの？

>gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
ファイル名のところだけな。
gitのメモリ消費はファイル名が大きな部分を占めてるん？

175 ：デフォルトの名無しさん：2011/02/25(金) 08:50:59.41

>>174
checkoutしたときのロケールとコミットするときのロケールが違うことはありえる
git/hg statusコマンドを叩く度に内部でファイル名をUnicodeに変換するとしたら使いものにならない

176 ：デフォルトの名無しさん：2011/02/25(金) 09:03:22.14

>>175
なるほど、バイナリ透過派だったのね。話が噛み合わないわけだ。
内部エンコーディングが UTF-8 vs UTF-16 の話からいつの間に話題が
変わってたんだろ。

バイト透過はLinuxの世界に引きこもる場合はロケール無視できて幸せだけど、
ファイルシステムがUnicodeなMacやWindowsと共同作業するのにはあまり
向かない。
俺は別に非ASCIIファイル名を使わないから気にしないけど。

177 ：デフォルトの名無しさん：2011/02/25(金) 09:39:03.80

>>176
Merurialはファイル名以外は内部UTF-8
Gitはログもバイト列でエンコード情報を付加している
どっちも正しい多言語化

178 ：デフォルトの名無しさん：2011/02/25(金) 10:03:21.47

>>177
あー、内部エンコーディングの話を無理やりbzrをディスる方向に
持って行きたかったのね。はいはい。

ファイル名に関しては、「たったひとつの正しい多言語対応」なんてものは存在しない。
ファイル名の扱いがOS毎に異なるんだから。

179 ：デフォルトの名無しさん：2011/02/25(金) 10:23:05.55

>>178
うん、bzrの設計はおかしい。
2005年だとJavaの文字２バイトのおかしさは認識されていたはずだし、
Linuxのutf-8ロケールも実用的になっていた。
Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
知らなかったとしか思えない。

180 ：デフォルトの名無しさん：2011/02/25(金) 10:35:36.51

>>179
> 2005年だとJavaの文字２バイトのおかしさは認識されていたはずだし、
> Linuxのutf-8ロケールも実用的になっていた。

意味不明。UTF-16 は Unicode のほとんどの文字集合を表現可能で、
UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
さらに言うと、bzrはPythonの unicode 型を使っているだけで、Pythonは
UTF-16とUTF-32を切り替え可能。bzrはPythonの内部エンコーディングに
依存してないし、リポジトリフォーマットではUTF-8を使ってる。

Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。

> Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
> 知らなかったとしか思えない。

bzr 開発してるのは Ubuntu Linux の開発してる Canonical で、
少なくともお前よりは Linux の多言語対応について判ってると思うぞ。

181 ：180：2011/02/25(金) 10:37:41.52

>UTF-16 は Unicode のほとんどの文字集合を表現可能で、
>UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。

の部分の日本語がおかしかった。
Unicode の（まだ文字が割り当てられていないコードを含む）ほとんどのコードを
表現可能で、UTF-16で表現できないコードに対して文字が割り当てられることは
永遠にないだろう。

182 ：デフォルトの名無しさん：2011/02/25(金) 10:38:27.52

>>180
>意味不明。
>別にEUCでもバイト透過にしたっていいじゃない。

本当は意味が分かってるんじゃないの?
本当は EUC にして良いとは思ってないんじゃないの?

183 ：デフォルトの名無しさん：2011/02/25(金) 10:38:56.90

bzrはどの分散管理よりもマルチ環境で使える
これが全て
他のは日本語環境だと使い物にならない

184 ：デフォルトの名無しさん：2011/02/25(金) 10:40:51.98

そっか。じゃあ俺は Git を使うわ。問題が起きた事無いし。

185 ：デフォルトの名無しさん：2011/02/25(金) 10:41:55.69

例えばSubversionの場合、
WindowsではUTF-16に変換してUnicode APIを呼ぶ（リポジトリ内部はUTF-8？）
Unix系ではその時のロケールに変換して出力、
って感じで、プラットフォーム毎に対応してるのかな？

単に表示上の問題だけならUIで吸収できると思うんだけど、ファイル名となると
ファイルシステムが対応してないとダメじゃない？
Linuxのファイルシステムって、内部表現とかあるんだろうか。
ファイル名のバイト表現が不定になると動かなくなるアプリとか、けっこうありそうな…

186 ：180：2011/02/25(金) 10:49:26.64

>>185
subversion に関しては yes

ファイルシステムに関しては、Linuxの場合は標準的に使われている
ファイルシステム(ext, btrfs, xfs, reiserfs)はバイト透過型。
Unicode型のHFS+を使ったりもできるけどね。

ファイル名のバイト表現が不定だと動かないのは、まさにMakefile
クロスプラットフォームではASCII文字以外使いものにならないけど、
Makefileに非ASCII文字書きたい人があまりいないから問題ない。

antとかはsvnと同じ方式だから、逆にロケールや環境が変わってるのに
バイト列が保存されてると動かない。

187 ：180：2011/02/25(金) 10:50:37.47

>>182
Unicodeに統一したいの？したくないの？
まったく意味が判らないよ。

188 ：デフォルトの名無しさん：2011/02/25(金) 11:34:29.81

ファイル名なんかよりもコミットログ、特にコミットユーザ名が一番重要。
フランス人、ドイツ人にコミットユーザ名に非ASCIIを使うな、って言えない。
git、hgは入力・出力どっちもきちんと対応している。
bzrはファイル名もロケール依存になっている不思議な設計。

189 ：デフォルトの名無しさん：2011/02/25(金) 11:50:50.34

>>186
なるほど。ファイルシステムはパフォーマンス出したいところだから、
内部はバイト透過にしておきたいだろうなぁ。

>>188
Subversionもファイル名ロケール依存では？

現状を考えると、フランス人ドイツ人もユーザ名はASCIIでは困るけど、
ファイル名はASCIIでいいよ、って感じなのかね。
それかどうしてもファイル名に非ASCII使いたい場合はUTF-8決めうちにしておいて、
UI側でそう見做せばいいでしょ、っていうのがLinux方面のスタンスかな？

190 ：デフォルトの名無しさん：2011/02/25(金) 12:20:48.99

>>188
全部大事
全部満たしてるのがbzrだけ

191 ：デフォルトの名無しさん：2011/02/25(金) 12:27:11.43

>>190
日本人の人名で普通に使われている文字がbzrでは使えないよね？

192 ：methane：2011/02/25(金) 12:40:06.97

>>191
一応言っておくけど、bzrがNFCで正規化するのはファイル名だけで、
コミッターやコミットログには示申を書いても神になったりしないよ。
hg, git と同じレベルで問題ない。

ファイル名をUnicodeで扱うのが正しいのかどうかは、>>178の言うとおり
正解はない。どのポリシーを選択するかだけ。

193 ：デフォルトの名無しさん：2011/02/25(金) 13:25:59.99

でも・・・正解が欲しいよ・・・ママン・・・

194 ：デフォルトの名無しさん：2011/02/25(金) 13:43:27.41

そんなものを求めたら宗教戦争に巻き込まれるだけだと思うぞ

195 ：デフォルトの名無しさん：2011/02/25(金) 14:51:51.55

いあ、add時のプラットフォームとエンコーディングをメタ情報に持った上でファイル名自体はバイナリとして保存、
比較や他プラットフォームに展開するときのみコード変換、正規化。
このやり方ならUnicode決め打ちよりはずっと多くの文字を正確に扱える。

こんなめんどくさいことをしてるアプリは見たことないが。

196 ：デフォルトの名無しさん：2011/02/25(金) 14:54:01.19

>>195
よう、いいだしっぺ

197 ：デフォルトの名無しさん：2011/02/25(金) 15:17:44.23

もうMIMEエンコードして保持しとけよ

198 ：デフォルトの名無しさん：2011/02/25(金) 15:17:45.41

>>195
そのアプローチだと、ひとつのファイル名に
互換性のない複数のエンコーディングが混じった場合どうすんの？

199 ：デフォルトの名無しさん：2011/02/25(金) 15:21:00.63

>>198
例えばLinuxでLANGをSJISにして「あ.txt」を追加、次はEUCにして「あ.txt」を追加、とかか？
それでも同じLinux上でチェックアウトするなら片方文字化けするだけで問題ない。
他のOSに持って行こうとすればエラーにでもすればいいと思う。
(理屈としてはWindowsでA.txtとa.txtが同時に存在できないのと同じ)

200 ：デフォルトの名無しさん：2011/02/25(金) 16:29:57.73

>>197
Mercurialのリポジトリファイル名はそんな感じ。
だから、UTF-8だろうがコロンが入ろうが、リポジトリはFATに置ける

201 ：デフォルトの名無しさん：2011/02/25(金) 16:33:31.64

>>199
cygwinがそれをやっているので、git/hg本体がやる必要性が無くなった

202 ：デフォルトの名無しさん：2011/02/25(金) 16:38:53.66

>>201
Eclipseで使えないと困っちゃうんだよねぇ・・・

203 ：デフォルトの名無しさん：2011/02/25(金) 16:50:04.22

>>201
それってUTF-8対応したCygwinってやつ？
てことは、WindowsでもCygwinなら化けない？

204 ：デフォルトの名無しさん：2011/02/25(金) 17:15:40.44

>>203
そうだよ、EUC-JPのファイル名もチェックアウトできるよ

205 ：デフォルトの名無しさん：2011/02/25(金) 18:45:30.52

>>180
> Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
> するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。

ということで、Git/Mercurialは、Linuxではバイト透過で、
cygwinでは、LANG=ja_JP.EUC-JPでEUC-JPファイル名を使えますが？

206 ：デフォルトの名無しさん：2011/02/25(金) 19:21:43.99

>>201
NTFSがUTF-16なのにどこで保存してるんだ？
セカンドストリーム？

207 ：デフォルトの名無しさん：2011/02/25(金) 22:31:47.81

なんか Cygwin についてごっちゃになってるっぽいので整理。

- Cygwin は 1.7 から UTF-8 Cygwin と同じような対応が入ってロケール設定がファイル名(の変換)に効くようになった。
- LANG=ja_JP.EUC-JP するとプログラムから見た場合にファイル名が EUC-JP になってるように見える。
　　プログラム内で EUC-JP のファイル名渡すと Cygwin API layer で UTF-16 に変換されて Wide API 経由でアクセスされる。
- Windows のファイルシステムで許可されない文字(例えば : とか)は Unicode のプライベートエリアの文字に変換される。
　Cygwin 上で見る場合は逆変換されるので普通に見える。

208 ：デフォルトの名無しさん：2011/02/25(金) 23:10:55.47

Mercurialのファイル名問題のほんとの理由は、コア開発者の中に、
非ASCIIファイル名を感情的に嫌ってるやつが居ることだから、
技術的にあれこれ言っても無意味。

209 ：デフォルトの名無しさん：2011/02/25(金) 23:34:44.37

>>207
まっとうな対応とは思うが、>>201の言ってることは何なんだ(苦笑

210 ：デフォルトの名無しさん：2011/02/26(土) 00:32:46.22

>>187
Unicode と言ったら、今は UTF-8 か UTF-32

211 ：デフォルトの名無しさん：2011/02/26(土) 00:39:59.28

>>210
お前の頭の中だけな。

212 ：デフォルトの名無しさん：2011/02/26(土) 00:41:32.04

Unicode が俺の頭の中にあったとは！
でも、お前さんらも使っていーよ。UTF-8 と UTF-32 ね。

213 ：デフォルトの名無しさん：2011/02/26(土) 00:49:19.48

>>212
WindowsでもJavaでも.NETでも頑張ってUTF-8かUTF-32使ってろ。
アホくさ。

214 ：デフォルトの名無しさん：2011/02/26(土) 00:50:59.24

>>213
Servlet ではもっぱら UTF-8 で入出力してるよ
過去のしがらみを引き摺ってる方がアホくさ

215 ：デフォルトの名無しさん：2011/02/26(土) 00:55:30.81

UTF-32（笑）

216 ：デフォルトの名無しさん：2011/02/26(土) 01:04:09.03

>>214
Servlet って Java か？
おもいっきり UTF-16 使ってるだろ。
クラス名だってUTF-16だぞ。文字列全部UTF-16だぞ。

っていうか、入出力って、外部エンコーディングの話してたの？
頑張ってUTF-16をdisってるみたいだけど、どこにファイルフォーマットや
ネットワーク転送時にUTF-16を使ってるバージョン管理システムがあるの？
それとも内部エンコーディングっていう単語の意味がわからなかったの？

217 ：デフォルトの名無しさん：2011/02/26(土) 01:07:07.26

>>216
Java の内部エンコーディングを俺が決められるなら UTF-16 なんて使わねえよ・・・
過去に遡って Java のエンコーディングを変える事が出来たとして UTF-16 を選ぶ人間は独りだけだろ
もっと足元の現実を見ようぜ

218 ：デフォルトの名無しさん：2011/02/26(土) 01:10:43.62

>>217
なんで？UTF-16って固定符号長だしUnicodeで定義されている文字を
全部表現できるし、どうせUTF-32にしたってメモリ使用量がほぼ倍になるのに
1文字1コードポイントにならないし、UTF-32に拘る理由なんてないでしょ。

219 ：デフォルトの名無しさん：2011/02/26(土) 01:15:24.95

>>218
何でって固定長の振りして実際は固定長じゃないからだよ。
プログラムで扱う文字列の殆どは数字とアルファベットだから UTF-16 にしたら
メモリ使用量が倍以上になるし、出力する際も UTF-8 が殆どなんだから、
変換するだけ処理時間の無駄。

今更、こんなどうでも良い事で抵抗しても何の意味も無いじゃん・・・

220 ：デフォルトの名無しさん：2011/02/26(土) 01:40:59.65

>>219
文字の符号数が固定でなくても、符号が固定長なのは処理の楽さに影響するよ。
UTF-8を処理する場合は、複数のバイト列から符号位置（序数）をデコードしたあと、
複数の序数を組み合わせて1つの文字を作る。
UTF-16やUTF-32を処理する場合は、16bit/32bitで直接符号位置（序数）が入っているから、
複数の序数を組み合わせて1つの文字を作るだけ。

UTF-8に対してUTF-16は、ASCII文字が大半を占めるときにメモリ効率が下がるという
デメリットと、処理が軽くなるというメリットがある。
ただし、CJKでは下がらないもしくは効率がよくなるケースもある。

これが UTF-16 に対する UTF-32 になると、ほとんどすべてのケースでメモリ効率が
2倍近く悪くなる上に、サロゲートペアの処理は無くなるものの、それ以外の結合文字の
問題はなくならないから処理はほとんど軽くならない。

20世紀に規格が決まったJavaだけでなく、2002年の.NET、2005年のQt4もUTF-16を
選んでいるのは、それなりにメリットがあるから。

221 ：デフォルトの名無しさん：2011/02/26(土) 01:49:29.33

>>220
それは今更 UTF-16 を使う理由にはならないよね

何でサロゲートペアやバイトオーダーを無視するの?
何で UTF-8 がデファクトとなっている世の中でわざわざ UTF-16 に変換するコストを無視するの?
何で CJK の文字列の中でも数字やアルファベットが多数含まれている事を無視するの?
何でそんな過去の技術に拘りたいの?

222 ：デフォルトの名無しさん：2011/02/26(土) 02:01:08.43

ご家庭用パソコンにメモリ4GBとかHDD2TBとかいう時代にメモリ効率はないわ～
文字列が可変長なんだから、文字も可変長になっててどこがいけないのか？
UTF-8マンセー！

223 ：デフォルトの名無しさん：2011/02/26(土) 02:01:33.18

>>221
サロゲートペアを考慮する必要があるケースって、文字単位で処理をしたい
場合だろうけど、UTF-32にしたって結合文字や異字体セレクタを扱う必要が
あるから、サロゲートペアの処理が入っても複雑さは殆ど変わらない。

もともと内部エンコーディングの話だからバイトオーダーの違いは無視できる。

CJKの文字列の中でも数字やアルファベットが多数含まれているが、
UTF-8だと3バイトでUTF-16だと2バイトで済む文字も多数あるので、
CJKでは容量のオーバーヘッドは充分小さい。
そして、UTF-16だとほとんどの文字が2バイトで最悪4バイトなのに対して、
UTF-32だと全部の文字が4バイトなので、2倍近くに容量が膨らむ。

UTF-16は過去の技術じゃない。

あと、なんで内部エンコーディングにそんなに拘るの？
もし bzr を dis るネタにしたいのであれば、FedoraでもUbuntuでもDebianでも
PythonがunicodeをUTF-32で扱ってるから、完全に筋違いだよ？
むしろ、そういった環境で長いファイル名をたくさん使うとメモリ効率が
悪いってdisるべき。

224 ：デフォルトの名無しさん：2011/02/26(土) 02:03:50.56

「UTF-16 は UTF-8 に比べてここが良いんですよ！」
「え、UTF-8 の方が良い部分がある? いやいや UTF-16 だって UTF-32 に比べたらマシですよ」

「UTF-16 は UTF-32 に比べたらここが良いんですよ！」
「え、UTF-32 の方が良い部分がある? いやいや UTF-16 だって UTF-8 に比べたらマシですよ」

225 ：デフォルトの名無しさん：2011/02/26(土) 02:07:14.76

肝心の UTF-16 は中途半端なだけで何のメリットも無くて残念

226 ：デフォルトの名無しさん：2011/02/26(土) 02:12:39.15

>>222
俺もそう思うわ。
↓こんな感じで、内部コードに UTF-8 を使用するのは十分リーズナブル。

http://practical-scheme.net/gauche/memo-str-j.html

227 ：デフォルトの名無しさん：2011/02/26(土) 02:20:15.47

>>224
俺は別にUTF-16最強と言いたいわけじゃなくて、UTF-16をレガシー扱い
するのは気が早いと言いたいだけだ。
>>225
中途半端とも言えるし、バランスがいいとも言える。
>>226
内部エンコーディングにUTF-8を使うのも十分ありだね。
Python も実装の内部でUTF-8を使えるようにしようという話は開発者の
間で議論されている。

228 ：デフォルトの名無しさん：2011/02/26(土) 02:22:47.15

いまどき、欧米人以外でUTF-32が固定長とか思ってる奴がいるんだな。
CJKの当事者としてもうちょっと勉強しようぜ。

229 ：デフォルトの名無しさん：2011/02/26(土) 02:22:50.71

>>227
拘ってないでレガシーだって認めちゃえよ
CJK の話だって無理があり過ぎなのは薄々感づいてるんだろ

230 ：デフォルトの名無しさん：2011/02/26(土) 02:26:01.13

>>228
『1コードポイントは固定長』という便利な表現をこのスレで学んだからな

231 ：デフォルトの名無しさん：2011/02/26(土) 02:45:02.44

とりあえずUTF-8なCygwinなら化けないようなので、
hgやGitをWindowsで使いたい人はCygwin使おうね、でFAということは分かった。
よく分からないけど、どうせIDEから使うんでしょ？　そうでもない？
IDEからCygwinのコマンド使ってもらえばオールオッケー？

232 ：デフォルトの名無しさん：2011/02/26(土) 02:46:54.04

cygwinからとかまるで使い物にならんな

233 ：デフォルトの名無しさん：2011/02/26(土) 02:49:11.61

ちなみにこのスレッドの dat ファイルのサイズは UTF-8 で 113564 bytes だけど、
UTF-16 だと 129222 bytes で、UTF-16 の方がファイルサイズが大きくなるよ。

日本語の掲示板でこれなんだから、英語のテキストや数値データファイル、地図データ、
ログファイル等々、CJK 文字が殆ど入らないデータを UTF-16 で扱えばどれだけ
無駄が発生する事か・・・

234 ：デフォルトの名無しさん：2011/02/26(土) 02:58:37.03

GC付きのスイーツな言語処理系しか触ったことなくて、
文字列操作のコストがイメージできないからUTF-8とかUTF-32とか言えちゃうんだろ。
C, C++ とかで文字列処理のアルゴリズム組むとか、O記法の概念が分かれば、
「大抵のケースについてO(1)時間で処理できる」ということの重要性は分かるよ。

ついでに、メモリは増えたけど、アクセスはやたら遅いんだよ。昔から。
そんなにUTF-32使いたいならCPUが10GHzになってバス幅が1024bitになるまで寝てろ

>>233
それは外部エンコードディングの話じゃん
AAだらけのとことかでも比較してみろよｗｗ
しかもメモリをけちりたいくせに数値データを数値に変換する手間は惜しむのかよｗｗｗ

235 ：デフォルトの名無しさん：2011/02/26(土) 03:06:04.80

>>234
何でこんな簡単な話を理解出来ない振りをするのか分からんけど、

1. dat ファイルは SJIS
2. それを内部エンコーディングが UTF-8 の処理系で読み込んだら 113564 bytes になる
3. UTF-16 の処理系で読み込んだら 129222 bytes になる
4. 非効率なのはどっち?

それ以外の下らない突っ込みにも返事して欲しい?
君の永遠に納得しないゲームに付き合う理由も無いけどね・・・

236 ：デフォルトの名無しさん：2011/02/26(土) 03:08:47.02

5. 元データが CJK 以外の場合だとどうなると思う?

237 ：デフォルトの名無しさん：2011/02/26(土) 03:13:01.59

そもそも、utf-8 vs utf-16 じゃなくて utf-8 or utf-32 vs utf-16 という
話だったと思うんだが。
utf-8 : utf-16 = 1:1.1～2
utf-16 : utf-32 = 1:1.9～2
つまり、utf-8とutf-16の効率の差よりも、utf-16とutf-32の差のほうが大きい。
utf-8 < utf-16 << utf-32
utf-8 と utf-16 の差をみてutf-16が非効率だと言うなら、utf-32はもっと
使いものにならない。

238 ：デフォルトの名無しさん：2011/02/26(土) 03:16:53.52

>>237
>>224

ダブスタ乙
それは都合の悪い時にもっと都合の悪い方を dis って誤摩化してるだけだろ

239 ：デフォルトの名無しさん：2011/02/26(土) 03:18:52.01

>>238
utf-16の非効率を指摘しながらutf-32はOKという自分のほうがダブスタ
だっていう認識はないんだな。。。

240 ：デフォルトの名無しさん：2011/02/26(土) 03:20:38.04

横からごめんよ。
よく分からんが、ここで争ってる文字コードは、どこで使う文字コード？
バージョン管理システム内だけで使う文字コードじゃないの？
それとも、各開発環境で使用してる文字コードを、
バージョン管理システムでは、わざわざ変換して保存するとかの話？

241 ：デフォルトの名無しさん：2011/02/26(土) 03:21:53.26

>>240
なんか内部エンコーディングと外部エンコーディングの区別もつかない奴が
暴れてるだけ。どの部分の文字コードの話とか全然話題になってない。

242 ：デフォルトの名無しさん：2011/02/26(土) 03:23:17.21

>>239
俺は UTF-8 の方が効率的だという話しかしていない。
君が勝手に UTF-32 と比較して UTF-16 を擁護しようとしているだけ。
当然 UTF-8 に対しては何の反論にもなっていない。

UTF-32 を採用する事があるとすれば、それは効率ではなく別の理由。

243 ：デフォルトの名無しさん：2011/02/26(土) 03:25:05.29

>>240
>バージョン管理システム内だけで使う文字コードじゃないの？

つ >>164

244 ：デフォルトの名無しさん：2011/02/26(土) 03:25:40.70

>>242
この議論はそもそも >>210 から始まったんだが。。。
UTF-16 を採用することがあるとすれば、それは効率と扱いやすさのバランス。

245 ：デフォルトの名無しさん：2011/02/26(土) 03:25:56.41

>>241
ふーん
バージョン管理システム内で使う文字コード(ログとか)なら、
開発環境に合わせて、好きな文字コード選べた方が良いし、
開発環境で使用してる文字コードを、変換して保存するとか
トラブルの元にしかならないからやめて欲しいのは俺だけか？

246 ：デフォルトの名無しさん：2011/02/26(土) 03:28:47.22

>>244
効率も悪いし、サロゲートペアが必須で扱い辛い文字コード乙

247 ：デフォルトの名無しさん：2011/02/26(土) 03:29:23.71

>>243
あーなるほどね。
そう言う話なら、ぶっちゃけどうでも良いや。

248 ：デフォルトの名無しさん：2011/02/26(土) 03:30:07.68

>>247
そう、ぶっちゃけどうでも良いのです。

249 ：デフォルトの名無しさん：2011/02/26(土) 03:30:08.18

つまり、ファイル名をunicodeで扱うかバイト列で扱うかという話に、
何故か今までWindows APIがUTF-16という点でしか登場する機会のなかった
UTF-16をdisり始めた >>210 が現れて、スルーできずにUTF-16の利点を
説明しだす奴が現れて、さらに何故かUTF-16がUTF-8より優れているという
議論をしていると勘違いしてる奴が現れた。

250 ：デフォルトの名無しさん：2011/02/26(土) 03:32:09.41

>>249
そして今、君が颯爽と現れてこれからこのスレを有意義な話題で盛り上げてくれる訳だ。

251 ：デフォルトの名無しさん：2011/02/26(土) 03:32:49.71

>>246
効率: UTF-8 < UTF-16 << UTF-32
処理しやすさ: UTF-32 < UTF-16 << UTF-8

効率と処理しやすさのどっちか片方しか必要ない場合は君の言うとおり。
どっちも必要な場合はバランスが良いフォーマット。

252 ：デフォルトの名無しさん：2011/02/26(土) 03:36:34.42

ファイル名なんて、システム依存なんだから、
文字コードを考えたって意味ないじゃん
むしろ、そのシステムで使えないファイル名を付ける奴が悪いってことじゃなくて？

253 ：デフォルトの名無しさん：2011/02/26(土) 03:39:34.62

>>251
結局、固定長を前提に出来ない時点で UTF-16 に処理し易さなんて無いよ
UTF-8 が ascii の範囲では固定長だから処理がし易いと言ってるのと同じ

254 ：デフォルトの名無しさん：2011/02/26(土) 04:02:39.82

utf8もutf16もutf32もサロゲートペア使って表せる範囲は全て同じでしょ？
基本的に処理なんて、変換位しかないし、一回書けば終わりなんだから
処理のしやすさなんて考えても意味ないじゃんって、突っ込んだら負けなの？
あと、変換とかで考えるとコードセパレート問題とか考える方が余程頭痛いけど…？
あぁ、結合文字とかも考えると、もっとめんどくさいのか…

255 ：デフォルトの名無しさん：2011/02/26(土) 06:50:22.82

utf16で盛り上がっているようですが、NTFSはutf16ではありません。ucs-2です

256 ：デフォルトの名無しさん：2011/02/26(土) 06:58:56.83

何その主張？
utf16じゃなくてutf-16とでも言いたいの？
それともucs-2はunicodeじゃないと言いたいの？

257 ：デフォルトの名無しさん：2011/02/26(土) 07:28:10.17

>>256
http://hibari.2ch.net/test/read.cgi/tech/1251208950/466-468

466 名前：デフォルトの名無しさん [sage]： 2010/11/27(土) 21:48:00
（略）
むしろ正規化されてないのはNTFSの方で、NTFSでは1つのファイル名でNFCとNFDの混在すら可能。
Windowsの日本語IMEはNFCしか吐かないので、NTFSはNFCで正規化されていると誤解されやすい
んだけど、ファイル名としてNFDな文字列やNFCとNFDが混在した文字列を指定した場合に、NTFS
で保存されるファイル名がNFCに正規化されるような事はない。（これは実際に試せば分かる）
（略）

467 名前：デフォルトの名無しさん [sage]： 2010/11/27(土) 21:57:34
NTFSのそれは (WCHAR)0 を含まない WCHAR列に過ぎないんじゃなかったっけ。
と思ったけど大文字小文字の話が合った。

468 名前：デフォルトの名無しさん [sage]： 2010/11/27(土) 22:05:47
WCHARも16ビット、32ビットあって単純じゃないのよね。
NTFSも本当にUTF-16なのか？という疑問もあるらしいし。
http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07

258 ：デフォルトの名無しさん：2011/02/26(土) 07:30:25.22

>>256
http://hibari.2ch.net/test/read.cgi/tech/1251208950/472
472 名前：デフォルトの名無しさん [sage]： 2010/11/28(日) 03:40:53
>468
Windows SDKが定義する16bitのWCHARという型って意味でWCHARって書いたんだけど、紛らわしかったか。すまん。
UNIXのファイル名がバイト列に過ぎないのと同様に、生き別れのサロゲートペアなんかも入れられたはず。BOMやU+FFFFも入るかも。

259 ：デフォルトの名無しさん：2011/02/26(土) 07:31:18.33

>>257
つ UTF-16 == UCS/Unicode Transformation Format 16

260 ：デフォルトの名無しさん：2011/02/26(土) 10:19:28.28

内部コードがUTF-いくつなんてどうでもいいだろ。
外から見て差が出るところを話そうぜ……。

261 ：デフォルトの名無しさん：2011/02/26(土) 10:30:56.66

>>260
うん。
bzrはいつになったら、コンソールでのエラーメッセージなどが日本語になるの？

262 ：デフォルトの名無しさん：2011/02/26(土) 10:34:13.89

bzrのアンチ活動とか不毛すぎるだろ……

263 ：デフォルトの名無しさん：2011/02/26(土) 10:37:46.68

>>262
svn/hgはメッセージ日本語化されているよ

264 ：デフォルトの名無しさん：2011/02/26(土) 10:41:05.75

自分が使う時にはいらないが、素人に使わせる事ような場合はメッセージが
日本語化されていると嬉しいかもしれんなぁ。

265 ：デフォルトの名無しさん：2011/02/26(土) 10:55:44.74

>264
素人がコンソールで使うわけ無いだろ。GUI必須。

266 ：デフォルトの名無しさん：2011/02/26(土) 10:55:58.34

どんだけdisっても、git、hg、bzrの三者は、向こう十年は使われ続ける体制ができちゃったし、
気に入らない物が残っちゃてご愁傷さまとしか言いようがない。

次の十年に向けての啓蒙活動を頑張ってください。

>>264
素人ならGUI使わせるんじゃないかな。

267 ：デフォルトの名無しさん：2011/02/26(土) 11:13:32.83

>>266
そして、素人のwindiff、kdiffが化けますというクレームに、玄人が対応できていません、と答えるのですね

268 ：methane：2011/02/26(土) 12:12:01.68

>>261
そろそろi18nしたいな。bzr-2.4までにできればやるよ。

>>267
bzr qdiff は、ファイルのエンコーディングをGUI上で選択できる
ようにはしておいた。玄人は素人にエンコーディングを教えて
あげてください。

269 ：デフォルトの名無しさん：2011/02/26(土) 12:42:29.67

>>268
WindowsでCP932で表すことができないファイル名のファイルはwindiff、kdiff3立ち上げられないよね？
cmd.exeでdiffしたとき、ファイルの中身がutf-8だった場合、激しく化け化けになるよね？

270 ：methane：2011/02/26(土) 15:15:05.28

>>269
前者は何とかする予定。
後者はさすがに無理ゲー（勝手にdiffの出力を変えたらpatchが動かない）なので
プラグイン作ってオプションで回避するかな。
俺は | gvim - で見てる。

271 ：デフォルトの名無しさん：2011/02/26(土) 15:23:25.20

>>270
ということは、bzrのパッチもLinuxではロケール依存なのですね？
Windowsで作成されたパッチをLinuxであてるには、ja_JP.SJISでチェックアウトしないといけないのですね？

272 ：methane：2011/02/26(土) 15:37:40.65

>>271
何処をどう読めばそうなるんだろう…？
ファイル名をロケール関係なく出力するからwindowsのコマンドプロンプトに
utf-8のファイルの内容を出力すると化けるんであって、それをリダイレクトで
patchファイルにしてLinuxに持って行ってpatchできるよ。

ただし、ファイル名はロケール依存になっちゃってるから、日本語ファイル名の
patchを作るときにはdiffは使えなくて、代わりにbundleという形式を使う。

273 ：methane：2011/02/26(土) 15:38:21.18

あ、間違えた。
s/ファイル名をロケール関係なく/ファイルの内容をロケール関係なく/

274 ：デフォルトの名無しさん：2011/02/26(土) 15:42:10.39

bzrのcmd.exeの標準出力はCP932だよね？
ファイル名がCP932でファイルの中身がUTF-8の場合。
これを化けずにどうやって読むのでしょうか？

275 ：methane：2011/02/26(土) 15:46:43.42

>>274
そのケースではファイル全体を化けないように観るのは無理。
GUI使うかコマンドラインでも変換するプラグインを使って。

276 ：デフォルトの名無しさん：2011/02/26(土) 15:50:34.51

>>275
そのプラグインとは？

277 ：methane：2011/02/26(土) 16:18:29.23

>>276
http://gigo-ice.org/scm/bazaar/plugins/encdiff.html

278 ：デフォルトの名無しさん：2011/02/26(土) 16:49:58.73

UTF-256とか作っちまえよ

279 ：デフォルトの名無しさん：2011/02/26(土) 16:52:14.55

>>278
スレ違い
http://hibari.2ch.net/test/read.cgi/tech/1278923059/781

280 ：デフォルトの名無しさん：2011/02/26(土) 18:07:45.87

使える文字が増えれば良い訳じゃない
増えたら、増えたで、また、やっかいな問題が出てくるもんだ

281 ：デフォルトの名無しさん：2011/02/26(土) 19:49:35.74

>>231
IDEを使うなら、utf-8ロケールのLinuxデスクトップで、
EclipseならGit、NetbeansならMercurialを使うことでオールオッケー

282 ：デフォルトの名無しさん：2011/02/26(土) 20:26:39.66

どでもいいんだが, プロジェクトが Unix 前提で構築されてて
ファイル名の銘々規則が
<module-name>:<function>.<ext>
な, VCS に MS Windows でつないでファイル名が
読めないって騒ぐのはよしてほしい

はなっから命名規則がやばいんで Windows からみると,
まともなファイル名は見えないって言ってるのにw

283 ：デフォルトの名無しさん：2011/02/27(日) 00:59:26.45

どうでも良いと言いつつ、文句を言う奴っているよね

284 ：デフォルトの名無しさん：2011/02/27(日) 01:03:08.98

最近の本を見るとbzrを以上に推してるな
最近の本で言えばプログラマが覚えるべき○○の事とかも最初にbzrの名前が挙がってた
だから他の分散管理はもっとがんばれ
勢いがいないぞ

285 ：デフォルトの名無しさん：2011/02/27(日) 01:23:27.31

>>184
うん、いいと思うよ。俺も一人だけ作業ならそうしてる

286 ：デフォルトの名無しさん：2011/02/27(日) 05:42:50.73

>>284
git, hgの本は売っているけど、bzrの本は売ってる？

287 ：デフォルトの名無しさん：2011/02/27(日) 05:47:23.01

売ってない気がする
bzrはアジャイル設計とかそういうプロジェクト管理系の本でよく見かけるようになったね

288 ：デフォルトの名無しさん：2011/02/27(日) 06:23:31.25

>>284
git, hg本体は枯れていて安定期に入ってるから勢いが無いようにみえるかもしれない
TortoiseHg 2.0 が３月１日に出る予定なので、hgは勢いつくかもしれない
いろいろ目玉はあるけど、このスレ的には、MacOSX対応かな？

289 ：デフォルトの名無しさん：2011/02/28(月) 01:10:26.03

>>133
Debian LinuxではGitは2010/04/03まではgit-coreパッケージ、それ以降はgitパッケージです。
2008/01/10にgitパッケージ(Gitとは別物)がgnuitに改名されました。
2010/04/03にgit-coreパッケージがgitに改名され、git-coreはgitのダミーパッケージになりました。
ダミーパッケージをインストールすると自動的に本来のパッケージもインストールされます。
つまり、Debian LinuxにおけるGitのインストール数は、
2010年3月まではgit-coreのグラフ、2010年後半からはgitのグラフで表されます。
GitはすでにCVSを越え、今年中にSubversionを越えそうです。

Popularity contest statistics for bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion
http://qa.debian.org/popcon-graph.php?packages=bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion&show_installed=on&want_legend=on&beenhere=1

http://packages.debian.org/changelogs/pool/main/g/gnuit/current/changelog.html#versionversion4.9.2-1
gnuit (4.9.2-1) unstable; urgency=low
> * Package name changed to gnuit.
> * Added transitional git package.
> -- Ian Beckwith <[email protected]> Thu, 10 Jan 2008 22:04:26 +0000

http://packages.debian.org/changelogs/pool/main/g/git/current/changelog#versionversion1:1.7.0.4-2_exp0
git (1:1.7.0.4-2~exp0) experimental; urgency=low
> * debian/control, debian/rules, debian/git-core.*: change source and
> binary package name from git-core to git; keep now obsolete empty
> git-core package that depends on git for upgrade (see
> http://lists.debian.org/debian-devel/2009/09/thrd2.html#00661).
> -- Gerrit Pape <[email protected]> Sat, 03 Apr 2010 15:07:19 -0500

290 ：デフォルトの名無しさん：2011/02/28(月) 17:37:23.77

>284
全然見ないよ。
最近は、本そのものをね。
bzrは、btrfsと同じで名前が途轍もなく格好悪いので
geek心をくすぐらないと思う

>>288
OSX対応って・・・MacHgで十分だったんだけど・・・
Finderに統合って、結構鬱陶しいってことがSubversionの時に分かったし・・・

291 ：デフォルトの名無しさん：2011/04/01(金) 03:23:44.79

Monotone が 1.0 になったみたいだけど、国際化対応とかユーザー認証の暗号化とかあるし、
期待してもいいんだろうか。

292 ：デフォルトの名無しさん：2011/04/02(土) 20:39:47.88

あげたら

293 ：デフォルトの名無しさん：2011/04/02(土) 20:48:33.91

431 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 21:52:13
>430
＞リポジトリデータはSQLiteで管理する。

キモの部分が他人任せかよ。

432 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:09:21
キモかどうかは判断が分かれるな
バックエンドの処理については実装部分の話で速度に影響する
もしmonotoneが速かったらGITもMercurialも産まれてなかったかもしれない

433 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:14:39
http://po3a.blogspot.com/2007/12/subversion.html
> もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
> ほんとに。連中は「本物のデータベース」を使っているよ。
> 「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
> 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
> これらすべての設計上の決定のために、できてきた結果はゲロゲロで
> 保守不可能なカオスだ。

294 ：デフォルトの名無しさん：2011/04/02(土) 20:49:36.36

434 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:29:00
ｹﾁｮﾝｹﾁｮﾝだなｗ
Cが至高なのは同意だが

435 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:42:13
Linus は最初 BitKeeper に変る SCM でMonotone を最有力に挙げていたが、
動作速度が遅いから Linus版 Monotone としてGitを作ったんだよな。

436 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:42:59
そこは別にいいんじゃね？

437 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:44:07
しょっちゅう使うツールは速いが正義なんだよなぁ。

438 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:48:02
で、Monotoneは、user-visibleなとこでは、どの辺に新規性があるわけ？
公開鍵がどうこうのあたり？

439 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 23:00:55
Monotone はファイル名をUTF-8に変換して管理してる。
これは Git に持ち込まなかった概念で、速度を犠牲にしたバカげた設計だと
Linus は思ったのだろう。

295 ：デフォルトの名無しさん：2011/04/02(土) 23:53:55.07

速度を犠牲にしたバカげた設計をしてしまったのがSubversionとBazaarかw

296 ：デフォルトの名無しさん：2011/04/03(日) 01:08:09.17

ttp://www.infoq.com/news/2011/04/haskell-git

297 ：デフォルトの名無しさん：2011/04/03(日) 02:51:43.75

SubversionはCなのに遅いからなぁ。あの遅さはUTF-8のせいだけじゃないんじゃないか。
まあでもCVSの代替としては長く使わせてもらったし、あの時点では最良だったと思う。

298 ：デフォルトの名無しさん：2011/04/03(日) 03:14:47.45

結局、どれもこれも帯に短し襷に長し、決定版と言うのはないのかね？

299 ：デフォルトの名無しさん：2011/04/03(日) 21:22:38.97

ないから色々あるんじゃないか？

300 ：デフォルトの名無しさん：2011/04/03(日) 21:26:45.16

帯も襷もあるが、襷としても使える帯は無いし、
帯としても使える襷は無い、ということか。

301 ：デフォルトの名無しさん：2011/04/06(水) 22:47:50.27

>>296
> The two leading distributed version control systems are Git and Mercurial,
> with Darcs, Bzr and others much less widely used.
> Typically the systems are used by their language implementers;
> Darcs, by Haskell developers, Mercurial by Python developers and Git for C developers.

302 ：デフォルトの名無しさん：2011/04/08(金) 10:18:19.21

Subversionのしかもwindows版TortoiseSVNから使い始めた俺は
遅くてもこんな物なんだろうと思っているからきっと幸せ。

つーか、俺、最初に手をつけた物が良いという思い込みが強くて
なかなか移行できない性格で難儀。

303 ：デフォルトの名無しさん：2011/04/08(金) 11:24:36.98

>>302
VSSに触らなくて良かったな

304 ：デフォルトの名無しさん：2011/04/08(金) 14:53:29.00

パスが含まれているようなファイルはどう管理したらいいのですか？
オープンなリポジトリにそのままコミットするわけにはいかないと思うので。

305 ：デフォルトの名無しさん：2011/04/08(金) 14:56:19.22

2文字読んでpathかと思ったらpasswordか。

* sensibleなデータだけ別ファイルになるような構成にして、リポジトリに入れないようにする。
* 暗号化したものを入れておいてデコード手段はリポジトリに入れないようにする。

など。

306 ：デフォルトの名無しさん：2011/04/08(金) 15:38:36.19

パスワードは環境変数にしてるなあ。仕事じゃないけど。

307 ：デフォルトの名無しさん：2011/04/08(金) 17:35:21.28

なるほど・・・参考になりました！
ありがとうございます。

308 ：デフォルトの名無しさん：2011/04/13(水) 14:20:21.44

これからバージョン管理を導入しようと思い調べたのだけれど、
有名どころだけでも結構あるんだね。

数人で1プロジェクトのソースが100ファイルで合計1MBに満たない
ようなレベルならTortoiseSVNあたりで十分かな？
ネット上の情報も一番多い感じなので、取っつきやすいと感じた。

それとも、今から覚えるなら、こっちにしておけっていうのあります？

309 ：デフォルトの名無しさん：2011/04/13(水) 14:33:52.97

やっぱsvnが無難でしょ。
TortoiseSVNってことはWin環境なんだろうけど、サーバー側はVisualSVN Serverを勧めておく。
さらにVisual Studio使ってて金が出せるなら、AnkhSVNよりVisualSVNがお勧め。
何だかんだ言って、インテグレーションの出来が違いすぎる。

310 ：デフォルトの名無しさん：2011/04/13(水) 15:48:40.56

>>309
ありがとう。
ちょっとVisualSVN Server、VisualSVNこの辺を調べてくる。
名前が似てるけど、全然別物なのか。

311 ：デフォルトの名無しさん：2011/04/13(水) 19:54:25.29

VisualSVNそんなに良いの？いくらするんだっけ？

AnkhSVNもまあまあ悪くはないかと思ったけど

312 ：デフォルトの名無しさん：2011/04/13(水) 23:17:07.73

AnkhSVNでも入れないよりは全然マシ。

今やってるプロジェクトはそれすら使っていないから
VS上でファイル名変更されると履歴が参照できずバージョン管理の意味が無くなってる。

313 ：デフォルトの名無しさん：2011/04/14(木) 02:06:48.18

Mercurialなら、名前変更の推定処理が出来るのに。

314 ：デフォルトの名無しさん：2011/04/14(木) 02:18:52.78

Hgもリネームは推定なのか。Gitもそう。

315 ：デフォルトの名無しさん：2011/04/14(木) 05:50:39.51

>>314
hg addremoveコマンドが推定。"--similarity 類似度"でパーセントを指定できる。
ファイルの移動はリポジトリに記録される。

316 ：デフォルトの名無しさん：2011/04/14(木) 14:42:44.77

>>315
え、移動はリポジトリに記録される、けどリネームは推定なの？
リネームと移動は同じじゃないか…？

317 ：デフォルトの名無しさん：2011/04/14(木) 14:57:42.25

>>316
hgのファイルの移動はコピーして削除。これはリポジトリ（マニフェスト）に記録される。
コピーしたものもマージ時に反映される。

ファイルの移動はhg renameコマンドを使うのが一般的。

hg addとhg removeコマンドがあって、それぞれ、ファイルを追加したとき、削除したとき、
パラメータ無しで追加、削除を自動的に認識するコマンド。

hg addremoveはそれを合体させたもので、--similarity 100がデフォルトの値で、
ファイルが改変されていないものは移動と認識されて、commit時にそれが反映される。

318 ：デフォルトの名無しさん：2011/04/14(木) 15:11:44.05

>>317
＞これはリポジトリ（マニフェスト）に記録される
「コピーして削除」のみならず「移動」としての情報が記録されるということ？

つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな？
それとも--similarity 100の時だけ「移動」として特別に記録？

319 ：デフォルトの名無しさん：2011/04/14(木) 15:46:11.01

>>318
> ＞これはリポジトリ（マニフェスト）に記録される
> 「コピーして削除」のみならず「移動」としての情報が記録されるということ？
リポジトリ（マニフェスト）には、コピーしたというのと削除したというのが別々に記録される。
aaa -> bbb
・bbbはaaaのコピー
・aaaは削除

> つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな？
> それとも--similarity 100の時だけ「移動」として特別に記録？
hg addremoveがファイルの移動をコピーと削除として判断する。
hg status のオプション"--copies"で確認可能。
この結果をcommitで確定させる。

320 ：デフォルトの名無しさん：2011/04/14(木) 17:17:45.25

>>319
なるほど、そうなるとsvnと似たやり方かな。
Gitはそういうの一切記録しなくて、履歴を表示する時に動的に分析してる。
全く同時期に同じ目的で開発されたものだけど、けっこう違うんだねえ。

321 ：デフォルトの名無しさん：2011/04/15(金) 06:18:40.99

Goodbye Subversion, Hello Mercurial: A Migration Guide
http://blogs.atlassian.com/developer/2011/03/goodbye_subversion_hello_mercurial.html

322 ：デフォルトの名無しさん：2011/04/25(月) 09:25:35.79

ひさびさにTortoiseHgをあぷでとした
チャンクごとのコミットが面倒なことになってないかい
なんだよこれ

323 ：デフォルトの名無しさん：2011/04/25(月) 10:18:19.53

>>322
TortoiseHg 2.0の大幅なユーザインターフェースの更新に抵抗がある方は、
1.1.xの最新版を使うことをお勧めします。
https://bitbucket.org/tortoisehg/stable/downloads

324 ：デフォルトの名無しさん：2011/04/25(月) 10:37:51.10

そうですか
よくみたらメジャーアップデートしてたんだ
日本語の方マニュアルやリリースノートも更新してくれればなあ！

325 ：デフォルトの名無しさん：2011/04/25(月) 20:04:58.45

Git 1.7.5がリリース、メッセージの国際化へ一歩
http://www.atmarkit.co.jp/news/201104/25/git.html

326 ：デフォルトの名無しさん：2011/04/25(月) 21:03:39.77

日本語ファイルが使えるならgit一択なのにな

327 ：デフォルトの名無しさん：2011/04/25(月) 21:06:26.08

>>326
使えるよ

328 ：デフォルトの名無しさん：2011/04/25(月) 21:09:21.90

あれ、そなの？
Win、Mac、Linuxの環境でsvnのように何の問題もなくなったの？

329 ：デフォルトの名無しさん：2011/04/25(月) 21:11:41.67

>>328
さて、svnのどこが何の問題が無いのでしょうか？

330 ：デフォルトの名無しさん：2011/04/25(月) 21:37:51.11

Git一択というほどGitいいのか。
今、MercrialとBazaarを試用しているけれど、Gitも試してみるか。

331 ：デフォルトの名無しさん：2011/04/25(月) 23:10:29.20

>>329
日本語のファイルの取り扱いが問題ありません
他はすべて日本語の扱いに問題有り

332 ：デフォルトの名無しさん：2011/04/25(月) 23:28:01.24

>>331
つ>>8
svnも問題あり、というよりマルチプラットフォームで問題ないものは無い。

333 ：デフォルトの名無しさん：2011/04/25(月) 23:28:50.00

>>332
それは既にパッチあるだろ

334 ：デフォルトの名無しさん：2011/04/25(月) 23:30:51.91

パッチどころか本家で既に対応済み
何年前の話だよ…

335 ：デフォルトの名無しさん：2011/04/25(月) 23:51:51.89

で、bzrも2.3だといけるらしい。

336 ：デフォルトの名無しさん：2011/04/25(月) 23:53:23.91

gitとhgｵﾜﾀｗ

337 ：デフォルトの名無しさん：2011/04/26(火) 00:20:04.65

svnは対応はできていません。
http://subversion.tigris.org/issues/show_bug.cgi?id=2464
bzrもだめです。
https://bugs.launchpad.net/bzr/+bug/172383

338 ：デフォルトの名無しさん：2011/04/26(火) 00:26:22.54

OSXなんて捨て捨て

339 ：デフォルトの名無しさん：2011/04/26(火) 00:28:10.54

windowsとlinuxとの連携ならsvnとbzrが最強なんだっけか？

340 ：デフォルトの名無しさん：2011/04/26(火) 01:10:25.90

ユニコードに過度な期待は禁物です

341 ：デフォルトの名無しさん：2011/04/26(火) 08:48:59.32

http://iup.2ch-library.com/i/i0291902-1303775239.jpg

342 ：デフォルトの名無しさん：2011/04/26(火) 09:05:53.42

>>337
Mac ports の svn は対応パッチ済みです。
bzr も完全に解決したかの確認がまだだけど、2.3で現在までに報告されている
ケースは解決されています。

Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の
扱いには満足していたんだし、Mac OS X の問題もとりあえず対応策が広まったし、
Unicodeでファイル名を扱うことを危険だと叫んでるのはただのFUD
Unicodeはすべての問題を解決してくれるわけではないが、文字コード周りの問題に
対するコストパフォーマンスの高い対応策。

343 ：デフォルトの名無しさん：2011/04/26(火) 09:15:25.50

>>342
GitとMercurialでファイル名に「ユニコード」が使えないという誤解を相変わらずバラ撒いている方がFUD

344 ：341：2011/04/26(火) 09:21:33.19

言い忘れたけど上の画像はOSXね

345 ：デフォルトの名無しさん：2011/04/26(火) 09:22:06.40

>>343
このスレでだれがそんなFUDを言ってる？
それとも、Mac OS X のNFD(モドキ)正規化問題に対応できてないというのがFUD？

346 ：デフォルトの名無しさん：2011/04/26(火) 09:22:54.02

>>342
> Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の
> 扱いには満足していたんだし、

満足なんかしてないよ。
波ダッシュとかの問題とか考えれば、永続的にメンテが必要なシステムに
ファイル名変換が行われるものなんか使わないよ。

347 ：デフォルトの名無しさん：2011/04/26(火) 09:23:56.85

>>344
Windowsでばーかというファイルを作成してMacでチェックアウトして
編集せずに git diff したら、何もしてないのにファイル名が変更されたって
報告されない？

348 ：デフォルトの名無しさん：2011/04/26(火) 09:26:52.41

>>345
つ>>208

349 ：デフォルトの名無しさん：2011/04/26(火) 09:27:11.56

>>347
GitHubにでもレポ作ってくれれば試すよ
興味あるし

350 ：デフォルトの名無しさん：2011/04/26(火) 09:30:01.93

>>346
たしかに、みんなは言い過ぎだな。
でも、波ダッシュ問題もWindowsだったらUTF-16で、LinuxやMacではUTF-8で扱えば
一切Shift-JISとの変換なんて起こらないし、多くの人は一部の文字が使えない
ことよりもリポジトリ内に複数の文字エンコーディングのファイル名が混ざる事や
たくさんの独自パッチ済みクライアントが乱立する方が管理が面倒だと感じて
CVSからSubversionへの変化を喜んでいた。

WinCVS日本語版でみんなこのオプション使いましょーねというルール決めても時々
設定間違ってコミットする人がいてリポジトリの内容が文字化けしていた時代に
戻りたいという人がどれくらいいるか。

351 ：デフォルトの名無しさん：2011/04/26(火) 09:30:43.31

>>347
gitは知らんが、hgはMacユーザがaddremoveすればWin/Linux/Macユーザみんなハッピー

352 ：デフォルトの名無しさん：2011/04/26(火) 09:34:07.00

>>349
https://gist.github.com/941544/
git clone git://gist.github.com/941544.git

353 ：デフォルトの名無しさん：2011/04/26(火) 09:35:06.00

>>351
Windows の hg って utf-8 ファイル名まともに使えるようになったんだっけ？

354 ：デフォルトの名無しさん：2011/04/26(火) 09:36:39.26

>>353
cygwin、fixutf8

355 ：デフォルトの名無しさん：2011/04/26(火) 09:37:13.47

>>351
あと、その方法だとLinux/Winユーザーがpullしてファイル名がNFDになると、
コマンドラインからファイル名指定するときに普通に日本語入力システムで
変換するとNFCになっちゃうからファイル名指定できなくて全然ハッピーじゃない。

356 ：デフォルトの名無しさん：2011/04/26(火) 09:39:58.20

>>354
fixutf8 ってもう安定して使えるのかな。TortoiseHGとの連携大丈夫？

cygwinを使う方法については、cygwinが必要だというのを明示せずに
「utf-8使えるよ」というのは、まどかシステム以前のQBのような気がするので、
ちゃんと「cygwin使えばutf-8使えるよ」と言って欲しい。

357 ：デフォルトの名無しさん：2011/04/26(火) 09:40:24.04

>>355
hgでコマンドラインでファイル名指定するのはhg log FILEぐらい。
hg add/remove/addremoveは自動認識するし。

358 ：デフォルトの名無しさん：2011/04/26(火) 09:43:16.46

>>357
チェックアウトしたファイルを開こうとして
$ vim ばーか.txt
ってやる場合を考えると、hgで直接ファイル名指定する機会が少ないというのは
リポジトリ内にNFDを突っ込む問題の一部しかカバーできてないと思う。

359 ：デフォルトの名無しさん：2011/04/26(火) 09:47:23.72

まとめ
日本語を使うのなら、、
集中型ならsvn
分散型ならbzr

日本語は使わないのなら、、
速いのが好きならgit
googleが好きならhg

360 ：デフォルトの名無しさん：2011/04/26(火) 09:49:21.95

>>358
たしかに「ば」が先頭だとシェル補完が厳しいなぁ・・・

361 ：デフォルトの名無しさん：2011/04/26(火) 09:49:36.10

>>352
git diffだと何も表示されないがgit statusだとUntracked fileとして表示されるね
WindowsのMsysGitを使った場合だとLinuxやMacではこういうことが起きるのか
勉強にはなったが、どうしようかなあ

362 ：デフォルトの名無しさん：2011/04/26(火) 10:40:10.09

ソースコードの中身ならまだしも、ファイル名に日本語とか情弱の極みだろ

363 ：デフォルトの名無しさん：2011/04/26(火) 11:18:24.43

まだ>>362みたいなことを言ってる馬鹿がいるんだな

364 ：デフォルトの名無しさん：2011/04/26(火) 11:23:43.49

ぶっちゃけどのバージョン管理システムかの問題じゃなくてWindowsの問題だよね

365 ：デフォルトの名無しさん：2011/04/26(火) 11:29:07.24

ファイル名はutf-8ではなくutf-7にしよう

366 ：デフォルトの名無しさん：2011/04/26(火) 13:08:35.45

自分、英語がプアなもんでファイル名に日本語が欠かせません！

英語にしてもそこそこ把握できる場合（予想）
『ワルプルギスの淫夢.txt』
『奴隷少佐ルクレツィア.txt』

英語にしたら把握に時間がかかるか訳がわからない場合（予想）
『目覚めると従姉妹を護る美少女剣士になっていた.txt』
『俺のフラグはよりどりみデレ.txt』

というような場合もあるんじゃないかな？
仮定、想像の話だけど。

367 ：デフォルトの名無しさん：2011/04/26(火) 13:36:52.35

確かにそうだな。
それはそれとして、そのtxtの中身について話をしたいのだが。

368 ：デフォルトの名無しさん：2011/04/26(火) 13:45:20.85

非実在テキストファイルですから。
何分、仮定、想像の話なので。

369 ：デフォルトの名無しさん：2011/04/26(火) 14:22:22.90

>>364
Windowsはutf-16 のAPIを提供しているのでそれを使えば問題ない。
どっちかっつーと、Mac OS X の方が、バージョン管理システムに限らず
ファイルをアップロードするときとか、zipファイルの中身とかいろんな
場面に影響するので凶悪。

370 ：デフォルトの名無しさん：2011/04/26(火) 14:49:34.62

>>369
ファイル名の話してんのに何言ってんの？
論点のすり替え乙

371 ：デフォルトの名無しさん：2011/04/26(火) 16:19:32.78

>>370
ファイル名の話だよ？
Windowsは10年以上昔(NT 4.0)からファイル名はUnicodeで扱っている。
Shift-JISなどでアクセスするAPIはレガシー用の互換APIで、基本的に使うべきではない。

372 ：デフォルトの名無しさん：2011/04/26(火) 16:23:47.02

厳密に言えば NT 3.1 (93年) だけど、サーバー、ワークステーション向けを
のぞいたらWinXP (01年) だから、10年以上ではないな。

373 ：デフォルトの名無しさん：2011/04/26(火) 16:24:17.13

いやだからファイル名の
話だろ？

374 ：デフォルトの名無しさん：2011/04/26(火) 16:24:26.87

Mercurialは、pythonがクソでレガシーAPI使ってるのが癌なんだろ。

375 ：デフォルトの名無しさん：2011/04/26(火) 16:25:13.49

あ
最新レス見ずに書いちゃった

376 ：デフォルトの名無しさん：2011/04/26(火) 16:27:30.17

>>374
Python はどちらでも扱えるようにしている。
open(u"ほげ") ならUnicode APIで、open("ほげ") ならASCII APIを使う。
bzrは前者、mercurialは後者を使ってる。

cygwin は、 fopen("ほげ"); すると、 "ほげ" を utf-8 でデコードして、
UTF-16にエンコードして、 CreateFileW に渡している。

377 ：デフォルトの名無しさん：2011/04/26(火) 16:31:31.57

>376
それがクソって言ってんの

378 ：デフォルトの名無しさん：2011/04/26(火) 16:34:02.13

>>377
えー、これがクソならどうしろと、、、
C#やJavaみたいにバイト列でファイルパスを指定するの禁止したらUnix系で
すごく使いにくくなるんだけど。
Python の仕様は超現実的で、RubyやPerlよりもずっとWindowsで使いやすいと
思ってる。

379 ：デフォルトの名無しさん：2011/04/26(火) 17:11:59.63

というかそれならMercurialで問題になってるのは何なの

380 ：デフォルトの名無しさん：2011/04/26(火) 18:26:12.29

>>379
http://mercurial.selenic.com/wiki/EncodingStrategy

381 ：デフォルトの名無しさん：2011/04/26(火) 18:29:23.48

>>379
英語のwikiにはNTFSはUTF-16となっているが、実際は２バイトのバイト列。
UTF-16としては不正な値も格納される。

382 ：デフォルトの名無しさん：2011/04/26(火) 18:33:09.11

NTFSがUTF-16とは書いていないか。
> kernel has a mix of byte-width and wide character APIs

383 ：デフォルトの名無しさん：2011/04/28(木) 10:45:25.11

Windowsシステムオンリー。日本語ファイル名あり。日本語ディレクトリあるかも。
Git、Mercurial、Bazaarから、上記の条件で考えた場合、分散型初心者が取っつき
やすいのは日本語対応が進んでいるBazaarでしょうか？

384 ：デフォルトの名無しさん：2011/04/28(木) 11:04:37.41

その条件ならシェル統合がまともに動くMercurialじゃないか

385 ：デフォルトの名無しさん：2011/04/28(木) 11:10:24.25

Bazaarは日本語対応進んでいないでしょ。

386 ：デフォルトの名無しさん：2011/04/28(木) 11:15:43.07

Windows onlyならhg、bzrのどちらでもいいと思う
でかいファイルを扱うならhgかな

387 ：デフォルトの名無しさん：2011/04/28(木) 11:16:05.67

書籍の有無、Web上での情報量、CUI/GUIのメニューの日本語化を含めて日本語対応と言うべきであって、
Mercurialが一歩抜き出ていて、CUI/GUIのメニューは >>325 でGitも対応する方向だと言う認識だが。

388 ：デフォルトの名無しさん：2011/04/28(木) 11:18:50.31

bitbucketとlaunchpadなら断然bitbucket
githubの方がもっといいけど

389 ：デフォルトの名無しさん：2011/04/28(木) 11:19:07.53

分散だと日本語環境はbzrが独占状態なのよねぇ。
他は何をやってんのやら。

390 ：デフォルトの名無しさん：2011/04/28(木) 11:23:24.89

>>389
> 分散だと日本語環境はbzrが独占状態なのよねぇ。
> 他は何をやってんのやら。
「Windowsのファイルシステムの」日本語環境でしょ。
Windows上で日本語ファイル名を使わなければ、Git、Mercurialでは何も不自由しないけど。

391 ：デフォルトの名無しさん：2011/04/28(木) 11:27:13.00

そうはいっても
○○支社向け.docとか
○○部長月間予定.xlsとか
いう日本語ファイル名って結構使うからねぇ

392 ：デフォルトの名無しさん：2011/04/28(木) 11:31:50.17

>>391
リポジトリを分ければ良い。
そういうファイルがあるところだけsvnにすれば良い。
svnはリポジトリを一ヶ所にするというのが一般的のようだが、
別に一ヶ所にする必要もない。

393 ：デフォルトの名無しさん：2011/04/28(木) 11:35:09.66

運用ポリシーで複数の管理システムを使うのはちょっとね
後々の事を考えてシンプルにしないとさ

394 ：デフォルトの名無しさん：2011/04/28(木) 11:46:48.22

Windowsだけで使う分にはHgでも日本語ファイル問題ないだろ？

395 ：デフォルトの名無しさん：2011/04/28(木) 11:48:38.19

>>394
CP932に無いUnicodeの文字も増えてきているからねえ・・・

396 ：デフォルトの名無しさん：2011/04/28(木) 14:21:26.83

○○支社向け.docとか○○部長月間予定.xlsとかは分散してる必要無いんじゃないか。
どうせマージ出来ないだろうから、むしろ分散してたら不都合な気がする。
そういうのはsvnでいいんじゃね。

397 ：デフォルトの名無しさん：2011/04/28(木) 14:50:19.02

>>396
Mercurialはロックを実装する気でいるぞ。
http://mercurial.selenic.com/wiki/LockExtension/NewDesign

398 ：デフォルトの名無しさん：2011/04/28(木) 15:39:09.50

>>397
分散型でlockとかｗｗｗ
というのは釣りですが、それでワークフローがうまく回るなら良いですね。
特に仕事でアジャイル（）とかだと分単位で作業が入り乱れるだろうから、
バグトラッカとかでやりとりするよりもスムーズかも知れない。

399 ：デフォルトの名無しさん：2011/04/28(木) 15:39:15.31

かといって、1プロジェクトに関わる設計書とかが単一の管理から外れるのも困る。
結局のところ、運用でごまかせって感じになっているのがなぁ。
誰だよ1バイト圏意外に住んでいるやつは。

400 ：デフォルトの名無しさん：2011/04/28(木) 16:10:18.30

>>396
中央リポジトリ関係無く好きに各ローカルリポジトリにプッシュ/プル出来るから分散のメリットは大ありだよ
人間の相関と分散管理はすごく相性がいいから無駄なんていっちゃいかん

401 ：デフォルトの名無しさん：2011/04/28(木) 16:13:02.54

×無駄なんて
○不都合だなんて
失敬

402 ：デフォルトの名無しさん：2011/04/28(木) 16:41:36.52

>>400
ワードとかエクセルのマージ作業はどうするの？

403 ：デフォルトの名無しさん：2011/04/28(木) 16:43:59.18

それって別に分散かどうかは関係ないよね

404 ：デフォルトの名無しさん：2011/04/28(木) 16:49:45.42

>>403
マスターリポジトリにプッシュするまでもない物をとりあえず確認するために
個人のローカルリポジトリにアクセスしたりとか
個別相談受けて訂正する時にその人のローカル除いたりとか色々ある
メッシュ網じゃないsvnなんかじゃこういうのは出来ないのさ

405 ：デフォルトの名無しさん：2011/05/01(日) 14:39:55.41

gitやhgが「Windowsでは」Unicode APIを使わずにバイト列でファイル名を扱うのはなんなんだ
バイト列なら>>376の言うようにPythonが対応しようが解決できないよね、これ
BazaarのようにUnicodeと決めているならUnicode APIに渡すときに変換なりするわけでしょ
でもバイト列で扱う方針なら変換できないよね
localeに応じて変換するのだろうか
マルチバイトのファイル名のマルチプラットフォームの問題はそもそも解決できない問題なの？

406 ：デフォルトの名無しさん：2011/05/01(日) 15:02:14.19

根本的には、ファイルシステム毎に使える文字が違うんだから細かい差異まで吸収できるわけがない。
やろうと思えば主要ファイルシステムの動作をエミュレートできるようにしたうえで、addした時のファイルシステムを覚えておくことになるだろうし。

それとは別に、必要な変換をしてくれないのは単なる無理解と手抜き。
gitについてはLinux上で最高のパフォーマンスが出せれば後はどうでもいいという大義名分があるけど、hgは単に開発者が無理解なだけだろ。
(bzrの互換漢字を正規化してしまう問題も、そんなことをするファイルシステムが現存しない以上やり過ぎと言える)

407 ：デフォルトの名無しさん：2011/05/01(日) 15:18:23.72

・欧米人にはファイル名にUnicodeを使う需要が無い
・欧米人はファイル名にCP1252(ISO-8859-1)が使えれば満足
・欧米人はLinuxでもファイル名はISO-8859-1を使っている
・Linux/UnixでロケールをUTF-8にしているのは日本人が主
・日本人はLinuxでEUC-JP/Shift_JIS/UTF-8の混在に慣れているが、これは日本の特殊事情

408 ：デフォルトの名無しさん：2011/05/01(日) 15:23:53.14

>>406
> hgは単に開発者が無理解なだけだろ。

無理解とは思えないが。
http://mercurial.selenic.com/wiki/EncodingStrategy

cmd.exeとGUIアプリの扱いが違うというのは、このスレでは話題になっていなかったが。
bzrがcmd.exeでCP932の方が無理解だと思うが。

409 ：デフォルトの名無しさん：2011/05/01(日) 15:29:36.71

hgが叩かれる時のリンクじゃないかそれ

cmd.exeでもW版APIを使えばokというのが周知されてないのも無理解の象徴だな

410 ：デフォルトの名無しさん：2011/05/01(日) 15:33:04.46

>>409
cmd.exeでwは使えない。
wprintf()がcp932とかcp1252の時にデータが欠損する。

411 ：デフォルトの名無しさん：2011/05/01(日) 15:35:38.99

>>409
bzrでお馴染みのpythonのコーデックエラーは、cmd.exeのことを考慮していない証拠。

412 ：デフォルトの名無しさん：2011/05/01(日) 15:37:30.80

使えるっての。
libcではなく自分でAPI呼べよ

413 ：デフォルトの名無しさん：2011/05/01(日) 15:45:46.84

>>412
chcp 1252 して日本語混じりのをwprintfしたら何が出力される？
だったら、printfでバイト列で出力した方がマルチプラットフォームアプリとしては
正しいと思うが。

414 ：デフォルトの名無しさん：2011/05/01(日) 16:09:39.19

>>413
cmdでUnicode使わない背景には、cmdのフォントの設定によっては表示されない
恐れがあるからという理由があったはず。
まぁ、一番は単に他の部分のファイルのインタフェースと整合性を取るのが大変
だからだろうけど。
CLIでunicode使いたかったら cygwin + minitty が最強。

415 ：414：2011/05/01(日) 16:10:15.09

>>412 だった。

416 ：デフォルトの名無しさん：2011/05/01(日) 16:14:13.63

UnicodeじゃないからUnicode版API使えないと言いつつ、
得体の知れないバイト列をANSI版APIに流し込む矛盾。

417 ：デフォルトの名無しさん：2011/05/01(日) 16:15:14.84

>>412
出力って何のこと？diffとか？

418 ：デフォルトの名無しさん：2011/05/01(日) 16:18:07.25

>>416
CP932と繁体字がASCIIと互換が無いから問題なのであって、
それ以外のコードページとLinuxでは、シングルバイト用のAPIで何ら問題が無い。

419 ：デフォルトの名無しさん：2011/05/01(日) 19:18:31.36

>>413
さすがPowerShell ISEさんに隙はなかった・・・

420 ：デフォルトの名無しさん：2011/05/01(日) 19:21:34.79

>>419
Mercurialは--encodeオプションかHGENCODING環境変数で、UTF-8が指定できるから、
PowerShellでも問題ない。これが正しい多言語化。

421 ：デフォルトの名無しさん：2011/05/01(日) 19:23:30.72

--encodingだった。
--encodingmodeってのもある。

422 ：デフォルトの名無しさん：2011/05/01(日) 19:40:05.99

>>420
や、俺が言ってるのはコンソールとしてのpowershell_ise.exeのことね
chcpコマンドがまともに機能するWin7標準のアプリ
従来の対話型コマンドが動作しないのが玉に瑕

423 ：デフォルトの名無しさん：2011/05/01(日) 20:00:58.60

>>422
PowerShell ISEってフルで言わないとだめなのか。
PowerShell ISEでMercurialでchcp 65001が最強。

424 ：デフォルトの名無しさん：2011/05/01(日) 20:09:01.55

>>423
うん、同意

425 ：デフォルトの名無しさん：2011/05/01(日) 20:26:56.00

chcp 65001 をしたら、fopenがutf-8を受け付けるようになるの？

426 ：デフォルトの名無しさん：2011/05/02(月) 12:10:01.43

>>313
そのwprintfはwcstombsしてるんだろ。

まずWriteConsoleWでUTF-16のまま無変換出力を試みる
→エラーになったらコンソール以外にリダイレクトされてるから
保存用コード(ロケール使うのが正しいがオプションでUTF-8を提供してもいい)に変換して改めてWriteFile
がWindowsでの正しいUnicode対応コンソールアプリの作り方。

427 ：デフォルトの名無しさん：2011/05/02(月) 12:10:24.54

>>413だった

428 ：デフォルトの名無しさん：2011/05/02(月) 12:29:52.71

>>426
Mercurialはファイル名とファイルの中身以外は内部UTF-8なんだからwcstombsを使う理由が無い。
http://mercurial.selenic.com/wiki/EncodingStrategy#Functions
にある通り、fromlocal()、tolocal()、colwidth()という関数が用意されている。

429 ：デフォルトの名無しさん：2011/05/02(月) 12:35:44.01

>>428
すまん、アンカーミスなんだ。
元はcmd.exeでWが使える使えないの話の流れなんだ。hgの実際の実装は関係ないんだ。

430 ：デフォルトの名無しさん：2011/05/02(月) 12:50:32.48

>>429
バージョン管理と何の関係があるの？

431 ：デフォルトの名無しさん：2011/05/04(水) 12:27:28.61

PowerShell ISEは旧来のコマンドプロンプトの諸問題を解決してくれて便利
シェルとして使いにくいのが悲しい点

432 ：デフォルトの名無しさん：2011/05/17(火) 18:26:14.74

gitでリモートからdiffを取る機能が無いか
gitスレで聞いたんだが基本的に存在しないらしい。

svnから物凄い機能後退だと思うのだけど、
bzrとかhgとか或いは、darcsとかmonotoneでも
出来ないのが通常なのだろうか？svnでは
svn diff -r 123:456 svn://server/repo/trunk
とかで出来たと思うんだけど。

433 ：デフォルトの名無しさん：2011/05/17(火) 18:30:32.51

普通に考えたらdiff取るだけなのに毎回リモート見に行く必要があるsvnのほうが……

434 ：デフォルトの名無しさん：2011/05/17(火) 19:17:16.19

SVN脳と言わざるをえないｗ

435 ：デフォルトの名無しさん：2011/05/17(火) 19:31:10.28

そうまでリモートに集約したいなら集中型のsvn使っとけば丁度良いよ

436 ：デフォルトの名無しさん：2011/05/17(火) 19:38:27.23

gitスレでも指摘されてるじゃないか
集中型じゃなくて分散型の思想について勉強してこいよ

437 ：デフォルトの名無しさん：2011/05/17(火) 19:39:28.24

ゲソなりく～ん

438 ：デフォルトの名無しさん：2011/05/17(火) 20:03:09.13

>>432みたいに新しい環境に拒絶反応示して興奮してる人って、後で恥ずかしくなったりしないのかね？

439 ：デフォルトの名無しさん：2011/05/17(火) 20:05:44.30

全成果プリントアウト(しかもシリアルプリンタで)がいいとおもうよ☆

440 ：デフォルトの名無しさん：2011/05/18(水) 00:19:30.76

いや、思想とかキモイです。
全部できないのか。酷い有様だな。

441 ：デフォルトの名無しさん：2011/05/18(水) 00:40:23.29

>>440
ssh gesonari@kimoi /usr/bin/git --git-dir=/svn/nou diff v0.1 v0.2

442 ：デフォルトの名無しさん：2011/05/18(水) 01:42:52.29

>>440
bzrはできる。

443 ：デフォルトの名無しさん：2011/05/18(水) 02:05:27.82

もうさわんなよｗ
タダの基地外なんだから。

444 ：デフォルトの名無しさん：2011/05/18(水) 02:07:36.82

bzr は遅くて泣けてくる・・・

445 ：デフォルトの名無しさん：2011/05/18(水) 02:50:35.02

>>444
最近はそうでもないぞ。
といっても、Windows以外のユーザーが最新のbzrを使うにはソースから
インストールするかFedoraかUbuntuの最新版を使わなきゃいけないけど。

446 ：デフォルトの名無しさん：2011/05/18(水) 08:46:27.06

＞使っていたソフトの開発元が svn+trac からgithubに
＞変わってしまってかなり機能後退と分かりゲンナリです。
このソフトって何だろうね。
意図せずGitHubに移行しなきゃいけなくなってゲソナリってことみたいだけど、
そこまでイライラするぐらいなら古いバージョンでsvn+trac使うことは出来ないのかな？

447 ：デフォルトの名無しさん：2011/05/18(水) 08:50:26.59

＞酷い有様だな。
おまえの頭がな

448 ：デフォルトの名無しさん：2011/05/18(水) 09:23:18.91

分散型がキモかったらsvnを使い続けていれば良い。
svnがキモくてcvsを使い続けているところもある。

http://hibari.2ch.net/test/read.cgi/tech/1113141518/817-818
> 817 名前：デフォルトの名無しさん [sage]： 2010/02/08(月) 11:34:23
> やはりgitか・・・
> bzrはすぐすたれそうだしsvnはきもいからな・・・
>
> 818 名前：デフォルトの名無しさん [sage]： 2010/02/25(木) 14:38:53
> >>815
> CVS で十分なのは同感。svn が嫌なのも同意。
> 俺は分散型に関しては、Mercurial と Bazaar を検討中。
> 機能的には Mercurial だけど、Bazaar も結構追いつきつつある(と思う)。
> あんまり日本語ファイル管理することもないんだけどね。

449 ：デフォルトの名無しさん：2011/05/18(水) 11:36:09.86

>>433
svnはリモート見に行く必要は無いんだが何いってんの?

450 ：デフォルトの名無しさん：2011/05/18(水) 11:47:33.18

>>449
それは作業領域の話。
特定のリビジョン間のdiffを見る場合、リモートを見に行く必要がある。

451 ：デフォルトの名無しさん：2011/05/18(水) 12:03:07.87

svnの仕組みもしらないsvnﾏﾝｾｰがﾌｧﾋﾞｮｯてると聞いて

452 ：デフォルトの名無しさん：2011/05/18(水) 12:22:45.76

スレがずいぶんと酷い有様だな。

453 ：デフォルトの名無しさん：2011/05/18(水) 17:26:11.89

ということでsvk最強

454 ：デフォルトの名無しさん：2011/05/18(水) 18:58:53.50

>>445
いや、最近久し振りに使ったら遅くて泣けた・・・

455 ：デフォルトの名無しさん：2011/05/18(水) 19:33:53.77

>>454
毎日使ってるけど、遅くて泣きたくなるのは、画像ファイルとかバイナリファイルを
たくさんリポジトリに突っ込んじゃった場合だけ。
どんな状況で遅かった？手元のバージョンが良くてもサーバー側のバージョンが
悪かったりしない？

456 ：デフォルトの名無しさん：2011/05/18(水) 19:35:04.65

>>455
launchpadの遅さは異常

457 ：デフォルトの名無しさん：2011/05/18(水) 21:00:36.69

>>456
試しにやってみたら、 bzr branch lp:mysql-server が 73771 リビジョンの
ブランチに 16m37sec かかった。
速いとは言わないけど、別に1日たっても終わらないとかじゃないし、最初の
1回だけだし、十分実用的な速度だと思う。
github や bitbucket に mysql のミラーないかな？

458 ：デフォルトの名無しさん：2011/05/18(水) 21:08:09.61

24時間経過しても終わらない上にエラーで失敗したりするgit cvsimportとかと比べたら
16分とか一瞬だった

459 ：デフォルトの名無しさん：2011/05/18(水) 21:08:55.41

無理すんなよw

460 ：デフォルトの名無しさん：2011/05/18(水) 21:14:56.64

>>457
Linuxカーネルは？
bitbucketじゃないところにhgのミラーはあるよ。
確かhgのポリシーにのっとって、バージョン毎にリポジトリが分かれていたから、
単純比較できないかもしれないけど。

461 ：デフォルトの名無しさん：2011/05/18(水) 21:16:19.31

time svn co http://svn.ruby-lang.org/repos/ruby/trunk/
real 0m18.214s
user 0m4.710s
sys 0m2.350s
time bzr branch lp:ruby
real 2m54.680s
user 1m29.770s
sys 0m1.500s
time git clone git://github.com/ruby/ruby.git ruby.git
real 2m42.831s
user 1m40.750s
sys 0m3.020s

git の方が速いんだろうけど、別に泣きたくなるほど遅くはないな。

462 ：デフォルトの名無しさん：2011/05/18(水) 21:21:40.34

Emacs も酷いね。

463 ：デフォルトの名無しさん：2011/05/18(水) 21:27:44.57

>>461
初回はどー考えてもsvn有利だろw

464 ：デフォルトの名無しさん：2011/05/18(水) 21:43:00.22

てか履歴1個だけじゃ他の分散型と比べられないよなー

465 ：デフォルトの名無しさん：2011/05/18(水) 21:45:41.86

>>462
$ time bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk emacs-trunk
real 17m46.033s
user 7m24.300s
sys 0m15.460s

2月辺りにはなんか問題あったらしいけど、改善されたらしいね。

466 ：デフォルトの名無しさん：2011/05/18(水) 22:00:37.84

time の履歴が流れちゃったけど、 savannah から git で emacs を clone
したら5分弱だった。emacsの場合はgitの方が4倍くらい速いな。

とりあえず、一晩たっても終わってないとかそういうのはなさそうだから、
実用上問題にはならないだろ。

467 ：デフォルトの名無しさん：2011/05/18(水) 22:02:22.21

bzrはやいなぁ
hgから乗り換えるかな

468 ：デフォルトの名無しさん：2011/05/18(水) 22:39:21.80

bzrの遅さはpull, push, merge全部が遅いってことでしょ。
インターネット越しじゃなくて、イントラネットでも。

469 ：デフォルトの名無しさん：2011/05/18(水) 22:47:37.12

バージョン上がる度にbzrは早くなってるな

470 ：デフォルトの名無しさん：2011/05/18(水) 23:47:49.94

俺もいつかは bzr が速いって言える様になるのかな・・

471 ：デフォルトの名無しさん：2011/05/18(水) 23:53:10.75

bzrはhgより早いし次はsvnとgitだな

472 ：デフォルトの名無しさん：2011/05/19(木) 00:29:13.45

と、bzr信者は何の根拠も無く申しております

473 ：デフォルトの名無しさん：2011/05/19(木) 00:32:44.03

hgはオワコン

474 ：デフォルトの名無しさん：2011/05/19(木) 00:35:21.89

と、bzr信者は何の根拠も無く申しております

475 ：デフォルトの名無しさん：2011/05/19(木) 00:37:37.15

時代はgitとbzrの2強の時代へ

476 ：デフォルトの名無しさん：2011/05/19(木) 00:49:17.80

と、bzr信者は何の根拠も無く申しております

477 ：デフォルトの名無しさん：2011/05/19(木) 00:53:13.72

マジレスするとGitとhgだろうな。どっちも似てるんだけどね。
GitHub vs Google Codeか。Launchpadはいまいち人気無いよね。

478 ：デフォルトの名無しさん：2011/05/19(木) 00:54:05.80

gitは男の子。bzrは女の子。hgはハードゲイ。

479 ：デフォルトの名無しさん：2011/05/19(木) 01:05:32.02

github は本当に良く出来てるよね
必要な情報が無駄無く配置されていて使い勝手がとても良い

480 ：デフォルトの名無しさん：2011/05/19(木) 02:24:14.68

gitはM$捨ててるからM$で遊んでる俺の選択肢にはなり得ない

481 ：デフォルトの名無しさん：2011/05/19(木) 08:05:41.81

>>461
githubのruby、trunk以外のブランチも入っているじゃん

482 ：デフォルトの名無しさん：2011/05/19(木) 08:10:45.02

>>480
http://code.google.com/p/msysgit/issues/detail?id=80#c77
http://repo.or.cz/w/git/mingw/4msysgit.git/shortlog/refs/heads/kb/unicode
http://repo.or.cz/w/git/mingw/4msysgit.git/commit/9205bfbef3dcd8d0361a04471c09d49e7a816b47

Mark unicode-related tests broken on msys

MSys bash doesn't support unicode at all. Testing a unicode-enabled git
with an encoding-agnostic bash cannot work.

This patch adds a new test function test_expect_success_unicode that tests
whether the shell is capable of passing unicode strings to another process.
If that works, the test is expected to succeed, otherwise it's expected to
fail.

483 ：デフォルトの名無しさん：2011/05/19(木) 08:17:10.66

gitもhgもutf-8に対応しているが、cmd.exe、MSysなど、MSの環境が糞なので、
まともに使えないってことだ。

484 ：デフォルトの名無しさん：2011/05/19(木) 11:17:07.01

>>481
うん、完全に同じ条件ではないとあとで気づいた。
だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
してはあながち的外れな比較でもないと思う。

まぁ、やりたかったことは、bzrとgitのどっちが速いかを調べることではなくて、
一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
一晩経って終わらないとかそういう事が無いことが確認できただけで満足。

本気で比較したかったらLAN上で帯域やレイテンシやパケロス率を制御した環境を
作れるはずだけど面倒なのでパス。

485 ：デフォルトの名無しさん：2011/05/19(木) 18:55:21.88

>>484
> 一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
> 遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
> 一晩経って終わらないとかそういう事が無いことが確認できただけで満足。

launchpadにアカウントを持っている人が一部の人では？
Emacsはlaunchpadではないけど、github・bitbucketに比べてcloneが目に見えて遅いのは
普通の感覚だと思うが。

486 ：デフォルトの名無しさん：2011/05/19(木) 19:06:38.32

>>484
> だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
> ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
> してはあながち的外れな比較でもないと思う。

git・hgはリポジトリに全部のブランチを入れるかブランチ毎にリポジトリを分けるか、
柔軟性があるけど、bzrはブランチ単位でしかcloneできないんじゃないの？
githubのrubyはgit-svnを叩いているから、ブランチだらけの状態だと思うけど。

487 ：デフォルトの名無しさん：2011/05/19(木) 19:31:26.64

launchpadは遅いというよりちょくちょく落ちてるのがなあ……

488 ：484：2011/05/19(木) 19:43:50.43

>>486
いやだから厳密な比較をしたいとかじゃなくて単に使い物にならないくらい遅いか
どうか調べたかっただけなんだって。
誰も bzr が git 並に速いなんて言ってないのに、そんなムキになって反論しなくても。

>>485
Launchpadからログオフしてmysql-serverをもう一回branchしてみた。
real 31m33.756s
user 11m9.130s
sys 0m8.110s
Launchpad自体がhttpサーバーが重くて遅いっぽいな。
でも、いつの間にかhttpでもスマートサーバーになってたらしくて、一晩かかるとか
ではない。mysqlでこの時間なら許容範囲内じゃない？
俺は、普段はmysqlよりも大分小さいプロジェクトで使ってるけど、全く問題ない速度で使えてる。

git と比べてて思ったのは、 git がステータス表示を常に高頻度で更新しててスピード感が
あるのに対して、 bzr の方がステータス表示の更新頻度が低いしちょくちょく止まる
(Launchpadからのレスポンスが遅いとずっと止まってることも、、、) ので見てて重そうに
感じた。実際の速度もまだまだgitに敵わないけど、遅いという印象を払拭するには
インタフェース面でもできることがありそう。

489 ：デフォルトの名無しさん：2011/05/19(木) 20:05:06.73

「一晩」が実用の判断基準っておかしくない？
git cvsimportやらgit-svnやらhgsubversionやらhg convertの最初の一回目が遅いのは当たり前。
だから、rubyのgithubみたいにミラーがあるんじゃない？
一回cloneすれば、その後のpullは差分だけど、そのpullもbzrは重いって指摘は
ぐぐればいっぱい出てくるけど？

490 ：デフォルトの名無しさん：2011/05/19(木) 20:55:28.09

> ぐぐればいっぱい出てくるけど？
これよそでは言うなよ恥ずかしいから

491 ：484：2011/05/19(木) 20:56:45.77

>>489
厳密な比較は面倒だからしないけど、きっとgitやhgよりも遅いんだろうな。
でも、俺は実用的な速度だと思ってるから使い続けてる。MySQLだって
あれだけ大きいプロジェクトで本当に使い物にならないほど遅かったら
とっくに乗り換えてるだろ。

bzrが実用にならないほど遅いという結論がでないとなにか困るの？

492 ：デフォルトの名無しさん：2011/05/19(木) 21:06:22.87

bzrでもsvnに比べたら御の字じゃないの？

常識で考えてGitが速すぎるんだよ。
clone中のあのいかにも速そうなインジケータとか、最初に何となくやるであろう
Linuxカーネルのcloneの速度とか、最初から狙ってると思う。

493 ：デフォルトの名無しさん：2011/05/19(木) 21:06:25.30

実用になる人も居れば、ならない人も居るってだけじゃないの

今使ってる人は使い続ける理由が欲しいだろうけど、今使ってなければ
別に思い入れもないし、遅いのが嫌なら bzr は選ばないでしょ

494 ：デフォルトの名無しさん：2011/05/19(木) 21:08:39.82

>>491
MySQLは万人がハックしてパッチを送るタイプのプロジェクトでないでしょ。
Emacsのビルドにbzrに接続することを要求されて、それで、bzrの重さの認識が一気に浸透したと思うけど。

cvs、svnもゼロから始めるソースはそんなに重くないけど、
だんだん重くなるよね。
bzr信者は感覚が麻痺しているんじゃないの？

cvsがデファクトスタンダードでsvnがそれに置き換わるかと思われたけど、
svn離れが加速しているよね？

遅いものは主流になり得ないというのは歴史が証明していると思うけど。

495 ：484：2011/05/19(木) 21:28:36.76

信者呼ばわりか。まぁ否定はしないけど。
別に bzr が今後も主流になりえないかもしれないけど、Canonicalが潰れる
までは衰退することもないし、その時に考えるからいいよ。
俺は単に使い物にならないほど遅いとdisられがちだから本当にそんなに
遅いのか実験してみて、俺に取っては許容範囲だと判断しただけ。

Emacsの件はいろいろ不幸だった。savannahのサーバーのセットアップが
悪かったり、タイミング的に bzr 2.1 以前を使ってるユーザーがまだ
多かったり (lennyのデフォルトのbzrなんて1.5とかいう使い物にならない古さ)
したからな。

496 ：デフォルトの名無しさん：2011/05/19(木) 21:58:52.05

> cvs、svnもゼロから始めるソースはそんなに重くないけど、
> だんだん重くなるよね。
svn の場合、ファイルシステム(リポジトリのフォーマットのこと)によって違うよね。
以前の bdb の場合はリビジョンが増えてもチェックアウトは速かったけど、
今のデフォの fsfs の場合はリビジョンが増えるとチェックアウトが遅くなる。
その半面、 fsfs ではホットコピーが簡単になり、壊れなくなったけど。

497 ：デフォルトの名無しさん：2011/05/19(木) 22:46:24.95

信者認定プログラム：OS　エディタ　プログラミング言語　これにVCSが仲間入りか。
他にもキーボード配列とか文字エンコーディングとかあるけどね。

498 ：デフォルトの名無しさん：2011/05/19(木) 22:48:09.06

Emacsはbzrの重さの認識が万人に浸透するほどハックされてるのか
Lisperの一人として胸厚だわ

499 ：デフォルトの名無しさん：2011/05/19(木) 23:22:30.26

友情は厚い、ですが胸は熱い、じゃないでしょうか？

500 ：デフォルトの名無しさん：2011/05/19(木) 23:23:19.53

鍛えてるんだろ

501 ：デフォルトの名無しさん：2011/05/20(金) 02:31:50.69

git>>>>bzr>>>>>>>>>>>>>>>>hg
今はこんな感じか。
hgの一時の勢いはどこへやら。

502 ：デフォルトの名無しさん：2011/05/20(金) 10:02:32.19

windowsオンリーの環境で分散型を取り入れる時、
git、hg、bzrからhgを選んで導入も終えてそこそこ使えるようになってきたのに、
だれだよオワコンとか言うのは！

503 ：484：2011/05/20(金) 10:23:37.27

>>502
hg いいと思うよ。そのうちWindowsでちゃんとUnicode API使えるようになりそうな気配だし。

504 ：デフォルトの名無しさん：2011/05/20(金) 10:26:12.38

>>501
2chのスレの勢いだとそうかもね。
hgの場合、日本語で語れる場所が他にもあるから。
そこで取り上げられていた、このスレに絶好のネタが2chでは取り上げられていないし、
住み分けができてるんじゃない？

505 ：504：2011/05/20(金) 10:27:50.43

おっと、>>503に例のネタ、先を越された

506 ：デフォルトの名無しさん：2011/05/22(日) 15:25:09.20

>>483
それもひっくるめてgitが糞という評価になるんだが。

507 ：デフォルトの名無しさん：2011/05/22(日) 15:34:57.36

MS 製品を使ってない俺には何が問題かさっぱり

508 ：デフォルトの名無しさん：2011/05/22(日) 15:36:55.32

なんども書いてるがcmd.exeっていうかWindowsのコマンドプロンプトでもUnicodeは使えるぞ。
UTF-8ではなくUTF-16になるから、#ifdefが必要になるだけで。

509 ：デフォルトの名無しさん：2011/05/22(日) 15:54:48.60

MS製品に依存してる連中がオレ様野郎ばっかというのがよく分かる。
Linux使ってる人が「VSSはLinuxで使えないから糞」なんて言わないからな。
別の意味では言ってるかも知れないが。

510 ：デフォルトの名無しさん：2011/05/22(日) 20:06:41.36

>>506 >>508
svnのmac portsのような対応をgitに望んでいるのか？

511 ：デフォルトの名無しさん：2011/05/22(日) 22:17:58.55

TortoiseCVSもTortoiseSVNも1つ落としてきてインスコするだけで使えるんだが
TortoiseGIT(笑)はそうじゃないんだよな
それを導入することによりよっぽど捗るとか利点がない限り
そんなまんどくせーものわざわざ手間かけてまでつかわねえよ

512 ：デフォルトの名無しさん：2011/05/22(日) 22:34:06.03

>>511
CVSとSVNのパフォーマンスとマージに満足なのですね？
CVSとSVNのマージはまんどくさくないのですね？

513 ：デフォルトの名無しさん：2011/05/22(日) 22:36:49.97

>>509
VSSがいいといっても見向きもしないでしょ、その人達は
文句を言うときは実装と一緒
gitがいいという話を聞いてうっかり使ってしまい文句のみを垂れ流す、それがWindowsユーザー

と、こんな風なレスを期待しているのか？
不毛じゃね？

514 ：デフォルトの名無しさん：2011/05/22(日) 22:46:18.29

>>513
> VSSがいいといっても見向きもしないでしょ、その人達は
VSSが糞なのは周知

515 ：デフォルトの名無しさん：2011/05/23(月) 02:37:25.78

>>512
自分の使わない機能がいくら速かろうが関係ないの
おわかり?

516 ：デフォルトの名無しさん：2011/05/23(月) 03:47:00.34

マージ使わないならrsyncとかtarballとかでいいんでは……

517 ：デフォルトの名無しさん：2011/05/23(月) 07:24:45.37

>>515
TortoiseCVS(笑) TortoiseSVN(笑)

518 ：デフォルトの名無しさん：2011/05/23(月) 11:12:04.02

>>515
使わないんじゃなくて使い方がわからないんだろ
おわかり?

519 ：デフォルトの名無しさん：2011/05/23(月) 15:38:59.33

>>518

520 ：デフォルトの名無しさん：2011/05/23(月) 16:34:02.13

>>515

521 ：デフォルトの名無しさん：2011/05/23(月) 18:52:26.43

>>515

522 ：デフォルトの名無しさん：2011/05/23(月) 19:42:43.91

きょうも元気だごはんがうまい
おかわり?

523 ：デフォルトの名無しさん：2011/05/23(月) 19:46:03.61

一人で開発する時は dropbox のフォルダに cp -R してるわ

524 ：デフォルトの名無しさん：2011/05/23(月) 23:22:47.09

dropboxとかねーわ

525 ：デフォルトの名無しさん：2011/05/23(月) 23:33:47.28

>>524
もっと良い奴あるの?

526 ：デフォルトの名無しさん：2011/05/24(火) 02:08:17.45

>>517
？

527 ：デフォルトの名無しさん：2011/05/25(水) 00:03:05.80

>>525
SugarSync

528 ：デフォルトの名無しさん：2011/05/25(水) 00:15:54.04

>>527
どこら辺がいいの?

529 ：デフォルトの名無しさん：2011/05/25(水) 13:11:25.38

SugarSyncとDropboxは良く比較されるしググればすぐ分かるぞ・・・・

530 ：デフォルトの名無しさん：2011/05/25(水) 19:27:34.81

いや、もちろん違いは知ってるんだけど、SugarSync のメリットがよく分からん

531 ：デフォルトの名無しさん：2011/06/24(金) 22:06:52.17

Github for Mac
https://github.com/blog/878-announcing-github-for-mac

532 ：デフォルトの名無しさん：2011/07/16(土) 22:33:02.35

code.google.com でも git が使える様になったらしいね

http://code.google.com/p/support/issues/detail?id=2454#c43

533 ：デフォルトの名無しさん：2011/07/17(日) 06:34:06.08

>>532
http://code.google.com/p/support/wiki/GitFAQ
> Is there a size limit on git repositories?
>
> For all source control systems, there is a 4GiB repository size limit. For git, we are starting with a push size limit of 500 MiB.
> If you try to push a pack over 500 MiB, your push will fail. We hope to lift this limit.

534 ：デフォルトの名無しさん：2011/07/17(日) 06:35:50.30

github、bitbucket優位の状況は変わらないだろう

535 ：デフォルトの名無しさん：2011/07/25(月) 19:55:07.99

Windows上にあるエロ画像とかエロ動画とか日記とかが雑多に保存してあるホームディレクトリを
まるっとバージョン管理するには何使ったらいいの

536 ：デフォルトの名無しさん：2011/07/25(月) 20:10:57.22

dropBox

537 ：デフォルトの名無しさん：2011/07/25(月) 20:23:18.86

テキストとそれ以外はバージョン管理のシステムを分けたほうが良い？

538 ：デフォルトの名無しさん：2011/07/25(月) 20:35:40.84

>>536
え？dropboxってバージョン管理できたの？別スレで
ttp://d.hatena.ne.jp/shibamu/20101014/p1
見て阿呆かと思ったけど意味があったのか…

>>537
同期して管理する必要が無いんだったら分けた方が良い、かも。
無関係なもの一緒くたにすると重くなりがちなので。

539 ：デフォルトの名無しさん：2011/07/25(月) 20:37:19.91

>>532
サーバのオプションどうなってるんだろうね。
sf.jpはrebaseできないの知らなくてすげー困ったんだけど。

540 ：デフォルトの名無しさん：2011/07/25(月) 20:45:00.76

>>538
俺もソースツリーのバックアップを dropbox に置いてるけど、何か問題あるのか?

バージョン管理は別途ツールを使ってるよ

541 ：デフォルトの名無しさん：2011/07/25(月) 20:51:32.69

>>540
>>538はバックアップじゃねーぞ

542 ：デフォルトの名無しさん：2011/07/25(月) 20:59:01.78

>>541
dropbox のディレクトリは単なるローカルのディレクトリでしょ
ビルドしてオブジェクトファイルが更新されたらバックグラウンドで
アップロードが走るのが嫌とか、そういう話?

543 ：デフォルトの名無しさん：2011/07/25(月) 21:15:46.51

元質問エロ画像やエロ動画や日記のバージョン管理を求めている。

544 ：538：2011/07/25(月) 21:44:02.08

>>540-542
ごめん俺drop boxのこと全く知らないし興味もないしスレ違いなので忘れて。

545 ：デフォルトの名無しさん：2011/07/25(月) 21:50:02.80

最良のバックアップは配布だ。トモダチにコピーして回る。

で、どんな得ろ画像だ? JSと熟女と太めは歓迎なので俺とトモダチになれ。

546 ：前スレ989：2011/07/25(月) 22:03:47.45

この板的にはJSと言えばJavaScriptだな。

547 ：デフォルトの名無しさん：2011/07/26(火) 00:04:51.49

dropboxならファイル単位で履歴管理できるしシェアもできる。
ソースの管理には向かないが、画像の管理にはそこそこ便利。
で、ソースのバックアップをdropboxに置くくらいなら、リポジトリを置いてしまうのも手。

548 ：デフォルトの名無しさん：2011/08/19(金) 23:24:45.47

gitで複数のブランチそれぞれに個別の未コミットのファイルを残したまま
ブランチを渡り歩くことってできる？
イメージとしてはbazaarで複数ブランチを同時にいじってて放置したまま
ブランチ間をcdで移動するみたいな。

diffとかはファイルとしての実体は不要でいいんだけど
gitは未コミット分をかかえたままになるのがちょっと困ってる。
いちいちstashとか嘘commitとかするのは
その判別含めて自動化できないと面倒で…。

549 ：デフォルトの名無しさん：2011/08/19(金) 23:28:19.52

MercurialならShelveがあるのにな

550 ：548：2011/08/19(金) 23:40:47.88

少し調べてみたけれど、
Mercurial の Shelve って git の stash と完全に同等に見えるけれど、そうでもないの？

551 ：デフォルトの名無しさん：2011/08/19(金) 23:45:29.57

TortoiseHgにあったShelve Changesは
ファイルごとに退避ができてstashより便利だなーって思った覚えが。

552 ：デフォルトの名無しさん：2011/08/19(金) 23:50:55.94

>>548
ブランチの数だけcloneしたら？

553 ：548：2011/08/19(金) 23:57:29.95

>>552
自分も一旦はそう考えたんだけど、それだと結局bazaarと同じ運用になって、共有リポジトリ使えない分だけ損してるような…。

ツリーは1つ、というのが気に入ってbazaarからgitに移行しようかと試してるんだけど
標準ではサポートされない（というか人気のない？）使い方なのかな。

554 ：548：2011/08/20(土) 02:26:16.94

濱野さんの本にはこう書いてある。
あとから追いやすくなるのでコミットは意味ごとに独立させるべき、
意味（意図）が同じコミットはあとからまとめるのもよい、
ローカルリポジトリは意味ごとにrebaseなどで改竄もむしろ推奨。

ということは、ブランチも意味ごとに直交させて切るべきだと思うんだけど
そーするとなぜ未コミット分がブランチをまたいで受け継がれるんだろう。
ブランチをまたぐ際にstashとか破棄前提の嘘commitが必要ってのは
単に実装が思想に（まだ）合致できてないってことなんだろうか。
日常的に使ってるとブランチは常に2～3個必要になるし、
瞬間的には 4個とかにもなるんだけど、みんな困ってないのかな。

555 ：デフォルトの名無しさん：2011/08/20(土) 04:18:26.06

Shelve Changesも実は嘘コミットだと思えば気分が楽になるんじゃね？
いやShelve Changesがどんなものか知らんけど。

556 ：デフォルトの名無しさん：2011/08/24(水) 15:54:04.86

>>535
NILFS

557 ：デフォルトの名無しさん：2011/08/24(水) 21:49:54.87

たくさんのリポジトリを一気にPull(Fetch)できるGUIのツールって無いかな
GitやHgのリポジトリ一つずつ更新していくの面倒

いや、サブディレクトリにあるリポジトリでfetchをする
スクリプト書けばいいのかもしれないけれども、GUIの方が良いし

558 ：デフォルトの名無しさん：2011/08/25(木) 01:08:57.32

>>557
俺はそんなのシェル一行ですませるけど、GUIのツールがほしいなら作れよ

559 ：デフォルトの名無しさん：2011/08/25(木) 15:02:17.64

GUIのツールで一気に何かするのって俺は怖くてやだ

560 ：デフォルトの名無しさん：2011/08/26(金) 11:34:02.44

復帰

561 ：デフォルトの名無しさん：2011/08/27(土) 19:55:47.01

Bazaar日本語ファイル名の問題がないらしいので手を出してみたが
GUIの既定値が自分の使い方とあっていなかった。
コマンド入力で補助しないと行けない。
Mercurialは自分と合っていそう。
rebase, transplant, splitを使って少しだけ内容の違うブランチを
双方で変更する場合に対応できる。
今までsubversionでリビジョンの範囲をマージする方法でやってきたが
履歴改変にはまりそうだ。

562 ：デフォルトの名無しさん：2011/08/30(火) 18:05:51.79

会社で開発メンバーが増える事になり、バージョン管理システムを使えとのお達しがでた。

条件は以下の通り

・NASでソースは管理する。（購入済み）
・サーバーレスで動くもの

調べた感じでSubVersionしか無いんじゃないかと思ったんだけど、他におすすめありますか？
上の条件に合致すれば分散だろうが集中だろうが関係無いらしい。

563 ：デフォルトの名無しさん：2011/08/30(火) 18:14:12.96

いやどれでもファイルベースのリボジトリ操作はできるだろうけど、
いろいろ無茶じゃないか……？

そのNASで複数の接続先から同時に同じファイルに排他ロックをかけようとして
ちゃんと動くか程度は確認したほうがいい。
ネットワークファイルシステム越しのロックがかからないようなら
サーバー建てるなり個人リポジトリとマージ用を分けるなり考えたほうがいい。

564 ：デフォルトの名無しさん：2011/08/30(火) 18:17:49.45

NASじゃ無理だろ
誰かのマシンでサーバを動かしてリポジトリはNASに置けばいい

565 ：デフォルトの名無しさん：2011/08/30(火) 18:26:32.70

同時書き込みしたらファイル壊れるな

566 ：デフォルトの名無しさん：2011/08/30(火) 18:33:06.19

いや、それこそsvnならファイルベースアクセスであってもロックファイルを作るぐらいのことはしてる。
だから一台のマシン上で複数プロセスから同時にコミットしても壊れない。

問題はネットワーク越しにそれをやると、ロックファイルを作ったつもりになって相手への反映が遅れるとか
NFSの制限でロック取れなくてもエラーが帰ってこないとか、なんか起きそうなことだ。

567 ：デフォルトの名無しさん：2011/08/30(火) 21:38:17.30

個人毎にリポジトリをもって、マスターのリポジトリへの反映は申請制とか

568 ：デフォルトの名無しさん：2011/08/30(火) 22:00:58.98

確かVSSはサーバーレスで動いたような……

569 ：デフォルトの名無しさん：2011/08/30(火) 22:33:14.62

分散型なら置くだけだからファイルコピーができる状況ならファイル置ける

570 ：デフォルトの名無しさん：2011/08/30(火) 23:54:03.63

>>562
SCMが全くわかってないなぁ、お前んとこの上司わ。
多分その上司は、そのNASがエクスプローラのWindowsネットワークに見えてないと
怒り出すんだろうな、きっと。

571 ：デフォルトの名無しさん：2011/08/30(火) 23:58:32.02

ちなみに、オレんとこの会社では牛NASを殻割りしてdebian突っ込んで、
そこでapache+subversionを動かしてるから、
・NASでソースは管理する。（購入済み）
という条件は満たしてるし、ソースの管理に必要なのはそのNASだけだから
・サーバーレスで動くもの
という条件も確かに満たしてはいる。

しかし当たり前のことだが、エクスプローラでは見えない。
つか、わかってないやつには見えないように設置する。これ、重要じゃね?

572 ：デフォルトの名無しさん：2011/08/31(水) 01:28:58.70

562の条件だとエクスプローラで見えなくても良さそうだが、
リポジトリを直接覗いて何が入ってるかわからん！なんて言われるレベルだとどうしようもないな

573 ：デフォルトの名無しさん：2011/08/31(水) 09:45:03.18

何も考えず独りよがりの思い込みでNASを買ってくる時点で、
どうしようもないレベルという条件は既に満たしてしまっている気がするが...。

574 ：562：2011/09/01(木) 17:08:25.56

みんなレスサンクス。

SCMについては俺もしっかり理解できてなくて勉強しながらやってるから勘弁してくれ

NASへのファイルの同時書き込みとかの問題は言ったんだけど
「今時のNASでそんなのあるわけないだろ、自宅で使ってるがそんな事起きたことが無い」
とか言われてナシのつぶてだった ('A｀)

んで、別のサーバ動かしてリポジトリをNASに置く件については
「サーバーとNASが同時稼動前提とか何考えてるんだ」らしい。

575 ：562：2011/09/01(木) 17:15:34.40

>>570
エクスプローラで見えてないとキチンと運用されているか俺がわからんとか言うタイプ

>>571
NAS(LS-WVL) を殻割りしてサーバー入れる手を考えてたんだけど、
「保証受けれなくなるし、もう半分ぐらい移行したから無理」とか言われるし

576 ：562：2011/09/01(木) 17:17:03.76

>>568
VSSは使いにくいって上司がいってｒ

>>569
分散型ってマスターの場所にサーバー入れて管理みたいな図を見たんだけど必要無い？
必要無いなら保存先がNASってだけでいけそうかなぁと

もう文句言いまくるくせに自分では絶対しない人なんで
ﾏﾝﾄﾞｸｾ('A｀) ｳﾞｧｰ

577 ：デフォルトの名無しさん：2011/09/01(木) 17:34:23.24

まあ、やってみなよ。リポジトリが壊れても知らんけど
いざとなったら日付フォルダで…

578 ：デフォルトの名無しさん：2011/09/01(木) 17:57:08.96

>>574
自宅用途でそもそも同時書き込みが発生するかよ。
本当にファイルに排他制御がかかるかテストさせてくれないのであれば
個人リポジトリを分けて、マージ担当を置いたほうがいいな。

579 ：デフォルトの名無しさん：2011/09/01(木) 18:22:06.68

>>576
保存先がNFSならいけたんだが、単なるNASだと無理。
あきらめろ。

580 ：デフォルトの名無しさん：2011/09/01(木) 18:26:56.25

どんなたいそうなNAS導入したのかと思ってググったら、それ15,000円位のゴミじゃん
業務でそんなの使うの？
サーバアプリ動かせるちゃんとしたの導入すれば？

581 ：デフォルトの名無しさん：2011/09/01(木) 20:18:22.50

まあ分散型なら自分とこのリポジトリが生き残っている可能性があるか…

582 ：デフォルトの名無しさん：2011/09/01(木) 20:26:10.00

分散型にして、そのNASは無いものと考える。

583 ：デフォルトの名無しさん：2011/09/02(金) 02:05:35.26

たしかにGitでロック競合しておかしくなったとしても
なんとかなっちゃいそうだよな

584 ：デフォルトの名無しさん：2011/09/02(金) 05:57:20.39

ダメ上司もつと大変だな

声かけしてコミットしなよ

585 ：デフォルトの名無しさん：2011/09/02(金) 06:51:53.18

確かにGitやMercurialならpushの前に声掛ければいいな

586 ：デフォルトの名無しさん：2011/09/02(金) 08:30:15.16

その上司の下じゃ何使っても駄目なんじゃ

587 ：デフォルトの名無しさん：2011/09/02(金) 08:37:09.09

分散型とか理解出来なさそうだ

588 ：デフォルトの名無しさん：2011/09/02(金) 08:52:00.66

今まで鯖も立てずによく業務がこなせたなとある意味感心する

589 ：デフォルトの名無しさん：2011/09/02(金) 20:20:34.83

QNAP TurboNAS の CPUがそこそこ上位の奴 (Mervell ARM じゃなくて、Intel ATOMの) なら、
Subversion が動くようだ。(ipkg で導入できるっぽい)
http://www.google.co.jp/search?q=QNAP+Subversion

Mercurial, Git, Bazaar, TFS については知らん。
Python と gcc と mod_wsgi が用意されているようなので、Mercurial は動きそうな気もする。
http://www.google.co.jp/search?q=QNAP+Mercurial

590 ：589：2011/09/02(金) 20:26:47.83

訂正。Subversion は一番安いの (TS-112 \20,000未満) でも用意されてる。

591 ：デフォルトの名無しさん：2011/09/02(金) 22:28:53.51

>>589 *nix系NASならbootする途中でのっとっちまえばなんでもありじゃん
gccのクロスコンパイラなんて簡単にできるんだしw

592 ：デフォルトの名無しさん：2011/09/04(日) 21:57:37.98

>>587
そんなときこそ Bazaar ですよ。
分散型が理解できないアホには集中型として、理解できる人には分散型として使える。

593 ：デフォルトの名無しさん：2011/09/04(日) 22:10:42.07

>>562
うちは Bazaar で共有リポジトリを共有フォルダ上において
push/pull あるいはmergeしてるから、NASを使っているのと
ほぼ同じ構成だな。

594 ：562：2011/09/05(月) 13:51:32.54

>>592
のやり方が一番幸せになれるんじゃないかと思った。

まだ自分がバージョン管理システムについて勉強中なんで
具体的な実現方法は見えてないんだけど、基礎的なものを勉強できる資料でおすすめって何かある？

リポジトリとかブランチとかさっぱりな初心者でも分かる資料・・・ orz

595 ：562：2011/09/05(月) 13:54:16.56

>>588

今までは自分が全部のソース管理をしてたんだよね。
でも今年の中頃から打ち合わせだとかで不在が多くなって
例の上司が「俺がソース管理をしてやろう」ってなってからデグレが８回。

全部自分が対応してなんとか復旧 orz

596 ：デフォルトの名無しさん：2011/09/05(月) 14:26:55.34

>>594
書籍・ドキュメント・実績豊富なGit・Mercurialを素直に使いましょう
まず近場の本屋に行きましょう
Bazaarが選択肢に入らないことは明かです

597 ：デフォルトの名無しさん：2011/09/05(月) 15:17:27.87

ClientのOSを聞かずに何かをお勧めしちゃうの？

598 ：562：2011/09/05(月) 15:21:47.38

Clientは Windows XP以上のOS全般です。(32bit、64bit混合)

599 ：デフォルトの名無しさん：2011/09/05(月) 15:59:53.41

>>595
>今までは自分が全部のソース管理をしてたんだよね。

どうやってたのよ？

で、上司が管理したらなぜデグるのか、原因はわかってる？

バージョン管理システムは管理を楽にしてくれるし、変なことできにくくしたり、
変なことしても復旧が容易だったりするけど、それでも変なソースをコミットして
混乱に陥るってことが皆無というわけじゃないよ。

600 ：デフォルトの名無しさん：2011/09/05(月) 17:44:12.82

分散型を選んで統合マネージャー型のワークフローで運用すればいいんじゃね
ttp://progit.org/book/ja/ch5-1.html#id103

どう運用するかが肝でどのツールを選ぶかはたいした問題じゃないと思う

601 ：デフォルトの名無しさん：2011/09/05(月) 17:56:40.55

なぁ、将来にわたって考えると数人月以上もコストがかかるやり方をやり始めるより、
5～20万出して(まともなサーバ or プログラムが実行できるNAS)(+UPS)を買った方が断然良くないか

602 ：デフォルトの名無しさん：2011/09/05(月) 18:18:38.93

それだったら問題の上司を飛ばすのが一番だよw

603 ：562：2011/09/05(月) 19:02:18.38

>>599
今まではPG一覧の資料作って、修正する際は申請してもらって修正中フォルダへ移動
PG一覧へ修正者の記載。

修正が終わった段階で修正中フォルダからメインフォルダへ移動→PG一覧に更新日を修正状況を更新

上司がデグらせたのはこの辺の管理を全くせずに勝手にフォルダ移動OKにしたところ。
あとPG一覧も修正せずにいたからこうなった感じ

604 ：デフォルトの名無しさん：2011/09/05(月) 20:05:34.11

>>603
その運用がちゃんとできているなら、ツール入れればだいぶ省力化できると思う。

その上司じゃどうしようもないから、早めに管理システム入れたほうがいい。

605 ：デフォルトの名無しさん：2011/09/05(月) 20:11:31.83

>>603
Tracとかredmineを検討したほうがいいんじゃない？鯖いるけどｗ

606 ：デフォルトの名無しさん：2011/09/05(月) 23:17:15.66

鯖立ち上げまで一発でインストールしてくれる
そんな夢のようなツールないですかね

607 ：デフォルトの名無しさん：2011/09/05(月) 23:55:40.10

>>603
うげぇ。そのPG一覧はExcelってオチか。
それはマズイ。

608 ：デフォルトの名無しさん：2011/09/06(火) 11:04:59.10

そのレベルだと VCS 入れたら入れたで問題起きそうだねえ

609 ：デフォルトの名無しさん：2011/09/06(火) 12:10:54.34

各モジュールに担当が決まっているような職場で、オプソ界隈のVCSがどれくらい効果的に使えるかねぇ?

…とか茶々入れてもしょうがないな。DVCSにして、マネージャ級だけがプッシュできるリポジトリを作るに一票。
>>600

610 ：デフォルトの名無しさん：2011/09/06(火) 17:12:20.61

画像ファイルをリポジトリに入れてるんだけど、色を変えただけでファイルサイズが同じだと
変更を認識してくれなくて酷い目にあった。
試してみたら
bzr : NG
git : NG
hg : OK
svn : OK
って感じだった。

これって常識？

611 ：デフォルトの名無しさん：2011/09/06(火) 17:13:31.88

バナリはなあ、、、
タイムスタンプ見るかどうか？

612 ：デフォルトの名無しさん：2011/09/06(火) 17:38:44.83

mjd?
ありえんなあ。

613 ：デフォルトの名無しさん：2011/09/06(火) 18:04:07.75

>610
VCSによっては、タイムスタンプもサイズも同じなら中身まではチェックしないってのはある。
タイムスタンプが変わってるのにサイズが同じってだけで変更無し扱いになるってのはちょっと考えにくい。

614 ：562：2011/09/06(火) 18:10:44.18

>>604
上司がやってなかったところがシステム化されるので大丈夫かなと思います。

>>605
まだどのバージョン管理システムを使うか検討段階なんで
どういうものがあるかも含めて教えてもらえると助かります。

鯖は無しでいいやつがいいです・・・・orz

615 ：デフォルトの名無しさん：2011/09/06(火) 19:30:58.94

>>614
各ホストファイル共有ベースでやってるならなおのことDVCSがいいね。

616 ：デフォルトの名無しさん：2011/09/07(水) 00:08:14.87

>>614
聞いてる感じだとMercurialが無難そう。GUIクライアントもこなれてるし。
日本語ファイル名をつかうなら、個人的にはBazaarを推したいけど。

とりあえず、HgInitでぐぐって出てきたページを読んでみるといいよ。
オリジナルは英文だけど和訳もあるはず。

617 ：デフォルトの名無しさん：2011/09/07(水) 00:32:56.06

>>610
＞git : NG
これは信じ難いなぁ

618 ：デフォルトの名無しさん：2011/09/07(水) 11:29:43.76

>>610
同じサイズのバイナリファイルということで
dd if=/dev/urandom of=file count=1
で試してみたけど再現しないな。何かやり方を間違っているだけでは。

619 ：デフォルトの名無しさん：2011/09/07(水) 12:15:08.63

ある程度以上の大きさのファイルは index に含まれなく、ファイル全体比較もしないんじゃないかな?
(一部だけ比較してるとか)

620 ：デフォルトの名無しさん：2011/09/07(水) 13:46:36.72

>>610
gitとbzrとsvnで確認してみた。
同サイズでタイムスタンプが同じだと、確かにgitとbzrはNGだった。svnはOK。
同サイズでタイムスタンプが異なるとgit、bzr、svnの全部がOKだった。

621 ：デフォルトの名無しさん：2011/09/07(水) 13:50:30.82

え、タイムスタンプが関係してくるSCMって大丈夫か？

622 ：デフォルトの名無しさん：2011/09/07(水) 13:55:41.41

バイナリーは特別扱いだろ

623 ：デフォルトの名無しさん：2011/09/07(水) 16:18:44.38

>>622
それは、バイナリファイルの場合は特別にタイムスタンプによって何か処理するということ？

624 ：デフォルトの名無しさん：2011/09/07(水) 16:37:24.24

まずバイナリの定義を述べてもらおうか

625 ：デフォルトの名無しさん：2011/09/07(水) 16:47:33.27

>>624
そのVCSでテキストレベルのdiffが取れないのがバイナリの定義じゃね？

626 ：デフォルトの名無しさん：2011/09/07(水) 16:52:46.13

>>624
gitとかsvnはバイナリファイルかどうかを判断してんだけど、知らないの？

627 ：デフォルトの名無しさん：2011/09/07(水) 17:29:05.52

>>624
mercurialだとNULバイト(0x00)が存在するものをバイナリファイルとして扱っているよ

628 ：デフォルトの名無しさん：2011/09/07(水) 17:30:24.65

gitのこと全然知らないんだけど、軽くググったところによると、「同サイズで同じexifを持ってれば同じとみなす」
とかいうことかも。
ファイルそのものの属性としてのタイムスタンプを見てるとは信じがたい。

629 ：デフォルトの名無しさん：2011/09/07(水) 17:35:55.51

気になるならテキストモードでやればいいだけ
それが専用プラグインなんかを突っ込む(Excelなんかはそうやるだろ？)
この手の質疑応答は10年ぐらいから嫌という程みてきたわｗ

630 ：629：2011/09/07(水) 17:40:21.02

×この手の質疑応答は10年ぐらいから嫌という程みてきたわｗ
○この手の質疑応答は10年以上前から嫌という程みてきたわｗ

要は該当するファイル群に対して強制的にハッシュを取るようにすればいいだけの事

631 ：620：2011/09/07(水) 17:45:28.75

gitとbzrとsvnで確認したのはWindows7上でした。
テキスト・バイナリ同じ結果となりました。

Linuxでは、ctimeを任意に変更することができなかったので
同じタイムスタンプのデータは作成できませんでした。
gitでは、chmod(ctime更新)したらそのテキストはmodifiedに
なりadd&commitできましたので、ctimeで判断しているように思えます。

632 ：デフォルトの名無しさん：2011/09/07(水) 17:48:52.87

>>630
何いってんの

633 ：デフォルトの名無しさん：2011/09/07(水) 18:03:41.17

バイナリだろうがテキストだろうがハッシュはとるでしょ。
ファイルサイズの大小ならともかく、テキストかバイナリかでその辺の挙動を変える意味はないし。

毎回全ファイルのハッシュ計算するわけにもいかないし、タイムスタンプとサイズが一致してたらとりあえず
未変更とみなすっていうのはそれなりに妥当な落としどころだと思う。

634 ：デフォルトの名無しさん：2011/09/07(水) 18:09:47.26

ひとりだけ勘違いくんが居るよ

635 ：デフォルトの名無しさん：2011/09/07(水) 18:17:45.90

とりあえず差分は無理だからな。丸ごと保存することになる場合が多い

636 ：デフォルトの名無しさん：2011/09/07(水) 18:17:49.92

>>633
何いってんの
どのSCMのコード見ての発言なの

637 ：デフォルトの名無しさん：2011/09/07(水) 18:21:51.64

ネットワーク越しのクライアント使う場合も、ローカルファイルのメタデータ送ってるって事か？

638 ：デフォルトの名無しさん：2011/09/07(水) 18:23:46.11

>>633
毎回全ファイルのタイムスタンプとサイズをやりとりするの？

639 ：デフォルトの名無しさん：2011/09/07(水) 18:26:01.40

>>635
svnは内部的にはバイナリファイルも差分で持ってるぜ

640 ：デフォルトの名無しさん：2011/09/07(水) 18:34:11.97

これマジか
gitとbzrは怖くて使えんわ

641 ：デフォルトの名無しさん：2011/09/07(水) 18:49:21.28

>>633
取らない物が殆ど
仕様をちゃんと読め

642 ：デフォルトの名無しさん：2011/09/07(水) 18:52:36.71

タイムスタンプがどうとか言ってる奴はバージョン管理を何だと思ってるの？ｗ

643 ：デフォルトの名無しさん：2011/09/07(水) 19:03:14.53

画像なんかのバイナリをバージョン管理に含める人がまだいるんだなぁ。
こういう人達はDBに沢山の画像をつっこむ以上に愚かだわ。

644 ：デフォルトの名無しさん：2011/09/07(水) 19:04:40.83

github の画像差分とか見てみろ

古い常識に囚われてはいかん

645 ：デフォルトの名無しさん：2011/09/07(水) 19:09:17.24

古い常識つーか今も常識でしょ。
リポが肥大して後で消そうにも消せない問題は未だ健在(出来る物も有るけどね)。
そんな拡張によるニッチな要求を満たした例を上げて「今はバイナリも突っ込むのが常識」なんて言われても説得力がないわい。

646 ：デフォルトの名無しさん：2011/09/07(水) 19:46:50.49

ゲームなんかだとバイナリ突っ込むけどなあ。

647 ：デフォルトの名無しさん：2011/09/07(水) 19:49:21.44

自分の常識があらゆる場合において普遍と思ってる奴は結構多いからな

648 ：デフォルトの名無しさん：2011/09/07(水) 19:52:05.38

ゲーム開発でバージョン管理にバイナリ突っ込む？えっ？
定期的にスナップショットをとるだけだろ…
あぁ同人か…

649 ：デフォルトの名無しさん：2011/09/07(水) 19:57:00.50

やっと10年前のレベルに追いついてる土方が沸いたか

650 ：633：2011/09/07(水) 20:01:27.36

>>641
マジで？これは恥ずかしい。
でもGitとBazaarはハッシュ取ってるよね？

>>642
そうは言っても、>>620 に書いてないMercurialも含めて、そういう挙動をしてるからなあ。

ちなみにタイムスタンプって言ってるのは、最後にコミットした時点のタイムスタンプじゃなくて、
ローカルで最初に変更チェックした時のタイムスタンプね。

BazaarとMercurialについては、一回ファイルの変更チェックしたら、サイズかタイムスタンプが変わらない限り再チェックされないようになってるように見える。
Gitは今手元にないから分からん。

651 ：デフォルトの名無しさん：2011/09/07(水) 20:08:37.60

見えるとかわからんとか言うぐらいなら一々レスするなって・・・・

652 ：620：2011/09/07(水) 20:19:42.68

git statusやbzr statusでmodifiedってならないだけならいいんだけど･･･
私の環境(Win7pro 32bit、bzr2.4.0、git 1.7.6 mysgit)だと、
ファイル名を指定してcommit(gitの場合はaddでファイル名指定後)も、
できないのが困る。

この現象が、私だけなのか、誰かWindowsでの動作を試してみてくれませんか？

653 ：デフォルトの名無しさん：2011/09/07(水) 20:27:04.66

要件上、画像の編集履歴を取りたい＋過去版を参照・取得したい
というのが必須なら、やはりVCSに突っ込むのがベターな選択だと思うよ。

ただその場合は、プログラムコードの管理をメインに開発されたVCSよりは、
Adobe Version Cueのような画像・映像データのアセット管理をメインに据えた
製品を選定するのが良いと思う。……というかそれは板違いの話になるな。

ちなみにウチは帳票定義用のバイナリーファイルをSVNに突っ込んでる。
Excelとか、Wordとか、PDFとか。

654 ：デフォルトの名無しさん：2011/09/07(水) 21:22:09.87

バイナリを入れないってのは、機械生成できる実行形式みたいな
のを入れないっていう意味だろ女子高生

655 ：デフォルトの名無しさん：2011/09/07(水) 21:31:19.43

>>648
画像データの内容とプログラムの仕様が一致していないとマズいから、
コードとデータを一緒くたにSubversionで管理してるよ。

以前までコードとデータを別々に管理してたけど、
コードだけ更新してデータを更新しないとか、逆のこととかが頻発するんだよね。
特に納期直前にそんな事あったら目も当てられん。

656 ：デフォルトの名無しさん：2011/09/07(水) 21:48:56.84

>>655
ディレクトリ、ファイル単位で別々のリビジョンをチェックアウトできるSubversionでは、
その要件は満たさない

657 ：デフォルトの名無しさん：2011/09/08(木) 00:24:05.54

>>656
そうなのかな。よく理解できてないけど。

658 ：デフォルトの名無しさん：2011/09/08(木) 00:38:53.93

タグくらいつけるだろ
管理できる

659 ：デフォルトの名無しさん：2011/09/08(木) 11:28:05.50

>>655
うむ。一番楽だ。重いけどな。

>>656
わかりやすく説明してちょ。

660 ：デフォルトの名無しさん：2011/09/08(木) 12:45:06.80

わざと一部だけ違うバージョンのファイルを混ぜてバージョンが一致してないとか言い出す揚げ足取り

661 ：デフォルトの名無しさん：2011/09/08(木) 14:01:54.84

>>629
> この手の質疑応答は10年ぐらいから嫌という程みてきたわ
そうなの？何か別の物と勘違いしてない？
今回の問題は「（フォーマット不明の）画像ファイルをSCMで扱うとき、ファイルの日付と
サイズが同じ場合、内容が異なっていてもSCMによっては同一のものと認識する」だよ？
GitやMercurialのFAQに書いてたりするのかな？

662 ：デフォルトの名無しさん：2011/09/08(木) 14:06:41.17

>>652
bzrで--unchangedつけてもダメ？

663 ：デフォルトの名無しさん：2011/09/08(木) 14:40:48.36

少なくともgitはファイルスタンプなんて見てない
画像はexifを見てるんだろうが、気に入らなきゃ自分で設定出来る

664 ：デフォルトの名無しさん：2011/09/08(木) 15:36:12.91

てか、プログラムで扱う画像ファイルにはexifなんか無いのが多いのでは？

665 ：620：2011/09/08(木) 16:46:29.90

>>662
bzrで--unchangedをつけて、試しましたがコミットは増えましたが、
変更が取り込まれませんでした。

再度Linux(Debian etch on VMware Player)とgit(1.5.6.5)で実験しました。
VMware Playerのフォルダ共有の機能でWindows上のフォルダを共有。
そこにディレクトリを作成してgitレポジトリを作成。
ファイルを追加してコミットした後、ファイルのサイズが変わらないようにファイルの内容を変更。
touchでファイルの存在するディレクトリとファイルのタイムスタンプを変更前のタイムスタンプに戻す。
VMwareのファイル共有ディレクトリだと、touchでctimeも変更できました。
この状態でgit statusをしても、変更がないと認識されました。add&commitもできませんでした。

666 ：デフォルトの名無しさん：2011/09/08(木) 17:03:17.59

>>665
gitの場合、.gitattributes ファイルに
*.foo binary
と書いとけば、拡張子.fooファイルはバイナリだと扱われる
これで試すとどうなる？

667 ：デフォルトの名無しさん：2011/09/08(木) 17:42:49.51

>>620
OKってどういうこと？
svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
「変更なし」になるんだけど。
変更を検知できないんならNGじゃね？

>>631
gitはパーミッションも管理対象だからじゃね？

668 ：デフォルトの名無しさん：2011/09/08(木) 17:53:14.49

>>667
> svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
> 「変更なし」になるんだけど。

まじか
svn使えねー

669 ：デフォルトの名無しさん：2011/09/08(木) 18:17:29.09

GitについてLinux(Debian Lanny)とMac OS X(10.6)で確認したら
サイズとctimeが同じでも、中身が違えば変更検知されたのだが

670 ：デフォルトの名無しさん：2011/09/08(木) 18:28:23.18

中身を見るなんて無駄な処理は要らない
タイムスタンプを変えないなんてわざとそうているのなら
運用する側が工夫すればよい

671 ：620：2011/09/08(木) 18:37:47.23

>>667
私の環境のTortoiseSVNだと、変更したファイルをクリックして状態を
観ると変更ありになり、コミット可能でした。

>>669
ファイルのみのctimeが同じな場合は、変更が検知されましたが、
その親ディレクトリのctimeを一致させた場合は、だめでしたので、
665ではそのように記述しました。

672 ：デフォルトの名無しさん：2011/09/08(木) 18:50:46.18

>>671
.git/ がある親ディレクトリまで含めて、全てのディレクトリとファイルの
ctimeを同じにしたけど、中身が違えば変更が検出されたぞ
どうなってんだ

673 ：デフォルトの名無しさん：2011/09/08(木) 18:53:09.32

このスレっていつからVIPになったの？

674 ：デフォルトの名無しさん：2011/09/08(木) 19:25:21.57

620は他のVCSに難癖を付けたいだけのSVN厨

675 ：デフォルトの名無しさん：2011/09/08(木) 21:37:47.88

http://stackoverflow.com/questions/1778862/how-does-git-detect-that-a-file-has-been-modified

676 ：デフォルトの名無しさん：2011/09/09(金) 18:59:34.46

svnはこれだな。
http://stackoverflow.com/questions/4730452/why-does-subversion-fail-to-flag-a-modified-microsoft-excel-spreadsheet-file

ttp://feather.cocolog-nifty.com/weblog/2010/12/excelbazaartort.html
を読む限りでは、
svnは>>667の通りで、
bzrは>>650っぽいけど、初めの状態からタイムスタンプが変わらない限りは
svnと同様ファイルサイズ等のチェックはしない…らしい。

svnで試してみたがやはり変更は検出されない。>>610 >>620は何か勘違いしてる。

>>668
bzr/gitでも試したがタイムスタンプ一緒だと変更検知できないよ。

677 ：デフォルトの名無しさん：2011/09/09(金) 19:11:14.55

サイズの同じ画像ファイルsample1.png, sample2.png を用意して、
こんな感じのシェルスクリプトを書いて実行してみた

---------------------------------------------
#!/bin/sh
mkdir dir
cd dir
echo "*.png binary" > .gitattributes
git init
touch .gitattributes
touch ../dir
cp ../sample1.png a.png
git add a.png
cp ../sample2.png a.png
cd ..
---------------------------------------------

実行は一瞬で終わるので、dir と dir/a.png と .gitattributes は全部同じタイムスタンプになった(statで確認）
で、git status してみたら変更が検知されたよ

678 ：676：2011/09/09(金) 19:13:22.93

ごめん、gitは検知した。検知できなかったのはhg。
svn NG
bzr NG
hg NG
git OK

679 ：デフォルトの名無しさん：2011/09/10(土) 08:47:32.42

つか file stat関係って、cifs とローカルで微妙に仕様が違ったりするんじゃないっけ？

680 ：デフォルトの名無しさん：2011/09/11(日) 04:38:09.42

毎回全ファイルの内容をチェックしてたらステータスの確認に時間がかかるから仕方ない。
変更したファイルはtouchすればいい。

681 ：デフォルトの名無しさん：2011/09/11(日) 13:38:57.77

>>680
だなー。内容変えたらタイムスタンプも変えておけってこった

682 ：デフォルトの名無しさん：2011/09/11(日) 20:53:04.25

PHPがGitに移行するみたい
ttp://news.php.net/php.internals/55293

683 ：デフォルトの名無しさん：2011/09/12(月) 11:18:01.38

変更したファイルをtouchすれば良いだけの話なのに
ぐだぐだと粘着してた奴が
svnも検知できないと分かったとたんパッタリ消えたのが笑えるwww

684 ：デフォルトの名無しさん：2011/09/12(月) 11:46:04.68

ていうか、普通変更したらタイムスタンプ変わるよね

685 ：デフォルトの名無しさん：2011/09/13(火) 23:23:49.08

待てよ、Mercurialでいいだろ！？

686 ：デフォルトの名無しさん：2011/09/30(金) 22:49:56.45

687 ：デフォルトの名無しさん：2011/10/01(土) 10:17:37.48

最近sf.netよりgithubなプロジェクト多いな
sf.netだと古くて動かないこと多いし

でも日本語ファイル名あったらsvnの方がいいのになんでgitなんだろ

688 ：デフォルトの名無しさん：2011/10/01(土) 10:27:38.33

日本語ファイル名なんてそんなにないんじゃない?

689 ：デフォルトの名無しさん：2011/10/01(土) 11:31:56.07

とにかくSourceForgeが使い辛いことにみんなが気づいてきたのが一因にあると思う
用途によってはsvnのほうが良いとしても、githubとSourceForgeには超えられない壁がある

690 ：デフォルトの名無しさん：2011/10/01(土) 11:56:33.55

もうVSSでいいじゃん
VSSのどこが気に食わないんだ？

691 ：デフォルトの名無しさん：2011/10/01(土) 12:11:45.07

全て

692 ：デフォルトの名無しさん：2011/10/01(土) 15:37:43.92

まあリヌース君が「svnは肥溜めの糞の中にあるサナダ虫の糞の中にある細菌の糞」って言っちゃったからなあ

693 ：デフォルトの名無しさん：2011/10/01(土) 18:32:06.16

少なくともフリーのバージョン管理システムと言えばCVS、と考えていた時代にリビジョンの概念を導入したSVNの功績は認められるべきだと思うんだが。糞とまで言われるのは使っていた自分としては哀しすぎる。

694 ：デフォルトの名無しさん：2011/10/01(土) 21:23:49.83

svnもよいものだったと思うよ。いまだに使われてるのもその証だし
CVSよりイケてるのがほぼsvnだけだった、て時代が長かったてのもあるけど

まあ、より使いやすい(と誰かが考える)ものに変わってくのはなんでも同じ
svnがそこにあって、それが気に入らなかったからLinusもgitつくったわけだし
よくもわるくも、svnがなければhgもbzrも育ってないと思う
だからsvnはよくやった、いままでごくろうさん、て感じかね

俺としては、ファイルシステムレベルでVCSをブチこんでくれないかな、
と前から思ってるんだけど。そういう構想とかないのかなあ

695 ：デフォルトの名無しさん：2011/10/01(土) 21:33:32.16

>>693
振り回され過ぎ。ほぼ完璧にUnicode対応
出来てるのは今でもsvnだけだし、
業務に使うのにこれほど信頼できるものも他にない。
リポジトリがネットワーク的に近ければ十分現役。
OSSのリポジトリは遠いからDVCSの速度が必須というだけ。1コミットに数分とかありえないだろ

696 ：デフォルトの名無しさん：2011/10/01(土) 21:57:58.42

>>694
Lionだと、全てのドキュメントが自動セーブ＆自動バージョニングされるらしいぞ、知らんけど

697 ：デフォルトの名無しさん：2011/10/01(土) 22:44:13.89

>>695
ローカルで履歴弄り放題のgitもいいもんだぞ
Windowsだと未だにsvn一択なのが悲しいが・・・

698 ：デフォルトの名無しさん：2011/10/02(日) 08:15:31.39

>>695
> 振り回され過ぎ。ほぼ完璧にUnicode対応
> 出来てるのは今でもsvnだけだし、
> 業務に使うのにこれほど信頼できるものも他にない。
バックアップが無くて全てパー
サーバがクラックされて全てパー

699 ：デフォルトの名無しさん：2011/10/02(日) 09:58:33.94

>>698
そう煽るなら上2行は引用しないのが適切

700 ：デフォルトの名無しさん：2011/10/02(日) 11:06:15.54

mercurial >>> git

701 ：デフォルトの名無しさん：2011/10/02(日) 12:42:12.53

>>696
Windowsにはシャドウコピーがあるね

702 ：デフォルトの名無しさん：2011/10/02(日) 21:00:37.28

>>698
バージョン管理システムと関係ないような気が

703 ：デフォルトの名無しさん：2011/10/02(日) 21:01:41.57

>ファイルシステムレベルでVCS
TRON

704 ：デフォルトの名無しさん：2011/10/02(日) 23:47:13.33

>>698 >>702
Gitならサーバークラックされて顧客情報流出しても平気と聞いて

705 ：デフォルトの名無しさん：2011/10/03(月) 00:38:14.24

ジャーナリングファイルシステムの話が出るなら Plan9 が話題に出るべきじゃないの。

706 ：デフォルトの名無しさん：2011/10/03(月) 00:49:36.39

LinuxならNILFSだよな

707 ：デフォルトの名無しさん：2011/10/03(月) 07:47:55.75

>>703 TRONにはねーよ。
VMSかな。

708 ：デフォルトの名無しさん：2011/10/03(月) 18:40:54.48

WebDAVが名前の通りにversioningするのはいつの日か

709 ：デフォルトの名無しさん：2011/10/05(水) 19:57:49.20

BitbucketがGitに対応したって、マジすか？

710 ：デフォルトの名無しさん：2011/10/05(水) 20:06:54.07

まじすよ。

711 ：デフォルトの名無しさん：2011/10/28(金) 19:50:58.83

712 ：デフォルトの名無しさん：2011/10/28(金) 20:09:47.78

はてなとmixiはgit使ってるんでしょ？

713 ：デフォルトの名無しさん：2011/10/28(金) 20:24:03.65

LLVMはGit使ってないよ

714 ：デフォルトの名無しさん：2011/11/07(月) 23:32:11.25

なぜ、アホみたいな煽り合いになるのだ？

Q:タイムスタンプが同じだと～
A:touchする運用でよくね？
で済む話が

信奉者が信じたくない(>>617)とか言い出したり。
そんな使い方が悪い(>>643)とか言い出したり。
使用上正しいと(>>641)とか言い出したり。

その言い争いで何か得るものがあるわけ？
アホ過ぎて分からんわ。

715 ：デフォルトの名無しさん：2011/11/07(月) 23:35:46.05

そんな2ヶ月前の話をほじくり返すお前もアホだ

716 ：デフォルトの名無しさん：2011/11/08(火) 20:04:44.10

まて、0.025光年先からレスしたのかもしれないんだぞ

717 ：デフォルトの名無しさん：2011/11/08(火) 22:28:31.53

>>716
どういう計算だよ。2ヶ月なら1/6年だろ。

718 ：デフォルトの名無しさん：2011/11/08(火) 23:05:32.39

計算は分からんが、概念としてどっちなんだろう
1光年みたく1光月という距離の単位があるとして
『1光月の彼方で、1ヶ月後に読み取ってその時書き込んだものがさらに1ヶ月後に我々の目に届く』
のか
『2光月の彼方で、2ヶ月後に読み取ってその時書き込んだものが瞬時に我々の目に届く』
のか、どっちでもないのか

719 ：デフォルトの名無しさん：2011/11/09(水) 00:00:43.38

不特定の人がパッチを投げ合いながら開発するオープンソースの開発モデルと
企業内で自分の担当のソースをいくつか修正してcommitする開発モデルではかなり違うキガス

720 ：デフォルトの名無しさん：2011/11/09(水) 11:18:08.64

そもそも光年は時間の単位じゃないだろ・・・

721 ：デフォルトの名無しさん：2011/11/09(水) 12:00:51.46

>>720
距離だよ。そんなことは常識だ。
光速より速い伝達手段がないから、仮に0.08光年離れたところからレスするなら
往復で0.16光年。即ち58日掛かるだろってこった。
因みに、0.025光年なら高々9日ほどだから往復でも18日。
二ヶ月前の話を穿るにしては中途半端すぎる。

722 ：デフォルトの名無しさん：2011/11/09(水) 12:24:31.18

>>716は光回線じゃないんだよ

723 ：デフォルトの名無しさん：2011/11/09(水) 21:24:08.38

TCPなんだからパケット１往復でレスできるわけ無いじゃんよ

724 ：デフォルトの名無しさん：2011/11/09(水) 23:37:38.83

スレチなのは重々承知だが素朴な疑問が
>>721
「光速より速い伝達手段がない」っていうのは
『とても軽い1光年の長さの棒があったとして、棒の端を押すかひねるかすると
その反対側が動き出すのはどんなに早くても1年後』
になるの？
せーの、で動き始める事にならないから音が水や金属を伝わる速さに差が出るのと
似た話になるんだろうか？？？

725 ：デフォルトの名無しさん：2011/11/09(水) 23:41:55.54

物理板でやれ
http://kamome.2ch.net/sci/

726 ：デフォルトの名無しさん：2011/11/10(木) 00:08:07.39

ありがとう、そこ行ってみる

スレ汚しすまんかった

727 ：デフォルトの名無しさん：2011/11/10(木) 02:42:10.27

テンプレ読んだけどmecurialとGITの一騎打ちでsubversionは論外でOK？
subversion使ってる人多いみたいだけど。

728 ：デフォルトの名無しさん：2011/11/10(木) 16:53:16.30

分散型の機能が必要なら論外。
不要なら鉄板。

729 ：デフォルトの名無しさん：2011/11/10(木) 22:18:29.30

>>728
集中型だとsubversionが鉄板なのか。どうりで名前をよく聞くわけだ。
どうも有り難う。

730 ：デフォルトの名無しさん：2011/11/11(金) 02:24:44.84

>>727
TortoiseSVNなどクライアントの成熟や日本語環境の安心度、集中型であるがゆえのシンプルさなどがSubversionの利点。

731 ：デフォルトの名無しさん：2011/11/12(土) 09:25:18.73

分散型は日本語環境が不安なので１人TortoiseSVN

732 ：デフォルトの名無しさん：2011/11/12(土) 22:34:58.67

Mercurialは最近ファイル名にUnicodeが使えるようになったらしい
Bazaarは前からUnicode使える
GitはCygwin版とかUTF-8対応msysgitにすればいいがTortoiseGitで文字化けする
Cygwin版GitとCygwin版GitGUIならいいのか？でもあれはTortoiseより使いづらい

だからこの3者で日本語の扱いに問題ありそうなのはGitだけということになった

733 ：デフォルトの名無しさん：2011/11/12(土) 23:11:54.74

>>732
> Mercurialは最近ファイル名にUnicodeが使えるようになったらしい
まだなっていない。

Windowsのネイティブ環境(cygwinじゃない環境)でUTF-16が扱えないということで、
それ以外の環境であれば、Unicodeのエンコードの一つUTF-8を扱うのに
MercurialもGitも制約は無い。

734 ：デフォルトの名無しさん：2011/11/15(火) 16:47:52.61

Macもいれてやれよ…

735 ：デフォルトの名無しさん：2011/11/15(火) 21:19:20.38

>>733
「日本語の扱いに問題がある」ってんだからWindowsのことだよ。
頭悪いな

736 ：デフォルトの名無しさん：2011/11/15(火) 21:36:30.42

日本語ファイル名使う時点でクズ

737 ：デフォルトの名無しさん：2011/11/15(火) 22:00:43.83

>>736
日本語嫌いな人？？国に帰れば

738 ：デフォルトの名無しさん：2011/11/16(水) 10:29:21.37

え？Macも日本語の扱いに問題あるだろ

739 ：デフォルトの名無しさん：2011/11/16(水) 13:34:58.80

ありまつけど

740 ：デフォルトの名無しさん：2011/11/18(金) 18:52:16.11

Software Design 2011年12月号
http://gihyo.jp/magazine/SD/archive/2011/201112

第2特集
まだSubversionで大丈夫？
イケてるGitの使い方
［Git×Subversion＆Redmine］

第1章：SVN使いのための
Git入門……岡本隆史
第2章：git-svnによるSVN包囲戦［戦支度編］
ローカルGitでSubversionを攻略せよ……川西俊之，正徳巧
第3章：git-svnによるSVN包囲戦［実戦編］
ローカルGitでSubversionを攻略せよ……川西俊之，正徳巧
第4章：RedmineによるGitリポジトリ包囲戦
プロジェクト管理ツールでGitをパワーアップ……岡本隆史

741 ：デフォルトの名無しさん：2011/11/18(金) 23:29:17.44

下のようにレイアウト組んでましたが、表の部分を右にずらそうとmarginを指定しても動いてくれません。
説明文と表と説明文の３つをdivで囲って、表の部分をtable{position:relative;left:20px}とかしたら
理想の通りになったんですけど、考え方としてこれでいいのでしょうか？

┏━━┓説明文
┃ 図　┃表
┃　　　┃説明文
┗━━┛

742 ：デフォルトの名無しさん：2011/11/18(金) 23:34:49.93

使い勝手がよいGUIがあるものが一番

743 ：デフォルトの名無しさん：2011/11/18(金) 23:45:50.65

>>741 誤爆でした。どうも騒がせて済みません。

744 ：デフォルトの名無しさん：2011/11/19(土) 16:29:42.10

いえいえ

745 ：デフォルトの名無しさん：2011/11/19(土) 18:35:58.41

746 ：デフォルトの名無しさん：2011/11/20(日) 04:59:47.49

よ

747 ：デフォルトの名無しさん：2011/11/20(日) 13:30:28.15

http://hibari.2ch.net/test/read.cgi/tech/1310403238/645

645 名前：デフォルトの名無しさん [sage]： 2011/11/20(日) 08:33:26.23
>>644
もうgitはsvnを抜いているよ
http://qa.debian.org/popcon-graph.php?packages=bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion&show_installed=on&want_legend=on&beenhere=1

748 ：デフォルトの名無しさん：2011/11/20(日) 17:10:36.62

私はsvnを続けるよ

749 ：デフォルトの名無しさん：2011/11/21(月) 09:14:35.58

僕は Subversion 1.6 を使い続けるよ。

750 ：デフォルトの名無しさん：2011/12/02(金) 16:17:39.36

fossil ってのは実際どんなもんだろうかと思って、
バージョン管理ツール総合スレらしきここを覗きにきた。

一言も登場しとらんのな。

751 ：デフォルトの名無しさん：2011/12/02(金) 19:59:03.84

fossilは1～2年に一回くらいの頻度で、バージョン管理系のスレやBTSスレかWIKIスレで見かける気がする。

752 ：デフォルトの名無しさん：2011/12/04(日) 01:42:40.77

昔WinMXっていうＰ２Ｐ型のファイル交換ソフトがあったけど、
あんな感じでWindowsにインストールしたらいきなりファイル交換を自動的にし合うような
そんなバージョン管理ソフトはまだ出現しませんかね？

753 ：デフォルトの名無しさん：2011/12/04(日) 02:07:15.59

そんな使いにくそうなソフトは、いつまでたっても出現しないと思う。

754 ：デフォルトの名無しさん：2011/12/04(日) 03:27:28.52

dropbox

755 ：デフォルトの名無しさん：2011/12/04(日) 21:25:54.92

RCSをGUIで表示できるアプリありませんか？

756 ：デフォルトの名無しさん：2011/12/04(日) 22:25:32.76

どうしてBazaarって人気ないの？

757 ：デフォルトの名無しさん：2011/12/04(日) 22:32:47.85

>>756
GNUだから

758 ：デフォルトの名無しさん：2011/12/04(日) 23:20:45.18

>>756
bzr-explorer が中途半端に使いにくい

759 ：デフォルトの名無しさん：2011/12/04(日) 23:21:40.66

GNU tla由来のbazaarとCanonicalのbazaarは別モンじゃね?

760 ：756：2011/12/04(日) 23:28:52.04

ぼくはBazaar使ってるんだけど、結構良いと思うんだけど。
subversionから移行して便利だなあって思ってるんだけど。
gitとかhg使ったことないから、そっちのほうがいいのかもしれないけど。

>>757
どうしてGNUだと人気ないの？

>>758
なんか良いGUIクライアントありませんかね。

761 ：デフォルトの名無しさん：2011/12/05(月) 00:06:34.92

>>760
あなたがWindowsを使っているのか、Linuxを使っているのかわからないけど
俺はwindows から使っている感想を書く。
SVNの場合TortoiseSVNを使う限り、SVNのコマンドを意識する必要は全く無い。

ところがBazaarの場合、TortoiseBZRにしろBzr-Explorerにしろ、BZRコマンドが
動いているのが見えるし、エラーが起きるとBZRコマンドを実際に打たないと復旧出来ない
場合がたまにある。GUIツールはGUIだけで完結してほしい。
特にWindowsの場合はそうでないと、グループで使うのはちょっと無理。

762 ：756：2011/12/05(月) 00:14:09.66

>>761
たしかに。TortoiseSVNは優れていますね。

hgやgitはWindowsでGUIツールで完結できるものはあるのでしょうか。

763 ：デフォルトの名無しさん：2011/12/05(月) 00:20:14.41

>>761
> SVNの場合TortoiseSVNを使う限り、SVNのコマンドを意識する必要は全く無い。
だって、svn.exeが付いてないんだもん。

764 ：デフォルトの名無しさん：2011/12/05(月) 01:58:42.83

>>763
最近のTortoiseSVNには付いてるよ。

765 ：デフォルトの名無しさん：2011/12/05(月) 03:16:56.63

>>761
Subversionっていうか、TortoiseSVNが優れてるっていう話だね。

うちの会社もSubversion使ってる。
Linuxでコマンドラインだけど。
ファイル数がめちゃめちゃ多いとcoするにもupdateするにも時間もメモリも食い過ぎていい方法か、いいソリューションが無いかと検討中。

766 ：デフォルトの名無しさん：2011/12/05(月) 03:36:06.74

SVN、管理ファイル1個になってそのへんマシになったんじゃないの？

開発途中で乗り換えるのは危なすぎるが、次のやつで試してみたいところではある

767 ：デフォルトの名無しさん：2011/12/05(月) 03:43:25.35

>>765
そういう場合は本格的にgitを考えたほうがいいかも

768 ：デフォルトの名無しさん：2011/12/05(月) 07:30:18.52

TortoiseSVNが優れてるってのは他に比較するものを知らないから優れているって信じているだけではないか？
他のものと比較してとりたてて優れているところはないが。

769 ：デフォルトの名無しさん：2011/12/05(月) 17:12:12.22

bazaar は遅い。

770 ：デフォルトの名無しさん：2011/12/05(月) 20:42:12.30

>>768
他の物って何？具体的なソフト名を挙げてくれ

771 ：デフォルトの名無しさん：2011/12/05(月) 21:11:43.17

>>770
TortoiseCVS

772 ：デフォルトの名無しさん：2011/12/05(月) 21:47:53.52

>>768
・Windows上の
・フリーで使える
・GUIの
・バージョン管理ソフト

の中では、やっぱ一番順当に使える完成度じゃなかろかね。
CVSよりはSubversionのが良いし、
かといって、Gitやらhgやらござーるやらにおいては、
今度はtortoiseの完成度が…だし。

773 ：デフォルトの名無しさん：2011/12/06(火) 01:20:45.51

ＣＶＳのが優れてるとかはじめてみたわｗ

774 ：755：2011/12/06(火) 02:11:34.33

TortoiseRCSのようなものはありませんか。単体で動くものでもかまいません。

775 ：デフォルトの名無しさん：2011/12/06(火) 07:36:04.07

TortoiseCVSはCVSクライアントとしては十分な完成度
CVSとSVNでは出来ることが違うのだからTortoiseCVSとTortoiseSVNを比較しても無意味
TortoiseHgとbzr-explorerはWindowsだけが動作環境では無いので、TortoiseSVNと比較しても無意味
TortoiseGitはgit extensionsという代替がある
TortoiseBzrは世界的に使われているのか疑問

776 ：デフォルトの名無しさん：2011/12/06(火) 12:56:30.07

GUIだったらWinCVSが一番良かった。
時点でEclipse。

777 ：デフォルトの名無しさん：2011/12/06(火) 21:04:55.95

>>755
RCSではないが、似たようなことをする Visual SouceSafe というものがある。ディスコンに向かってるけど。
GUI で RCS って面倒なだけだよ?

778 ：デフォルトの名無しさん：2011/12/06(火) 21:12:05.43

各種分散型にインポートしろ

779 ：755：2011/12/06(火) 23:59:59.17

>>777
そうなんですか。
履歴とかをグラフィカルに見たかったので。

780 ：デフォルトの名無しさん：2011/12/07(水) 00:23:13.91

RCSのグラフィカル履歴っていったい…

781 ：デフォルトの名無しさん：2011/12/07(水) 00:30:10.63

ラインエディタからスクリーンエディタにすれば、よりグラフィカルに。

782 ：デフォルトの名無しさん：2011/12/07(水) 22:06:27.69

板の移動を管理するバージョン管理ソフト

783 ：デフォルトの名無しさん：2011/12/08(木) 11:52:36.03

第二の内柴を出さないためのバージン管理ソフト

784 ：デフォルトの名無しさん：2011/12/09(金) 21:21:56.20

分散型バージョン管理ソフトって、
簡単に言えばファイル交換ソフトにバージョン管理を組み合わせただけでしょ

Winny にバージョン管理とssh通信付ければ、
最強の分散型バージョン管理ソフトが出来たのに、

↓仁義なきなんとかネタの突っ込み禁止

785 ：デフォルトの名無しさん：2011/12/09(金) 22:13:00.71

>>784
マージできんモン送られても困るがな。

786 ：デフォルトの名無しさん：2011/12/09(金) 22:54:52.34

履歴ログも閲覧出来んし。

787 ：デフォルトの名無しさん：2011/12/09(金) 23:47:18.48

自分用のコミットを勝手に同期されても困る

788 ：デフォルトの名無しさん：2011/12/09(金) 23:47:27.97

パッチの順序性をどこで確保するかが難しいな。

789 ：デフォルトの名無しさん：2011/12/09(金) 23:51:15.60

あれ？他のすれが消えてる？

790 ：【18.3m】【東電 82.0 %】：2011/12/09(金) 23:51:38.60 BE:5044097489-2BP(108)

移転だってさ

791 ：デフォルトの名無しさん：2011/12/09(金) 23:52:42.31

ラピュタ混乱の最中にやらんでも

792 ：デフォルトの名無しさん：2011/12/09(金) 23:57:19.16

㌧㌦

793 ：【28m】【東電 82.0 %】：2011/12/10(土) 00:32:02.42 BE:1050854235-2BP(108)

移転していない件orz

794 ：【26.8m】【東電 82.0 %】：2011/12/10(土) 00:32:30.29 BE:420342023-2BP(108)

ってハード換えたのか

795 ：デフォルトの名無しさん：2011/12/10(土) 12:49:29.27

バージョン管理の行き着く先が git なのかな　？

git を本質的に超えるバージョン管理はもう現れないのかな？

796 ：デフォルトの名無しさん：2011/12/10(土) 13:15:24.55

ｈｇ

797 ：デフォルトの名無しさん：2011/12/10(土) 14:23:58.07

>>796
HGが、”本質的”にgitを超えているとは思えないな
多少の機能の違いがあるだけで似たり寄ったりですな

798 ：デフォルトの名無しさん：2011/12/10(土) 14:27:45.52

>>797
ファイル名の扱いが構想通りに実現すれば、他のVCSを超越すると思う

799 ：デフォルトの名無しさん：2011/12/10(土) 17:40:14.09

>>798
望みが低すぎる

800 ：デフォルトの名無しさん：2011/12/10(土) 20:29:18.18

本質ってどういうこと？
どれも思想が異なるわけだが

801 ：デフォルトの名無しさん：2011/12/10(土) 20:32:39.04

>>800
gitとhgは思想は一緒。リポジトリへの保存方法とコマンド体系が違うから別物に見えるけど。

802 ：デフォルトの名無しさん：2011/12/10(土) 21:14:57.01

妖怪人間bazaar が　hg のような普通の人間になろうとしているのが痛い

803 ：デフォルトの名無しさん：2011/12/10(土) 21:15:34.91

>>800
思想がちがうのはdarcsだけ

804 ：デフォルトの名無しさん：2011/12/11(日) 03:11:29.28

>>798
gitが優れてる部分が多いことは間違いないんだけど、
バイナリを頻繁に扱わなくちゃならない環境にとってはgitじゃ駄目なんだよなぁ

805 ：デフォルトの名無しさん：2011/12/11(日) 15:31:56.85

>>804
バイナリが得意なVCSってなに？

806 ：デフォルトの名無しさん：2011/12/11(日) 15:58:35.45

>>805
Mercurial 2.0リリース、バックポートに有用な「graft」コマンドや
サイズの大きいバイナリファイルを効率よく扱う拡張などが導入される
http://sourceforge.jp/magazine/11/11/04/0354255

807 ：デフォルトの名無しさん：2011/12/11(日) 16:18:33.61

>>806
それは単に実体を共有したりするだけだろ。そんなもんgitならデフォだ。
そして頻繁にバイナリの変更があるようなのはどっちもダメだ。

svnならバイナリも差分で格納してくれる。

808 ：デフォルトの名無しさん：2011/12/11(日) 16:32:10.84

>>807
> svnならバイナリも差分で格納してくれる。
hgも差分だけど。
もっとも、hgは、テキスト・バイナリの区別は(EOL拡張を除いて)してないけど。
記事にも概要は書いてあるけどもっと高機能。
http://d.hatena.ne.jp/flying-foozy/20111113/1321206115
12/19のAdvent Calendarにご期待下さい。
http://partake.in/events/902cd6d9-0215-4ea3-b51f-b8ff32e56426

809 ：デフォルトの名無しさん：2011/12/11(日) 16:33:57.52

bazaarのバイナリの扱いはどうなっていますか

810 ：デフォルトの名無しさん：2011/12/11(日) 16:44:05.76

hgの新機能についてはよく知らないけど、gitもpackすれば
バイナリに限らず差分形式になる

811 ：デフォルトの名無しさん：2011/12/11(日) 17:18:49.81

巨大なバイナリを扱おうとするとgitもbzrも大量のメモリーを使用した。
この点はsvnが優れている。hgは試してない。

812 ：デフォルトの名無しさん：2011/12/11(日) 17:25:35.96

・何をした？
・OSは？
・メモリのキャッシュに残ってただけでは？

813 ：デフォルトの名無しさん：2011/12/11(日) 17:27:15.85

svnと分散型を比較するのなら、svnのサーバも比較してね

814 ：811：2011/12/11(日) 17:34:26.83

いずれもMicrosoft Windows XPで比較。タスクマネージャーの仮想メモリ量
で見た。
1.7GBくらいのファイル1個をコミットしてみた。
hgはファイルサイズくらいのメモリーを消費した。
bzrはファイルサイズの倍(もっとかも)のメモリーを消費した。
svnは数百メガバイトくらい。
svnはサーバーを使わずローカルのファイルシステム上にSVNROOTを設定した。
ただしbzrをテストしたのはだいぶ前なので改良されてるかも。

815 ：デフォルトの名無しさん：2011/12/11(日) 17:36:29.61

>>814
仮想メモリ量じゃなかったかも。手元にXPがないんですまん。

816 ：デフォルトの名無しさん：2011/12/11(日) 17:46:23.18

ユーザモードのアドレス空間は2GBしかないのに3.4GB消費したの？

817 ：デフォルトの名無しさん：2011/12/11(日) 17:49:39.45

bzrはだいぶ前だったから記憶があいまい。っていうか人のテストにケチをつける
前に自分でやってみればいいのに。

818 ：デフォルトの名無しさん：2011/12/11(日) 17:50:52.67

>>811 >>814
gitとhgのどっちを試したのか分からん

819 ：デフォルトの名無しさん：2011/12/11(日) 17:55:07.49

>>818
すまん。gitとbzrとsvnだった。

820 ：デフォルトの名無しさん：2011/12/11(日) 18:13:30.24

>>817
テスト内容が非現実的。svnでサーバーを使わない目的が不明。

821 ：デフォルトの名無しさん：2011/12/11(日) 18:18:33.97

>>820
だから誰でも簡単にできるテストなんだから、好きにテストすればいい。

822 ：デフォルトの名無しさん：2011/12/11(日) 18:21:26.09

>>821
svnが優位というのは根拠が無いでOK？

823 ：デフォルトの名無しさん：2011/12/11(日) 18:44:30.16

>>822
好きにしたら?
誰かの参考になるかと思って単にテスト結果を並べただけだよ。
svnを応援する気なんてない。実際svn使ってないし。

824 ：デフォルトの名無しさん：2011/12/11(日) 21:24:02.28

SubversionとMercurial使っている人に聞きたい。
理論的な上限じゃ無くて、実運用的な作業フォルダのサイズってどの程度にしている？

なんか、直ぐにファイル無くしたとか、上書きしたとか削除したとか言い出す人がいて、
管理フォルダまとめて管理してしまおうかと。でも、6.5GBで、ファイル数38,000くらいあるんだ。
さすがにこれをひとまとめは無茶だよね。Windows環境でファイルサーバー的にしか使ってない。

バージョン管理ソフト使うよりはファイルの書き換え毎にバックアップで戻るソフトさがした方が良いか。
そんなのあるのか知らないけど。

825 ：デフォルトの名無しさん：2011/12/11(日) 21:29:18.94

バージョン管理とは別にpdumpfsでも走らせとけばいいんじゃねーの

826 ：デフォルトの名無しさん：2011/12/11(日) 21:32:24.34

>>824
Subversionはディレクトリ（フォルダ）単位でチェックアウトできる。
Mercurialはサブリポジトリという機能がある。

827 ：デフォルトの名無しさん：2011/12/11(日) 21:36:35.06

バージョン管理ソフトの欠点は
使い方を理解している人が明示的に使わない限りは
全く機能しないってところだな

828 ：デフォルトの名無しさん：2011/12/11(日) 21:43:25.58

>824
WindowsのMercurialで、ファイル数2万ぐらいの画像ファイルの管理をした時の不満点は、
・TortoiseHGのパフォーマンス劣化が酷い
・上位のディレクトリ名を変更したら、ファイル追加と同じぐらい激しくリポジトリ肥大
・addのcommit中に共有違反で読めないファイルがあった時、リポジトリがぶっ壊れた

特に最後の奴が痛かった。常識的に考えて、エラーならアトミックにロールバックしろよ。

829 ：デフォルトの名無しさん：2011/12/11(日) 21:44:47.60

ごめんなさい

830 ：デフォルトの名無しさん：2011/12/11(日) 22:23:38.15

リポジトリ破壊とかﾋﾄﾞｽｗ

831 ：デフォルトの名無しさん：2011/12/11(日) 22:27:19.66

だからリポジトリをバージョン管理しておけって言ったのに…

832 ：デフォルトの名無しさん：2011/12/11(日) 22:37:10.72

>>828
Mercurialって最近largefile拡張とかサポートしてたキガス

833 ：デフォルトの名無しさん：2011/12/12(月) 00:34:37.98

>>824
そのくらいなら実際に開発してた。
ディレクトリの切り方がまともなら十分可能。
常にその数を相手にするのはきついなあ。

834 ：デフォルトの名無しさん：2011/12/12(月) 00:48:50.75

>>817
ケチつけられるのが嫌ならいい加減なこと書かなきゃいいのに。

835 ：デフォルトの名無しさん：2011/12/12(月) 01:11:47.52

>>834
いい加減だったのは謝る。でも誰もsvnサーバーで巨大ファイルのテストを
してないのにケチだけつけるのは驚きだ。

836 ：デフォルトの名無しさん：2011/12/12(月) 09:53:03.48

見事なお子様反応。
「ぼく悪くないもん！」

837 ：デフォルトの名無しさん：2011/12/12(月) 10:50:40.41

テストになってないし無意味だからなｗ

838 ：デフォルトの名無しさん：2011/12/12(月) 11:23:56.12

>>835
お前2chは初めてか？力抜けよ。

839 ：デフォルトの名無しさん：2011/12/12(月) 12:17:56.61

テストしてみた。1.4GBのzipファイルをコミットしてみた。
ローカルファイルシステムを使った場合 → svn.exe が約10MB使用
svnserveを使った場合 → svnserve.exe が約10MB、svn.exe が約8MB使用
ファイルの最後にわずかな変更を加えて再コミットした場合も同様だった。

840 ：デフォルトの名無しさん：2011/12/12(月) 12:37:02.31

>>839
svnのバージョンは？
1.6と1.7ではクライアントは全く違う。

841 ：デフォルトの名無しさん：2011/12/12(月) 12:45:54.17

>>840
たまたまはいってた古い1.5.2でやった。何でやればいい?

842 ：デフォルトの名無しさん：2011/12/12(月) 12:49:33.24

>>841
1.7

843 ：デフォルトの名無しさん：2011/12/12(月) 13:35:08.79

>>842
VisualSVNのコマンドラインツールでやった。サーバー、クライアントとも1.7.2。
1回めのコミット→サーバー20MB、クライアント5.5MB
2回目のコミット→サーバー20MB、クライアント5MB
使ったファイル→Jazz RationalTeamConcert3.01配布ファイルのzip 1.4GB
2回めのコミットの前に「echo a >> ファイル」でファイルに内容を追加した。

844 ：デフォルトの名無しさん：2011/12/12(月) 19:17:04.36

Git、Eclipse.orgでCVS、SVNを超える
http://www.infoq.com/jp/news/2011/12/eclipse-git

845 ：デフォルトの名無しさん：2011/12/12(月) 20:38:29.65

時代はgitだな。

846 ：デフォルトの名無しさん：2011/12/12(月) 20:53:04.53

http://hibari.2ch.net/test/read.cgi/tech/1310403238/778
778 ：デフォルトの名無しさん：2011/12/12(月) 19:41:23.29
>>777
後半のhgの所は間違っている。
bitbucketはプライベートリポジトリとして使われているケースが多い。
公開リポジトリが１つもないアカウントはいっぱいある。
hgのossプロジェクトは自前でリポジトリを立てている所が多い。
http://mercurial.selenic.com/wiki/ProjectsUsingMercurial

847 ：デフォルトの名無しさん：2011/12/12(月) 21:05:47.21

>>844
この著者はgithubが言いたいだけなんじゃないか。
Atlassianに買収される前のbitbucketは頻繁にサーバが落ちていたけど、
最近はほとんど無くなった。
機能もどんどん多くなってきている。githubとほとんど変わらない。
容量制限無し、プライベートリポジトリ、git/hg両方対応と、bitbucketの方が利便性が高い。
個人では公開はgithub、プライベートはbitbucketと使い分けているのが多い。
今後、githubからbitbucketに移動するプロジェクトも増えるのではないか。

848 ：デフォルトの名無しさん：2011/12/12(月) 21:27:55.21

どうしてbazaarちゃんを無視するの

849 ：デフォルトの名無しさん：2011/12/12(月) 21:33:23.02

>>848
Atlassianに聞いて

850 ：デフォルトの名無しさん：2011/12/12(月) 23:55:59.46

ファイラーなに使ってますの？

851 ：デフォルトの名無しさん：2011/12/13(火) 00:06:04.20

分散バージョン管理システムの詳細なガイド
投稿日 2010年2月21日
http://www.infoq.com/jp/articles/dvcs-guide

> 最初の頃パフォーマンスが悪かったため、Bazaarは周囲に影響を与える多くの
> 早期採用者(MozillaやSolaris、OpenJDK)を失いました。

Bazaarって遅いのかよｗ

852 ：デフォルトの名無しさん：2011/12/16(金) 01:38:32.73

大量のバイナリファイルを多くのユーザーで編集する環境で
git選択しにくいのはパフォーマンス云々よりlock出来ないのが痛い。

そんなわけで一定以上のリソースがある場合はPerforce
そうじゃないときはsvnって選択になっちゃってる。

853 ：デフォルトの名無しさん：2011/12/16(金) 01:39:12.54

適材適所でいいんじゃない？

854 ：デフォルトの名無しさん：2011/12/16(金) 07:18:50.98

>>853
その適材適所にみんな悩んでいるんだと思うが
いくら適材適所でも3も4も管理システム導入とか非現実的だし

855 ：デフォルトの名無しさん：2011/12/16(金) 07:26:33.87

>>852
つ>>397

856 ：デフォルトの名無しさん：2011/12/16(金) 07:30:03.15

>>397はリンク切れで新しいリンク
http://mercurial.selenic.com/wiki/LockExtension
Mercurialの主要コミッタ作なんで品質は大丈夫だろう

857 ：デフォルトの名無しさん：2011/12/17(土) 22:18:25.37

アイコンのビットマップ程度ならばともかく、ソースコード対象にしている版管理ソフトに巨大バイナリ管理を求めるのは間違っている。

858 ：デフォルトの名無しさん：2011/12/17(土) 22:24:21.44

>>857
これまでは

> ソースコード対象にしている

だったけど、今後

> 巨大バイナリ管理を求める

ってことで、ツールも対応してくれって言うことでしょ。

859 ：デフォルトの名無しさん：2011/12/17(土) 22:29:14.97

Subversion なんかじゃフツーにバイナリ管理するけど
git/Mercurial じゃできないのプププのプー
って話にならね?

860 ：デフォルトの名無しさん：2011/12/17(土) 22:35:02.11

>>859
Mercurialは、largefile extensionとlock extensionがあるとこのスレにあるのが見えない盲目？

861 ：デフォルトの名無しさん：2011/12/17(土) 22:57:34.77

>>860
話の流れも見えない馬鹿?

862 ：デフォルトの名無しさん：2011/12/17(土) 23:08:36.86

>>861
Mercurialは巨大バイナリも、ワード・エクセルなどを想定したロックも、両方対応しているってのが分からない馬鹿？

863 ：デフォルトの名無しさん：2011/12/18(日) 00:54:57.99

>>862
たぶん859は857に対してレスしてるんじゃね？

864 ：デフォルトの名無しさん：2011/12/18(日) 02:14:55.00

svnのバイナリ管理も程度に依るよな。
ゲームのグラフィクスなどの大型、大量バイナリを突っ込むと実用性に問題が出るほど重くなる。
Perforceはマシみたいだけど。

865 ：デフォルトの名無しさん：2011/12/18(日) 02:42:17.59

だねえ。
10G 前後ならまあ、なんとかなるけど、数倍になるとアウトだよ!
Perforce だとイケる? 桁上がったくらいはどう?

866 ：デフォルトの名無しさん：2011/12/18(日) 10:32:16.15

>>865
>Perforce だとイケる? 桁上がったくらいはどう?

評価版があるみたいだから、試してみれば？
http://www.toyo.co.jp/ss/perforce/download_soft_2010.2.html

867 ：デフォルトの名無しさん：2011/12/18(日) 14:14:40.34

自分ならバイナリの容量が1Gを超えるならsvnなりコード用のバージョンコントロールは使用しないがな。

868 ：デフォルトの名無しさん：2011/12/18(日) 16:58:55.49

とりあえずお前の内臓が破裂するぐらいのボディブローは出せるがな（笑

869 ：デフォルトの名無しさん：2011/12/18(日) 17:16:16.57

>>868
そのボディブローでVSSを抹殺してください

870 ：デフォルトの名無しさん：2011/12/18(日) 20:21:16.25

まだ使ってるとこあるのか

871 ：デフォルトの名無しさん：2011/12/18(日) 21:11:31.09

フリーソフトは駄目ってところが未だに多いからな。

872 ：デフォルトの名無しさん：2011/12/18(日) 21:31:44.39

>>868
うは～、腹いてー（笑）

873 ：デフォルトの名無しさん：2011/12/18(日) 22:12:30.18

要はGitHub日本法人(仮)とかが有料サポートすればいいんだな？

874 ：デフォルトの名無しさん：2011/12/18(日) 22:22:39.37

安心と信頼のCanonical印のBazaarをお使い下さい

875 ：デフォルトの名無しさん：2011/12/18(日) 22:38:46.11

始まる前から終わってた

876 ：デフォルトの名無しさん：2011/12/18(日) 22:39:07.29

>>873
git技術者検定とかやりそうだなｗ

877 ：デフォルトの名無しさん：2011/12/18(日) 22:40:59.18

>>874
Bazaarはマジでこのままだとジリ貧だろ
Linux関連の開発で使う限りではgitの方が使っているプロジェクトも技術者も多いし

Bazaarは今のバージョンで打ち止めして、新規に再設計した方が良いと思うわ

878 ：デフォルトの名無しさん：2011/12/18(日) 23:00:45.79

>>870
>まだ使ってるとこあるのか

あるよ～、って言うかそこそこの規模だとなかなか入れ替えられない。

879 ：デフォルトの名無しさん：2011/12/18(日) 23:43:43.22

VSSとBazaarの究極の組み合わせ
http://d.hatena.ne.jp/wonderful_panda/20111212/1323643703

880 ：デフォルトの名無しさん：2011/12/19(月) 00:08:40.00

自分のまわりにいないってだけで、書籍、Webドキュメント、記事、
膨大なOSSプロジェクトといっぱいありますが？

https://twitter.com/#!/methane/status/148328106841751552
> git へ移行する最大の障壁は、「gitのことならなんでも訊いて！」という人がいないこと。
> バージョン管理システムのワークフローの構築とかはこう言った先導者が必要。
> bzrは問題あったらぼくがなんでも解決できてたけど、gitはぼくが教えて欲しいくらいだしな。

881 ：755：2011/12/19(月) 00:55:41.26

>>880
この人は何者？

882 ：デフォルトの名無しさん：2011/12/19(月) 01:05:07.92

>>881
このスレの前半を見よう。
Bazaarの泥舟から脱出を検討している亡命予備者

883 ：デフォルトの名無しさん：2011/12/19(月) 01:23:13.62

BitKeeperってバイナリ管理どうなん

884 ：デフォルトの名無しさん：2011/12/19(月) 10:40:41.15

>>880
methaneさんは社内の人員のことを言ってると思うよ。
業務で使う場合、社内に強力に推進できる人がいないと結構大変だよね。

885 ：デフォルトの名無しさん：2011/12/19(月) 17:34:49.82

https://twitter.com/#!/methane/status/148657202620661760
今でも一応3つとも使ってますが、会社ではbzrを使うメリットがあまりないので、git, hg への移行を考え中。

886 ：デフォルトの名無しさん：2011/12/19(月) 19:27:10.46

[Bazaar]Git, Git, Git. たまに違うのが聞こえればHg. なぜこの俺を認めねぇ

887 ：デフォルトの名無しさん：2011/12/19(月) 20:23:07.50

Bazaar さん遅いですやん

888 ：デフォルトの名無しさん：2011/12/19(月) 20:41:56.16