11/02/26 10:34:13.89
bzrのアンチ活動とか不毛すぎるだろ……
263:デフォルトの名無しさん
11/02/26 10:37:46.68
>>262
svn/hgはメッセージ日本語化されているよ
264:デフォルトの名無しさん
11/02/26 10:41:05.75
自分が使う時にはいらないが、素人に使わせる事ような場合はメッセージが
日本語化されていると嬉しいかもしれんなぁ。
265:デフォルトの名無しさん
11/02/26 10:55:44.74
>264
素人がコンソールで使うわけ無いだろ。GUI必須。
266:デフォルトの名無しさん
11/02/26 10:55:58.34
どんだけdisっても、git、hg、bzrの三者は、向こう十年は使われ続ける体制ができちゃったし、
気に入らない物が残っちゃてご愁傷さまとしか言いようがない。
次の十年に向けての啓蒙活動を頑張ってください。
>>264
素人ならGUI使わせるんじゃないかな。
267:デフォルトの名無しさん
11/02/26 11:13:32.83
>>266
そして、素人のwindiff、kdiffが化けますというクレームに、玄人が対応できていません、と答えるのですね
268:methane
11/02/26 12:12:01.68
>>261
そろそろi18nしたいな。bzr-2.4までにできればやるよ。
>>267
bzr qdiff は、ファイルのエンコーディングをGUI上で選択できる
ようにはしておいた。玄人は素人にエンコーディングを教えて
あげてください。
269:デフォルトの名無しさん
11/02/26 12:42:29.67
>>268
WindowsでCP932で表すことができないファイル名のファイルはwindiff、kdiff3立ち上げられないよね？
cmd.exeでdiffしたとき、ファイルの中身がutf-8だった場合、激しく化け化けになるよね？
270:methane
11/02/26 15:15:05.28
>>269
前者は何とかする予定。
後者はさすがに無理ゲー（勝手にdiffの出力を変えたらpatchが動かない）なので
プラグイン作ってオプションで回避するかな。
俺は | gvim - で見てる。
271:デフォルトの名無しさん
11/02/26 15:23:25.20
>>270
ということは、bzrのパッチもLinuxではロケール依存なのですね？
Windowsで作成されたパッチをLinuxであてるには、ja_JP.SJISでチェックアウトしないといけないのですね？
272:methane
11/02/26 15:37:40.65
>>271
何処をどう読めばそうなるんだろう…？
ファイル名をロケール関係なく出力するからwindowsのコマンドプロンプトに
utf-8のファイルの内容を出力すると化けるんであって、それをリダイレクトで
patchファイルにしてLinuxに持って行ってpatchできるよ。
ただし、ファイル名はロケール依存になっちゃってるから、日本語ファイル名の
patchを作るときにはdiffは使えなくて、代わりにbundleという形式を使う。
273:methane
11/02/26 15:38:21.18
あ、間違えた。
s/ファイル名をロケール関係なく/ファイルの内容をロケール関係なく/
274:デフォルトの名無しさん
11/02/26 15:42:10.39
bzrのcmd.exeの標準出力はCP932だよね？
ファイル名がCP932でファイルの中身がUTF-8の場合。
これを化けずにどうやって読むのでしょうか？
275:methane
11/02/26 15:46:43.42
>>274
そのケースではファイル全体を化けないように観るのは無理。
GUI使うかコマンドラインでも変換するプラグインを使って。
276:デフォルトの名無しさん
11/02/26 15:50:34.51
>>275
そのプラグインとは？
277:methane
11/02/26 16:18:29.23
>>276
URLﾘﾝｸ(gigo-ice.org)
278:デフォルトの名無しさん
11/02/26 16:49:58.73
UTF-256とか作っちまえよ
279:デフォルトの名無しさん
11/02/26 16:52:14.55
>>278
スレ違い
ｽﾚﾘﾝｸ(tech板:781番)
280:デフォルトの名無しさん
11/02/26 18:07:45.87
使える文字が増えれば良い訳じゃない
増えたら、増えたで、また、やっかいな問題が出てくるもんだ
281:デフォルトの名無しさん
11/02/26 19:49:35.74
>>231
IDEを使うなら、utf-8ロケールのLinuxデスクトップで、
EclipseならGit、NetbeansならMercurialを使うことでオールオッケー
282:デフォルトの名無しさん
11/02/26 20:26:39.66
どでもいいんだが, プロジェクトが Unix 前提で構築されてて
ファイル名の銘々規則が
<module-name>:<function>.<ext>
な, VCS に MS Windows でつないでファイル名が
読めないって騒ぐのはよしてほしい
はなっから命名規則がやばいんで Windows からみると,
まともなファイル名は見えないって言ってるのにw
283:デフォルトの名無しさん
11/02/27 00:59:26.45
どうでも良いと言いつつ、文句を言う奴っているよね
284:デフォルトの名無しさん
11/02/27 01:03:08.98
最近の本を見るとbzrを以上に推してるな
最近の本で言えばプログラマが覚えるべき○○の事とかも最初にbzrの名前が挙がってた
だから他の分散管理はもっとがんばれ
勢いがいないぞ
285:デフォルトの名無しさん
11/02/27 01:23:27.31
>>184
うん、いいと思うよ。俺も一人だけ作業ならそうしてる
286:デフォルトの名無しさん
11/02/27 05:42:50.73
>>284
git, hgの本は売っているけど、bzrの本は売ってる？
287:デフォルトの名無しさん
11/02/27 05:47:23.01
売ってない気がする
bzrはアジャイル設計とかそういうプロジェクト管理系の本でよく見かけるようになったね
288:デフォルトの名無しさん
11/02/27 06:23:31.25
>>284
git, hg本体は枯れていて安定期に入ってるから勢いが無いようにみえるかもしれない
TortoiseHg 2.0 が３月１日に出る予定なので、hgは勢いつくかもしれない
いろいろ目玉はあるけど、このスレ的には、MacOSX対応かな？
289:デフォルトの名無しさん
11/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
URLﾘﾝｸ(qa.debian.org)
URLﾘﾝｸ(packages.debian.org)
gnuit (4.9.2-1) unstable; urgency=low
> * Package name changed to gnuit.
> * Added transitional git package.
> -- Ian Beckwith <ianb@erislabs.net> Thu, 10 Jan 2008 22:04:26 +0000
URLﾘﾝｸ(packages.debian.org)
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
> URLﾘﾝｸ(lists.debian.org)).
> -- Gerrit Pape <pape@smarden.org> Sat, 03 Apr 2010 15:07:19 -0500
290:デフォルトの名無しさん
11/02/28 17:37:23.77
>284
全然見ないよ。
最近は、本そのものをね。
bzrは、btrfsと同じで名前が途轍もなく格好悪いので
geek心をくすぐらないと思う
>>288
OSX対応って・・・MacHgで十分だったんだけど・・・
Finderに統合って、結構鬱陶しいってことがSubversionの時に分かったし・・・
291:デフォルトの名無しさん
11/04/01 03:23:44.79
Monotone が 1.0 になったみたいだけど、国際化対応とかユーザー認証の暗号化とかあるし、
期待してもいいんだろうか。
292:デフォルトの名無しさん
11/04/02 20:39:47.88
あげたら
293:デフォルトの名無しさん
11/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
URLﾘﾝｸ(po3a.blogspot.com)
> もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
> ほんとに。連中は「本物のデータベース」を使っているよ。
> 「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
> 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
> これらすべての設計上の決定のために、できてきた結果はゲロゲロで
> 保守不可能なカオスだ。
294:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/04/02 23:53:55.07
速度を犠牲にしたバカげた設計をしてしまったのがSubversionとBazaarかw
296:デフォルトの名無しさん
11/04/03 01:08:09.17
URLﾘﾝｸ(www.infoq.com)
297:デフォルトの名無しさん
11/04/03 02:51:43.75
SubversionはCなのに遅いからなぁ。あの遅さはUTF-8のせいだけじゃないんじゃないか。
まあでもCVSの代替としては長く使わせてもらったし、あの時点では最良だったと思う。
298:デフォルトの名無しさん
11/04/03 03:14:47.45
結局、どれもこれも帯に短し襷に長し、決定版と言うのはないのかね？
299:デフォルトの名無しさん
11/04/03 21:22:38.97
ないから色々あるんじゃないか？
300:デフォルトの名無しさん
11/04/03 21:26:45.16
帯も襷もあるが、襷としても使える帯は無いし、
帯としても使える襷は無い、ということか。
301:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/04/08 10:18:19.21
Subversionのしかもwindows版TortoiseSVNから使い始めた俺は
遅くてもこんな物なんだろうと思っているからきっと幸せ。
つーか、俺、最初に手をつけた物が良いという思い込みが強くて
なかなか移行できない性格で難儀。
303:デフォルトの名無しさん
11/04/08 11:24:36.98
>>302
VSSに触らなくて良かったな
304:デフォルトの名無しさん
11/04/08 14:53:29.00
パスが含まれているようなファイルはどう管理したらいいのですか？
オープンなリポジトリにそのままコミットするわけにはいかないと思うので。
305:デフォルトの名無しさん
11/04/08 14:56:19.22
2文字読んでpathかと思ったらpasswordか。
* sensibleなデータだけ別ファイルになるような構成にして、リポジトリに入れないようにする。
* 暗号化したものを入れておいてデコード手段はリポジトリに入れないようにする。
など。
306:デフォルトの名無しさん
11/04/08 15:38:36.19
パスワードは環境変数にしてるなあ。仕事じゃないけど。
307:デフォルトの名無しさん
11/04/08 17:35:21.28
なるほど・・・参考になりました！
ありがとうございます。
308:デフォルトの名無しさん
11/04/13 14:20:21.44
これからバージョン管理を導入しようと思い調べたのだけれど、
有名どころだけでも結構あるんだね。
数人で1プロジェクトのソースが100ファイルで合計1MBに満たない
ようなレベルならTortoiseSVNあたりで十分かな？
ネット上の情報も一番多い感じなので、取っつきやすいと感じた。
それとも、今から覚えるなら、こっちにしておけっていうのあります？
309:デフォルトの名無しさん
11/04/13 14:33:52.97
やっぱsvnが無難でしょ。
TortoiseSVNってことはWin環境なんだろうけど、サーバー側はVisualSVN Serverを勧めておく。
さらにVisual Studio使ってて金が出せるなら、AnkhSVNよりVisualSVNがお勧め。
何だかんだ言って、インテグレーションの出来が違いすぎる。
310:デフォルトの名無しさん
11/04/13 15:48:40.56
>>309
ありがとう。
ちょっとVisualSVN Server、VisualSVNこの辺を調べてくる。
名前が似てるけど、全然別物なのか。
311:デフォルトの名無しさん
11/04/13 19:54:25.29
VisualSVNそんなに良いの？いくらするんだっけ？
AnkhSVNもまあまあ悪くはないかと思ったけど
312:デフォルトの名無しさん
11/04/13 23:17:07.73
AnkhSVNでも入れないよりは全然マシ。
今やってるプロジェクトはそれすら使っていないから
VS上でファイル名変更されると履歴が参照できずバージョン管理の意味が無くなってる。
313:デフォルトの名無しさん
11/04/14 02:06:48.18
Mercurialなら、名前変更の推定処理が出来るのに。
314:デフォルトの名無しさん
11/04/14 02:18:52.78
Hgもリネームは推定なのか。Gitもそう。
315:デフォルトの名無しさん
11/04/14 05:50:39.51
>>314
hg addremoveコマンドが推定。"--similarity 類似度"でパーセントを指定できる。
ファイルの移動はリポジトリに記録される。
316:デフォルトの名無しさん
11/04/14 14:42:44.77
>>315
え、移動はリポジトリに記録される、けどリネームは推定なの？
リネームと移動は同じじゃないか…？
317:デフォルトの名無しさん
11/04/14 14:57:42.25
>>316
hgのファイルの移動はコピーして削除。これはリポジトリ（マニフェスト）に記録される。
コピーしたものもマージ時に反映される。
ファイルの移動はhg renameコマンドを使うのが一般的。
hg addとhg removeコマンドがあって、それぞれ、ファイルを追加したとき、削除したとき、
パラメータ無しで追加、削除を自動的に認識するコマンド。
hg addremoveはそれを合体させたもので、--similarity 100がデフォルトの値で、
ファイルが改変されていないものは移動と認識されて、commit時にそれが反映される。
318:デフォルトの名無しさん
11/04/14 15:11:44.05
>>317
＞これはリポジトリ（マニフェスト）に記録される
「コピーして削除」のみならず「移動」としての情報が記録されるということ？
つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな？
それとも--similarity 100の時だけ「移動」として特別に記録？
319:デフォルトの名無しさん
11/04/14 15:46:11.01
>>318
> ＞これはリポジトリ（マニフェスト）に記録される
> 「コピーして削除」のみならず「移動」としての情報が記録されるということ？
リポジトリ（マニフェスト）には、コピーしたというのと削除したというのが別々に記録される。
aaa -> bbb
・bbbはaaaのコピー
・aaaは削除
> つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな？
> それとも--similarity 100の時だけ「移動」として特別に記録？
hg addremoveがファイルの移動をコピーと削除として判断する。
hg status のオプション"--copies"で確認可能。
この結果をcommitで確定させる。
320:デフォルトの名無しさん
11/04/14 17:17:45.25
>>319
なるほど、そうなるとsvnと似たやり方かな。
Gitはそういうの一切記録しなくて、履歴を表示する時に動的に分析してる。
全く同時期に同じ目的で開発されたものだけど、けっこう違うんだねえ。
321:デフォルトの名無しさん
11/04/15 06:18:40.99
Goodbye Subversion, Hello Mercurial: A Migration Guide
URLﾘﾝｸ(blogs.atlassian.com)
322:デフォルトの名無しさん
11/04/25 09:25:35.79
ひさびさにTortoiseHgをあぷでとした
チャンクごとのコミットが面倒なことになってないかい
なんだよこれ
323:デフォルトの名無しさん
11/04/25 10:18:19.53
>>322
TortoiseHg 2.0の大幅なユーザインターフェースの更新に抵抗がある方は、
1.1.xの最新版を使うことをお勧めします。
URLﾘﾝｸ(bitbucket.org)
324:デフォルトの名無しさん
11/04/25 10:37:51.10
そうですか
よくみたらメジャーアップデートしてたんだ
日本語の方マニュアルやリリースノートも更新してくれればなあ！
325:デフォルトの名無しさん
11/04/25 20:04:58.45
Git 1.7.5がリリース、メッセージの国際化へ一歩
URLﾘﾝｸ(www.atmarkit.co.jp)
326:デフォルトの名無しさん
11/04/25 21:03:39.77
日本語ファイルが使えるならgit一択なのにな
327:デフォルトの名無しさん
11/04/25 21:06:26.08
>>326
使えるよ
328:デフォルトの名無しさん
11/04/25 21:09:21.90
あれ、そなの？
Win、Mac、Linuxの環境でsvnのように何の問題もなくなったの？
329:デフォルトの名無しさん
11/04/25 21:11:41.67
>>328
さて、svnのどこが何の問題が無いのでしょうか？
330:デフォルトの名無しさん
11/04/25 21:37:51.11
Git一択というほどGitいいのか。
今、MercrialとBazaarを試用しているけれど、Gitも試してみるか。
331:デフォルトの名無しさん
11/04/25 23:10:29.20
>>329
日本語のファイルの取り扱いが問題ありません
他はすべて日本語の扱いに問題有り
332:デフォルトの名無しさん
11/04/25 23:28:01.24
>>331
つ>>8
svnも問題あり、というよりマルチプラットフォームで問題ないものは無い。
333:デフォルトの名無しさん
11/04/25 23:28:50.00
>>332
それは既にパッチあるだろ
334:デフォルトの名無しさん
11/04/25 23:30:51.91
パッチどころか本家で既に対応済み
何年前の話だよ…
335:デフォルトの名無しさん
11/04/25 23:51:51.89
で、bzrも2.3だといけるらしい。
336:デフォルトの名無しさん
11/04/25 23:53:23.91
gitとhgｵﾜﾀｗ
337:デフォルトの名無しさん
11/04/26 00:20:04.65
svnは対応はできていません。
URLﾘﾝｸ(subversion.tigris.org)
bzrもだめです。
URLﾘﾝｸ(bugs.launchpad.net)
338:デフォルトの名無しさん
11/04/26 00:26:22.54
OSXなんて捨て捨て
339:デフォルトの名無しさん
11/04/26 00:28:10.54
windowsとlinuxとの連携ならsvnとbzrが最強なんだっけか？
340:デフォルトの名無しさん
11/04/26 01:10:25.90
ユニコードに過度な期待は禁物です
341:デフォルトの名無しさん
11/04/26 08:48:59.32
http://iup.2ch-library.com/i/i0291902-1303775239.jpg
342:デフォルトの名無しさん
11/04/26 09:05:53.42
>>337
Mac ports の svn は対応パッチ済みです。
bzr も完全に解決したかの確認がまだだけど、2.3で現在までに報告されている
ケースは解決されています。
Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の
扱いには満足していたんだし、Mac OS X の問題もとりあえず対応策が広まったし、
Unicodeでファイル名を扱うことを危険だと叫んでるのはただのFUD
Unicodeはすべての問題を解決してくれるわけではないが、文字コード周りの問題に
対するコストパフォーマンスの高い対応策。
343:デフォルトの名無しさん
11/04/26 09:15:25.50
>>342
GitとMercurialでファイル名に「ユニコード」が使えないという誤解を相変わらずバラ撒いている方がFUD
344:341
11/04/26 09:21:33.19
言い忘れたけど上の画像はOSXね
345:デフォルトの名無しさん
11/04/26 09:22:06.40
>>343
このスレでだれがそんなFUDを言ってる？
それとも、Mac OS X のNFD(モドキ)正規化問題に対応できてないというのがFUD？
346:デフォルトの名無しさん
11/04/26 09:22:54.02
>>342
> Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の
> 扱いには満足していたんだし、
満足なんかしてないよ。
波ダッシュとかの問題とか考えれば、永続的にメンテが必要なシステムに
ファイル名変換が行われるものなんか使わないよ。
347:デフォルトの名無しさん
11/04/26 09:23:56.85
>>344
Windowsでばーかというファイルを作成してMacでチェックアウトして
編集せずに git diff したら、何もしてないのにファイル名が変更されたって
報告されない？
348:デフォルトの名無しさん
11/04/26 09:26:52.41
>>345
つ>>208
349:デフォルトの名無しさん
11/04/26 09:27:11.56
>>347
GitHubにでもレポ作ってくれれば試すよ
興味あるし
350:デフォルトの名無しさん
11/04/26 09:30:01.93
>>346
たしかに、みんなは言い過ぎだな。
でも、波ダッシュ問題もWindowsだったらUTF-16で、LinuxやMacではUTF-8で扱えば
一切Shift-JISとの変換なんて起こらないし、多くの人は一部の文字が使えない
ことよりもリポジトリ内に複数の文字エンコーディングのファイル名が混ざる事や
たくさんの独自パッチ済みクライアントが乱立する方が管理が面倒だと感じて
CVSからSubversionへの変化を喜んでいた。
WinCVS日本語版でみんなこのオプション使いましょーねというルール決めても時々
設定間違ってコミットする人がいてリポジトリの内容が文字化けしていた時代に
戻りたいという人がどれくらいいるか。
351:デフォルトの名無しさん
11/04/26 09:30:43.31
>>347
gitは知らんが、hgはMacユーザがaddremoveすればWin/Linux/Macユーザみんなハッピー
352:デフォルトの名無しさん
11/04/26 09:34:07.00
>>349
URLﾘﾝｸ(gist.github.com)
git clone git://gist.github.com/941544.git
353:デフォルトの名無しさん
11/04/26 09:35:06.00
>>351
Windows の hg って utf-8 ファイル名まともに使えるようになったんだっけ？
354:デフォルトの名無しさん
11/04/26 09:36:39.26
>>353
cygwin、fixutf8
355:デフォルトの名無しさん
11/04/26 09:37:13.47
>>351
あと、その方法だとLinux/Winユーザーがpullしてファイル名がNFDになると、
コマンドラインからファイル名指定するときに普通に日本語入力システムで
変換するとNFCになっちゃうからファイル名指定できなくて全然ハッピーじゃない。
356:デフォルトの名無しさん
11/04/26 09:39:58.20
>>354
fixutf8 ってもう安定して使えるのかな。TortoiseHGとの連携大丈夫？
cygwinを使う方法については、cygwinが必要だというのを明示せずに
「utf-8使えるよ」というのは、まどかシステム以前のQBのような気がするので、
ちゃんと「cygwin使えばutf-8使えるよ」と言って欲しい。
357:デフォルトの名無しさん
11/04/26 09:40:24.04
>>355
hgでコマンドラインでファイル名指定するのはhg log FILEぐらい。
hg add/remove/addremoveは自動認識するし。
358:デフォルトの名無しさん
11/04/26 09:43:16.46
>>357
チェックアウトしたファイルを開こうとして
$ vim ばーか.txt
ってやる場合を考えると、hgで直接ファイル名指定する機会が少ないというのは
リポジトリ内にNFDを突っ込む問題の一部しかカバーできてないと思う。
359:デフォルトの名無しさん
11/04/26 09:47:23.72
まとめ
日本語を使うのなら、、
集中型ならsvn
分散型ならbzr
日本語は使わないのなら、、
速いのが好きならgit
googleが好きならhg
360:デフォルトの名無しさん
11/04/26 09:49:21.95
>>358
たしかに「ば」が先頭だとシェル補完が厳しいなぁ・・・
361:デフォルトの名無しさん
11/04/26 09:49:36.10
>>352
git diffだと何も表示されないがgit statusだとUntracked fileとして表示されるね
WindowsのMsysGitを使った場合だとLinuxやMacではこういうことが起きるのか
勉強にはなったが、どうしようかなあ
362:デフォルトの名無しさん
11/04/26 10:40:10.09
ソースコードの中身ならまだしも、ファイル名に日本語とか情弱の極みだろ
363:デフォルトの名無しさん
11/04/26 11:18:24.43
まだ>>362みたいなことを言ってる馬鹿がいるんだな
364:デフォルトの名無しさん
11/04/26 11:23:43.49
ぶっちゃけどのバージョン管理システムかの問題じゃなくてWindowsの問題だよね
365:デフォルトの名無しさん
11/04/26 11:29:07.24
ファイル名はutf-8ではなくutf-7にしよう
366:デフォルトの名無しさん
11/04/26 13:08:35.45
自分、英語がプアなもんでファイル名に日本語が欠かせません！
英語にしてもそこそこ把握できる場合（予想）
『ワルプルギスの淫夢.txt』
『奴隷少佐ルクレツィア.txt』
英語にしたら把握に時間がかかるか訳がわからない場合（予想）
『目覚めると従姉妹を護る美少女剣士になっていた.txt』
『俺のフラグはよりどりみデレ.txt』
というような場合もあるんじゃないかな？
仮定、想像の話だけど。
367:デフォルトの名無しさん
11/04/26 13:36:52.35
確かにそうだな。
それはそれとして、そのtxtの中身について話をしたいのだが。
368:デフォルトの名無しさん
11/04/26 13:45:20.85
非実在テキストファイルですから。
何分、仮定、想像の話なので。
369:デフォルトの名無しさん
11/04/26 14:22:22.90
>>364
Windowsはutf-16 のAPIを提供しているのでそれを使えば問題ない。
どっちかっつーと、Mac OS X の方が、バージョン管理システムに限らず
ファイルをアップロードするときとか、zipファイルの中身とかいろんな
場面に影響するので凶悪。
370:デフォルトの名無しさん
11/04/26 14:49:34.62
>>369
ファイル名の話してんのに何言ってんの？
論点のすり替え乙
371:デフォルトの名無しさん
11/04/26 16:19:32.78
>>370
ファイル名の話だよ？
Windowsは10年以上昔(NT 4.0)からファイル名はUnicodeで扱っている。
Shift-JISなどでアクセスするAPIはレガシー用の互換APIで、基本的に使うべきではない。
372:デフォルトの名無しさん
11/04/26 16:23:47.02
厳密に言えば NT 3.1 (93年) だけど、サーバー、ワークステーション向けを
のぞいたらWinXP (01年) だから、10年以上ではないな。
373:デフォルトの名無しさん
11/04/26 16:24:17.13
いやだからファイル名の
話だろ？
374:デフォルトの名無しさん
11/04/26 16:24:26.87
Mercurialは、pythonがクソでレガシーAPI使ってるのが癌なんだろ。
375:デフォルトの名無しさん
11/04/26 16:25:13.49
あ
最新レス見ずに書いちゃった
376:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/04/26 16:31:31.57
>376
それがクソって言ってんの
378:デフォルトの名無しさん
11/04/26 16:34:02.13
>>377
えー、これがクソならどうしろと、、、
C#やJavaみたいにバイト列でファイルパスを指定するの禁止したらUnix系で
すごく使いにくくなるんだけど。
Python の仕様は超現実的で、RubyやPerlよりもずっとWindowsで使いやすいと
思ってる。
379:デフォルトの名無しさん
11/04/26 17:11:59.63
というかそれならMercurialで問題になってるのは何なの
380:デフォルトの名無しさん
11/04/26 18:26:12.29
>>379
URLﾘﾝｸ(mercurial.selenic.com)
381:デフォルトの名無しさん
11/04/26 18:29:23.48
>>379
英語のwikiにはNTFSはUTF-16となっているが、実際は２バイトのバイト列。
UTF-16としては不正な値も格納される。
382:デフォルトの名無しさん
11/04/26 18:33:09.11
NTFSがUTF-16とは書いていないか。
> kernel has a mix of byte-width and wide character APIs
383:デフォルトの名無しさん
11/04/28 10:45:25.11
Windowsシステムオンリー。日本語ファイル名あり。日本語ディレクトリあるかも。
Git、Mercurial、Bazaarから、上記の条件で考えた場合、分散型初心者が取っつき
やすいのは日本語対応が進んでいるBazaarでしょうか？
384:デフォルトの名無しさん
11/04/28 11:04:37.41
その条件ならシェル統合がまともに動くMercurialじゃないか
385:デフォルトの名無しさん
11/04/28 11:10:24.25
Bazaarは日本語対応進んでいないでしょ。
386:デフォルトの名無しさん
11/04/28 11:15:43.07
Windows onlyならhg、bzrのどちらでもいいと思う
でかいファイルを扱うならhgかな
387:デフォルトの名無しさん
11/04/28 11:16:05.67
書籍の有無、Web上での情報量、CUI/GUIのメニューの日本語化を含めて日本語対応と言うべきであって、
Mercurialが一歩抜き出ていて、CUI/GUIのメニューは >>325 でGitも対応する方向だと言う認識だが。
388:デフォルトの名無しさん
11/04/28 11:18:50.31
bitbucketとlaunchpadなら断然bitbucket
githubの方がもっといいけど
389:デフォルトの名無しさん
11/04/28 11:19:07.53
分散だと日本語環境はbzrが独占状態なのよねぇ。
他は何をやってんのやら。
390:デフォルトの名無しさん
11/04/28 11:23:24.89
>>389
> 分散だと日本語環境はbzrが独占状態なのよねぇ。
> 他は何をやってんのやら。
「Windowsのファイルシステムの」日本語環境でしょ。
Windows上で日本語ファイル名を使わなければ、Git、Mercurialでは何も不自由しないけど。
391:デフォルトの名無しさん
11/04/28 11:27:13.00
そうはいっても
○○支社向け.docとか
○○部長月間予定.xlsとか
いう日本語ファイル名って結構使うからねぇ
392:デフォルトの名無しさん
11/04/28 11:31:50.17
>>391
リポジトリを分ければ良い。
そういうファイルがあるところだけsvnにすれば良い。
svnはリポジトリを一ヶ所にするというのが一般的のようだが、
別に一ヶ所にする必要もない。
393:デフォルトの名無しさん
11/04/28 11:35:09.66
運用ポリシーで複数の管理システムを使うのはちょっとね
後々の事を考えてシンプルにしないとさ
394:デフォルトの名無しさん
11/04/28 11:46:48.22
Windowsだけで使う分にはHgでも日本語ファイル問題ないだろ？
395:デフォルトの名無しさん
11/04/28 11:48:38.19
>>394
CP932に無いUnicodeの文字も増えてきているからねえ・・・
396:デフォルトの名無しさん
11/04/28 14:21:26.83
○○支社向け.docとか○○部長月間予定.xlsとかは分散してる必要無いんじゃないか。
どうせマージ出来ないだろうから、むしろ分散してたら不都合な気がする。
そういうのはsvnでいいんじゃね。
397:デフォルトの名無しさん
11/04/28 14:50:19.02
>>396
Mercurialはロックを実装する気でいるぞ。
URLﾘﾝｸ(mercurial.selenic.com)
398:デフォルトの名無しさん
11/04/28 15:39:09.50
>>397
分散型でlockとかｗｗｗ
というのは釣りですが、それでワークフローがうまく回るなら良いですね。
特に仕事でアジャイル（）とかだと分単位で作業が入り乱れるだろうから、
バグトラッカとかでやりとりするよりもスムーズかも知れない。
399:デフォルトの名無しさん
11/04/28 15:39:15.31
かといって、1プロジェクトに関わる設計書とかが単一の管理から外れるのも困る。
結局のところ、運用でごまかせって感じになっているのがなぁ。
誰だよ1バイト圏意外に住んでいるやつは。
400:デフォルトの名無しさん
11/04/28 16:10:18.30
>>396
中央リポジトリ関係無く好きに各ローカルリポジトリにプッシュ/プル出来るから分散のメリットは大ありだよ
人間の相関と分散管理はすごく相性がいいから無駄なんていっちゃいかん
401:デフォルトの名無しさん
11/04/28 16:13:02.54
×無駄なんて
○不都合だなんて
失敬
402:デフォルトの名無しさん
11/04/28 16:41:36.52
>>400
ワードとかエクセルのマージ作業はどうするの？
403:デフォルトの名無しさん
11/04/28 16:43:59.18
それって別に分散かどうかは関係ないよね
404:デフォルトの名無しさん
11/04/28 16:49:45.42
>>403
マスターリポジトリにプッシュするまでもない物をとりあえず確認するために
個人のローカルリポジトリにアクセスしたりとか
個別相談受けて訂正する時にその人のローカル除いたりとか色々ある
メッシュ網じゃないsvnなんかじゃこういうのは出来ないのさ
405:デフォルトの名無しさん
11/05/01 14:39:55.41
gitやhgが「Windowsでは」Unicode APIを使わずにバイト列でファイル名を扱うのはなんなんだ
バイト列なら>>376の言うようにPythonが対応しようが解決できないよね、これ
BazaarのようにUnicodeと決めているならUnicode APIに渡すときに変換なりするわけでしょ
でもバイト列で扱う方針なら変換できないよね
localeに応じて変換するのだろうか
マルチバイトのファイル名のマルチプラットフォームの問題はそもそも解決できない問題なの？
406:デフォルトの名無しさん
11/05/01 15:02:14.19
根本的には、ファイルシステム毎に使える文字が違うんだから細かい差異まで吸収できるわけがない。
やろうと思えば主要ファイルシステムの動作をエミュレートできるようにしたうえで、addした時のファイルシステムを覚えておくことになるだろうし。
それとは別に、必要な変換をしてくれないのは単なる無理解と手抜き。
gitについてはLinux上で最高のパフォーマンスが出せれば後はどうでもいいという大義名分があるけど、hgは単に開発者が無理解なだけだろ。
(bzrの互換漢字を正規化してしまう問題も、そんなことをするファイルシステムが現存しない以上やり過ぎと言える)
407:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/05/01 15:23:53.14
>>406
> hgは単に開発者が無理解なだけだろ。
無理解とは思えないが。
URLﾘﾝｸ(mercurial.selenic.com)
cmd.exeとGUIアプリの扱いが違うというのは、このスレでは話題になっていなかったが。
bzrがcmd.exeでCP932の方が無理解だと思うが。
409:デフォルトの名無しさん
11/05/01 15:29:36.71
hgが叩かれる時のリンクじゃないかそれ
cmd.exeでもW版APIを使えばokというのが周知されてないのも無理解の象徴だな
410:デフォルトの名無しさん
11/05/01 15:33:04.46
>>409
cmd.exeでwは使えない。
wprintf()がcp932とかcp1252の時にデータが欠損する。
411:デフォルトの名無しさん
11/05/01 15:35:38.99
>>409
bzrでお馴染みのpythonのコーデックエラーは、cmd.exeのことを考慮していない証拠。
412:デフォルトの名無しさん
11/05/01 15:37:30.80
使えるっての。
libcではなく自分でAPI呼べよ
413:デフォルトの名無しさん
11/05/01 15:45:46.84
>>412
chcp 1252 して日本語混じりのをwprintfしたら何が出力される？
だったら、printfでバイト列で出力した方がマルチプラットフォームアプリとしては
正しいと思うが。
414:デフォルトの名無しさん
11/05/01 16:09:39.19
>>413
cmdでUnicode使わない背景には、cmdのフォントの設定によっては表示されない
恐れがあるからという理由があったはず。
まぁ、一番は単に他の部分のファイルのインタフェースと整合性を取るのが大変
だからだろうけど。
CLIでunicode使いたかったら cygwin + minitty が最強。
415:414
11/05/01 16:10:15.09
>>412 だった。
416:デフォルトの名無しさん
11/05/01 16:14:13.63
UnicodeじゃないからUnicode版API使えないと言いつつ、
得体の知れないバイト列をANSI版APIに流し込む矛盾。
417:デフォルトの名無しさん
11/05/01 16:15:14.84
>>412
出力って何のこと？diffとか？
418:デフォルトの名無しさん
11/05/01 16:18:07.25
>>416
CP932と繁体字がASCIIと互換が無いから問題なのであって、
それ以外のコードページとLinuxでは、シングルバイト用のAPIで何ら問題が無い。
419:デフォルトの名無しさん
11/05/01 19:18:31.36
>>413
さすがPowerShell ISEさんに隙はなかった・・・
420:デフォルトの名無しさん
11/05/01 19:21:34.79
>>419
Mercurialは--encodeオプションかHGENCODING環境変数で、UTF-8が指定できるから、
PowerShellでも問題ない。これが正しい多言語化。
421:デフォルトの名無しさん
11/05/01 19:23:30.72
--encodingだった。
--encodingmodeってのもある。
422:デフォルトの名無しさん
11/05/01 19:40:05.99
>>420
や、俺が言ってるのはコンソールとしてのpowershell_ise.exeのことね
chcpコマンドがまともに機能するWin7標準のアプリ
従来の対話型コマンドが動作しないのが玉に瑕
423:デフォルトの名無しさん
11/05/01 20:00:58.60
>>422
PowerShell ISEってフルで言わないとだめなのか。
PowerShell ISEでMercurialでchcp 65001が最強。
424:デフォルトの名無しさん
11/05/01 20:09:01.55
>>423
うん、同意
425:デフォルトの名無しさん
11/05/01 20:26:56.00
chcp 65001 をしたら、fopenがutf-8を受け付けるようになるの？
426:デフォルトの名無しさん
11/05/02 12:10:01.43
>>313
そのwprintfはwcstombsしてるんだろ。
まずWriteConsoleWでUTF-16のまま無変換出力を試みる
→エラーになったらコンソール以外にリダイレクトされてるから
保存用コード(ロケール使うのが正しいがオプションでUTF-8を提供してもいい)に変換して改めてWriteFile
がWindowsでの正しいUnicode対応コンソールアプリの作り方。
427:デフォルトの名無しさん
11/05/02 12:10:24.54
>>413だった
428:デフォルトの名無しさん
11/05/02 12:29:52.71
>>426
Mercurialはファイル名とファイルの中身以外は内部UTF-8なんだからwcstombsを使う理由が無い。
URLﾘﾝｸ(mercurial.selenic.com)
にある通り、fromlocal()、tolocal()、colwidth()という関数が用意されている。
429:デフォルトの名無しさん
11/05/02 12:35:44.01
>>428
すまん、アンカーミスなんだ。
元はcmd.exeでWが使える使えないの話の流れなんだ。hgの実際の実装は関係ないんだ。
430:デフォルトの名無しさん
11/05/02 12:50:32.48
>>429
バージョン管理と何の関係があるの？
431:デフォルトの名無しさん
11/05/04 12:27:28.61
PowerShell ISEは旧来のコマンドプロンプトの諸問題を解決してくれて便利
シェルとして使いにくいのが悲しい点
432:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/05/17 18:30:32.51
普通に考えたらdiff取るだけなのに毎回リモート見に行く必要があるsvnのほうが……
434:デフォルトの名無しさん
11/05/17 19:17:16.19
SVN脳と言わざるをえないｗ
435:デフォルトの名無しさん
11/05/17 19:31:10.28
そうまでリモートに集約したいなら集中型のsvn使っとけば丁度良いよ
436:デフォルトの名無しさん
11/05/17 19:38:27.23
gitスレでも指摘されてるじゃないか
集中型じゃなくて分散型の思想について勉強してこいよ
437:デフォルトの名無しさん
11/05/17 19:39:28.24
ゲソなりく～ん
438:デフォルトの名無しさん
11/05/17 20:03:09.13
>>432みたいに新しい環境に拒絶反応示して興奮してる人って、後で恥ずかしくなったりしないのかね？
439:デフォルトの名無しさん
11/05/17 20:05:44.30
全成果プリントアウト(しかもシリアルプリンタで)がいいとおもうよ☆
440:デフォルトの名無しさん
11/05/18 00:19:30.76
いや、思想とかキモイです。
全部できないのか。酷い有様だな。
441:デフォルトの名無しさん
11/05/18 00:40:23.29
>>440
ssh gesonari@kimoi /usr/bin/git --git-dir=/svn/nou diff v0.1 v0.2
442:デフォルトの名無しさん
11/05/18 01:42:52.29
>>440
bzrはできる。
443:デフォルトの名無しさん
11/05/18 02:05:27.82
もうさわんなよｗ
タダの基地外なんだから。
444:デフォルトの名無しさん
11/05/18 02:07:36.82
bzr は遅くて泣けてくる・・・
445:デフォルトの名無しさん
11/05/18 02:50:35.02
>>444
最近はそうでもないぞ。
といっても、Windows以外のユーザーが最新のbzrを使うにはソースから
インストールするかFedoraかUbuntuの最新版を使わなきゃいけないけど。
446:デフォルトの名無しさん
11/05/18 08:46:27.06
＞使っていたソフトの開発元が svn+trac からgithubに
＞変わってしまってかなり機能後退と分かりゲンナリです。
このソフトって何だろうね。
意図せずGitHubに移行しなきゃいけなくなってゲソナリってことみたいだけど、
そこまでイライラするぐらいなら古いバージョンでsvn+trac使うことは出来ないのかな？
447:デフォルトの名無しさん
11/05/18 08:50:26.59
＞酷い有様だな。
おまえの頭がな
448:デフォルトの名無しさん
11/05/18 09:23:18.91
分散型がキモかったらsvnを使い続けていれば良い。
svnがキモくてcvsを使い続けているところもある。
ｽﾚﾘﾝｸ(tech板: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:デフォルトの名無しさん
11/05/18 11:36:09.86
>>433
svnはリモート見に行く必要は無いんだが何いってんの?
450:デフォルトの名無しさん
11/05/18 11:47:33.18
>>449
それは作業領域の話。
特定のリビジョン間のdiffを見る場合、リモートを見に行く必要がある。
451:デフォルトの名無しさん
11/05/18 12:03:07.87
svnの仕組みもしらないsvnﾏﾝｾｰがﾌｧﾋﾞｮｯてると聞いて
452:デフォルトの名無しさん
11/05/18 12:22:45.76
スレがずいぶんと酷い有様だな。
453:デフォルトの名無しさん
11/05/18 17:26:11.89
ということでsvk最強
454:デフォルトの名無しさん
11/05/18 18:58:53.50
>>445
いや、最近久し振りに使ったら遅くて泣けた・・・
455:デフォルトの名無しさん
11/05/18 19:33:53.77
>>454
毎日使ってるけど、遅くて泣きたくなるのは、画像ファイルとかバイナリファイルを
たくさんリポジトリに突っ込んじゃった場合だけ。
どんな状況で遅かった？手元のバージョンが良くてもサーバー側のバージョンが
悪かったりしない？
456:デフォルトの名無しさん
11/05/18 19:35:04.65
>>455
launchpadの遅さは異常
457:デフォルトの名無しさん
11/05/18 21:00:36.69
>>456
試しにやってみたら、 bzr branch lp:mysql-server が 73771 リビジョンの
ブランチに 16m37sec かかった。
速いとは言わないけど、別に1日たっても終わらないとかじゃないし、最初の
1回だけだし、十分実用的な速度だと思う。
github や bitbucket に mysql のミラーないかな？
458:デフォルトの名無しさん
11/05/18 21:08:09.61
24時間経過しても終わらない上にエラーで失敗したりするgit cvsimportとかと比べたら
16分とか一瞬だった
459:デフォルトの名無しさん
11/05/18 21:08:55.41
無理すんなよw
460:デフォルトの名無しさん
11/05/18 21:14:56.64
>>457
Linuxカーネルは？
bitbucketじゃないところにhgのミラーはあるよ。
確かhgのポリシーにのっとって、バージョン毎にリポジトリが分かれていたから、
単純比較できないかもしれないけど。
461:デフォルトの名無しさん
11/05/18 21:16:19.31
time svn co URLﾘﾝｸ(svn.ruby-lang.org)
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:デフォルトの名無しさん
11/05/18 21:21:40.34
Emacs も酷いね。
463:デフォルトの名無しさん
11/05/18 21:27:44.57
>>461
初回はどー考えてもsvn有利だろw
464:デフォルトの名無しさん
11/05/18 21:43:00.22
てか履歴1個だけじゃ他の分散型と比べられないよなー
465:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/05/18 22:00:37.84
time の履歴が流れちゃったけど、 savannah から git で emacs を clone
したら5分弱だった。emacsの場合はgitの方が4倍くらい速いな。
とりあえず、一晩たっても終わってないとかそういうのはなさそうだから、
実用上問題にはならないだろ。
467:デフォルトの名無しさん
11/05/18 22:02:22.21
bzrはやいなぁ
hgから乗り換えるかな
468:デフォルトの名無しさん
11/05/18 22:39:21.80
bzrの遅さはpull, push, merge全部が遅いってことでしょ。
インターネット越しじゃなくて、イントラネットでも。
469:デフォルトの名無しさん
11/05/18 22:47:37.12
バージョン上がる度にbzrは早くなってるな
470:デフォルトの名無しさん
11/05/18 23:47:49.94
俺もいつかは bzr が速いって言える様になるのかな・・
471:デフォルトの名無しさん
11/05/18 23:53:10.75
bzrはhgより早いし次はsvnとgitだな
472:デフォルトの名無しさん
11/05/19 00:29:13.45
と、bzr信者は何の根拠も無く申しております
473:デフォルトの名無しさん
11/05/19 00:32:44.03
hgはオワコン
474:デフォルトの名無しさん
11/05/19 00:35:21.89
と、bzr信者は何の根拠も無く申しております
475:デフォルトの名無しさん
11/05/19 00:37:37.15
時代はgitとbzrの2強の時代へ
476:デフォルトの名無しさん
11/05/19 00:49:17.80
と、bzr信者は何の根拠も無く申しております
477:デフォルトの名無しさん
11/05/19 00:53:13.72
マジレスするとGitとhgだろうな。どっちも似てるんだけどね。
GitHub vs Google Codeか。Launchpadはいまいち人気無いよね。
478:デフォルトの名無しさん
11/05/19 00:54:05.80
gitは男の子。bzrは女の子。hgはハードゲイ。
479:デフォルトの名無しさん
11/05/19 01:05:32.02
github は本当に良く出来てるよね
必要な情報が無駄無く配置されていて使い勝手がとても良い
480:デフォルトの名無しさん
11/05/19 02:24:14.68
gitはM$捨ててるからM$で遊んでる俺の選択肢にはなり得ない
481:デフォルトの名無しさん
11/05/19 08:05:41.81
>>461
githubのruby、trunk以外のブランチも入っているじゃん
482:デフォルトの名無しさん
11/05/19 08:10:45.02
>>480
URLﾘﾝｸ(code.google.com)
URLﾘﾝｸ(repo.or.cz)
URLﾘﾝｸ(repo.or.cz)
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:デフォルトの名無しさん
11/05/19 08:17:10.66
gitもhgもutf-8に対応しているが、cmd.exe、MSysなど、MSの環境が糞なので、
まともに使えないってことだ。
484:デフォルトの名無しさん
11/05/19 11:17:07.01
>>481
うん、完全に同じ条件ではないとあとで気づいた。
だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
してはあながち的外れな比較でもないと思う。
まぁ、やりたかったことは、bzrとgitのどっちが速いかを調べることではなくて、
一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
一晩経って終わらないとかそういう事が無いことが確認できただけで満足。
本気で比較したかったらLAN上で帯域やレイテンシやパケロス率を制御した環境を
作れるはずだけど面倒なのでパス。
485:デフォルトの名無しさん
11/05/19 18:55:21.88
>>484
> 一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
> 遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
> 一晩経って終わらないとかそういう事が無いことが確認できただけで満足。
launchpadにアカウントを持っている人が一部の人では？
Emacsはlaunchpadではないけど、github・bitbucketに比べてcloneが目に見えて遅いのは
普通の感覚だと思うが。
486:デフォルトの名無しさん
11/05/19 19:06:38.32
>>484
> だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
> ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
> してはあながち的外れな比較でもないと思う。
git・hgはリポジトリに全部のブランチを入れるかブランチ毎にリポジトリを分けるか、
柔軟性があるけど、bzrはブランチ単位でしかcloneできないんじゃないの？
githubのrubyはgit-svnを叩いているから、ブランチだらけの状態だと思うけど。
487:デフォルトの名無しさん
11/05/19 19:31:26.64
launchpadは遅いというよりちょくちょく落ちてるのがなあ……
488:484
11/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:デフォルトの名無しさん
11/05/19 20:05:06.73
「一晩」が実用の判断基準っておかしくない？
git cvsimportやらgit-svnやらhgsubversionやらhg convertの最初の一回目が遅いのは当たり前。
だから、rubyのgithubみたいにミラーがあるんじゃない？
一回cloneすれば、その後のpullは差分だけど、そのpullもbzrは重いって指摘は
ぐぐればいっぱい出てくるけど？
490:デフォルトの名無しさん
11/05/19 20:55:28.09
> ぐぐればいっぱい出てくるけど？
これよそでは言うなよ恥ずかしいから
491:484
11/05/19 20:56:45.77
>>489
厳密な比較は面倒だからしないけど、きっとgitやhgよりも遅いんだろうな。
でも、俺は実用的な速度だと思ってるから使い続けてる。MySQLだって
あれだけ大きいプロジェクトで本当に使い物にならないほど遅かったら
とっくに乗り換えてるだろ。
bzrが実用にならないほど遅いという結論がでないとなにか困るの？
492:デフォルトの名無しさん
11/05/19 21:06:22.87
bzrでもsvnに比べたら御の字じゃないの？
常識で考えてGitが速すぎるんだよ。
clone中のあのいかにも速そうなインジケータとか、最初に何となくやるであろう
Linuxカーネルのcloneの速度とか、最初から狙ってると思う。
493:デフォルトの名無しさん
11/05/19 21:06:25.30
実用になる人も居れば、ならない人も居るってだけじゃないの
今使ってる人は使い続ける理由が欲しいだろうけど、今使ってなければ
別に思い入れもないし、遅いのが嫌なら bzr は選ばないでしょ
494:デフォルトの名無しさん
11/05/19 21:08:39.82
>>491
MySQLは万人がハックしてパッチを送るタイプのプロジェクトでないでしょ。
Emacsのビルドにbzrに接続することを要求されて、それで、bzrの重さの認識が一気に浸透したと思うけど。
cvs、svnもゼロから始めるソースはそんなに重くないけど、
だんだん重くなるよね。
bzr信者は感覚が麻痺しているんじゃないの？
cvsがデファクトスタンダードでsvnがそれに置き換わるかと思われたけど、
svn離れが加速しているよね？
遅いものは主流になり得ないというのは歴史が証明していると思うけど。
495:484
11/05/19 21:28:36.76
信者呼ばわりか。まぁ否定はしないけど。
別に bzr が今後も主流になりえないかもしれないけど、Canonicalが潰れる
までは衰退することもないし、その時に考えるからいいよ。
俺は単に使い物にならないほど遅いとdisられがちだから本当にそんなに
遅いのか実験してみて、俺に取っては許容範囲だと判断しただけ。
Emacsの件はいろいろ不幸だった。savannahのサーバーのセットアップが
悪かったり、タイミング的に bzr 2.1 以前を使ってるユーザーがまだ
多かったり (lennyのデフォルトのbzrなんて1.5とかいう使い物にならない古さ)
したからな。
496:デフォルトの名無しさん
11/05/19 21:58:52.05
> cvs、svnもゼロから始めるソースはそんなに重くないけど、
> だんだん重くなるよね。
svn の場合、ファイルシステム(リポジトリのフォーマットのこと)によって違うよね。
以前の bdb の場合はリビジョンが増えてもチェックアウトは速かったけど、
今のデフォの fsfs の場合はリビジョンが増えるとチェックアウトが遅くなる。
その半面、 fsfs ではホットコピーが簡単になり、壊れなくなったけど。
497:デフォルトの名無しさん
11/05/19 22:46:24.95
信者認定プログラム：OS エディタ プログラミング言語 これにVCSが仲間入りか。
他にもキーボード配列とか文字エンコーディングとかあるけどね。
498:デフォルトの名無しさん
11/05/19 22:48:09.06
Emacsはbzrの重さの認識が万人に浸透するほどハックされてるのか
Lisperの一人として胸厚だわ
499:デフォルトの名無しさん
11/05/19 23:22:30.26
友情は厚い、ですが胸は熱い、じゃないでしょうか？
500:デフォルトの名無しさん
11/05/19 23:23:19.53
鍛えてるんだろ
501:デフォルトの名無しさん
11/05/20 02:31:50.69
git>>>>bzr>>>>>>>>>>>>>>>>hg
今はこんな感じか。
hgの一時の勢いはどこへやら。
502:デフォルトの名無しさん
11/05/20 10:02:32.19
windowsオンリーの環境で分散型を取り入れる時、
git、hg、bzrからhgを選んで導入も終えてそこそこ使えるようになってきたのに、
だれだよオワコンとか言うのは！
503:484
11/05/20 10:23:37.27
>>502
hg いいと思うよ。そのうちWindowsでちゃんとUnicode API使えるようになりそうな気配だし。
504:デフォルトの名無しさん
11/05/20 10:26:12.38
>>501
2chのスレの勢いだとそうかもね。
hgの場合、日本語で語れる場所が他にもあるから。
そこで取り上げられていた、このスレに絶好のネタが2chでは取り上げられていないし、
住み分けができてるんじゃない？
505:504
11/05/20 10:27:50.43
おっと、>>503に例のネタ、先を越された
506:デフォルトの名無しさん
11/05/22 15:25:09.20
>>483
それもひっくるめてgitが糞という評価になるんだが。
507:デフォルトの名無しさん
11/05/22 15:34:57.36
MS 製品を使ってない俺には何が問題かさっぱり
508:デフォルトの名無しさん
11/05/22 15:36:55.32
なんども書いてるがcmd.exeっていうかWindowsのコマンドプロンプトでもUnicodeは使えるぞ。
UTF-8ではなくUTF-16になるから、#ifdefが必要になるだけで。
509:デフォルトの名無しさん
11/05/22 15:54:48.60
MS製品に依存してる連中がオレ様野郎ばっかというのがよく分かる。
Linux使ってる人が「VSSはLinuxで使えないから糞」なんて言わないからな。
別の意味では言ってるかも知れないが。
510:デフォルトの名無しさん
11/05/22 20:06:41.36
>>506 >>508
svnのmac portsのような対応をgitに望んでいるのか？
511:デフォルトの名無しさん
11/05/22 22:17:58.55
TortoiseCVSもTortoiseSVNも1つ落としてきてインスコするだけで使えるんだが
TortoiseGIT(笑)はそうじゃないんだよな
それを導入することによりよっぽど捗るとか利点がない限り
そんなまんどくせーものわざわざ手間かけてまでつかわねえよ
512:デフォルトの名無しさん
11/05/22 22:34:06.03
>>511
CVSとSVNのパフォーマンスとマージに満足なのですね？
CVSとSVNのマージはまんどくさくないのですね？
513:デフォルトの名無しさん
11/05/22 22:36:49.97
>>509
VSSがいいといっても見向きもしないでしょ、その人達は
文句を言うときは実装と一緒
gitがいいという話を聞いてうっかり使ってしまい文句のみを垂れ流す、それがWindowsユーザー
と、こんな風なレスを期待しているのか？
不毛じゃね？
514:デフォルトの名無しさん
11/05/22 22:46:18.29
>>513
> VSSがいいといっても見向きもしないでしょ、その人達は
VSSが糞なのは周知
515:デフォルトの名無しさん
11/05/23 02:37:25.78
>>512
自分の使わない機能がいくら速かろうが関係ないの
おわかり?
516:デフォルトの名無しさん
11/05/23 03:47:00.34
マージ使わないならrsyncとかtarballとかでいいんでは……
517:デフォルトの名無しさん
11/05/23 07:24:45.37
>>515
TortoiseCVS(笑) TortoiseSVN(笑)
518:デフォルトの名無しさん
11/05/23 11:12:04.02
>>515
使わないんじゃなくて使い方がわからないんだろ
おわかり?
519:デフォルトの名無しさん
11/05/23 15:38:59.33
>>518
520:デフォルトの名無しさん
11/05/23 16:34:02.13
>>515
521:デフォルトの名無しさん
11/05/23 18:52:26.43
>>515
522:デフォルトの名無しさん
11/05/23 19:42:43.91
きょうも元気だごはんがうまい
おかわり?
523:デフォルトの名無しさん
11/05/23 19:46:03.61
一人で開発する時は dropbox のフォルダに cp -R してるわ
524:デフォルトの名無しさん
11/05/23 23:22:47.09
dropboxとかねーわ
525:デフォルトの名無しさん
11/05/23 23:33:47.28
>>524
もっと良い奴あるの?
526:デフォルトの名無しさん
11/05/24 02:08:17.45
>>517
？
527:デフォルトの名無しさん
11/05/25 00:03:05.80
>>525
SugarSync
528:デフォルトの名無しさん
11/05/25 00:15:54.04
>>527
どこら辺がいいの?
529:デフォルトの名無しさん
11/05/25 13:11:25.38
SugarSyncとDropboxは良く比較されるしググればすぐ分かるぞ・・・・
530:デフォルトの名無しさん
11/05/25 19:27:34.81
いや、もちろん違いは知ってるんだけど、SugarSync のメリットがよく分からん
531:デフォルトの名無しさん
11/06/24 22:06:52.17
Github for Mac
URLﾘﾝｸ(github.com)
532:デフォルトの名無しさん
11/07/16 22:33:02.35
code.google.com でも git が使える様になったらしいね
URLﾘﾝｸ(code.google.com)
533:デフォルトの名無しさん
11/07/17 06:34:06.08
>>532
URLﾘﾝｸ(code.google.com)
> 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:デフォルトの名無しさん
11/07/17 06:35:50.30
github、bitbucket優位の状況は変わらないだろう
535:デフォルトの名無しさん
11/07/25 19:55:07.99
Windows上にあるエロ画像とかエロ動画とか日記とかが雑多に保存してあるホームディレクトリを
まるっとバージョン管理するには何使ったらいいの
536:デフォルトの名無しさん
11/07/25 20:10:57.22
dropBox
537:デフォルトの名無しさん
11/07/25 20:23:18.86
テキストとそれ以外はバージョン管理のシステムを分けたほうが良い？
538:デフォルトの名無しさん
11/07/25 20:35:40.84
>>536
え？dropboxってバージョン管理できたの？別スレで
URLﾘﾝｸ(d.hatena.ne.jp)
見て阿呆かと思ったけど意味があったのか…
>>537
同期して管理する必要が無いんだったら分けた方が良い、かも。
無関係なもの一緒くたにすると重くなりがちなので。
539:デフォルトの名無しさん
11/07/25 20:37:19.91
>>532
サーバのオプションどうなってるんだろうね。
sf.jpはrebaseできないの知らなくてすげー困ったんだけど。
540:デフォルトの名無しさん
11/07/25 20:45:00.76
>>538
俺もソースツリーのバックアップを dropbox に置いてるけど、何か問題あるのか?
バージョン管理は別途ツールを使ってるよ
541:デフォルトの名無しさん
11/07/25 20:51:32.69
>>540
>>538はバックアップじゃねーぞ
542:デフォルトの名無しさん
11/07/25 20:59:01.78
>>541
dropbox のディレクトリは単なるローカルのディレクトリでしょ
ビルドしてオブジェクトファイルが更新されたらバックグラウンドで
アップロードが走るのが嫌とか、そういう話?
543:デフォルトの名無しさん
11/07/25 21:15:46.51
元質問エロ画像やエロ動画や日記のバージョン管理を求めている。
544:538
11/07/25 21:44:02.08
>>540-542
ごめん俺drop boxのこと全く知らないし興味もないしスレ違いなので忘れて。
545:デフォルトの名無しさん
11/07/25 21:50:02.80
最良のバックアップは配布だ。トモダチにコピーして回る。
で、どんな得ろ画像だ? JSと熟女と太めは歓迎なので俺とトモダチになれ。
546:前スレ989
11/07/25 22:03:47.45
この板的にはJSと言えばJavaScriptだな。
547:デフォルトの名無しさん
11/07/26 00:04:51.49
dropboxならファイル単位で履歴管理できるしシェアもできる。
ソースの管理には向かないが、画像の管理にはそこそこ便利。
で、ソースのバックアップをdropboxに置くくらいなら、リポジトリを置いてしまうのも手。
548:デフォルトの名無しさん
11/08/19 23:24:45.47
gitで複数のブランチそれぞれに個別の未コミットのファイルを残したまま
ブランチを渡り歩くことってできる？
イメージとしてはbazaarで複数ブランチを同時にいじってて放置したまま
ブランチ間をcdで移動するみたいな。
diffとかはファイルとしての実体は不要でいいんだけど
gitは未コミット分をかかえたままになるのがちょっと困ってる。
いちいちstashとか嘘commitとかするのは
その判別含めて自動化できないと面倒で…。
549:デフォルトの名無しさん
11/08/19 23:28:19.52
MercurialならShelveがあるのにな
550:548
11/08/19 23:40:47.88
少し調べてみたけれど、
Mercurial の Shelve って git の stash と完全に同等に見えるけれど、そうでもないの？
551:デフォルトの名無しさん
11/08/19 23:45:29.57
TortoiseHgにあったShelve Changesは
ファイルごとに退避ができてstashより便利だなーって思った覚えが。
552:デフォルトの名無しさん
11/08/19 23:50:55.94
>>548
ブランチの数だけcloneしたら？
553:548
11/08/19 23:57:29.95
>>552
自分も一旦はそう考えたんだけど、それだと結局bazaarと同じ運用になって、共有リポジトリ使えない分だけ損してるような…。
ツリーは1つ、というのが気に入ってbazaarからgitに移行しようかと試してるんだけど
標準ではサポートされない（というか人気のない？）使い方なのかな。
554:548
11/08/20 02:26:16.94
濱野さんの本にはこう書いてある。
あとから追いやすくなるのでコミットは意味ごとに独立させるべき、
意味（意図）が同じコミットはあとからまとめるのもよい、
ローカルリポジトリは意味ごとにrebaseなどで改竄もむしろ推奨。
ということは、ブランチも意味ごとに直交させて切るべきだと思うんだけど
そーするとなぜ未コミット分がブランチをまたいで受け継がれるんだろう。
ブランチをまたぐ際にstashとか破棄前提の嘘commitが必要ってのは
単に実装が思想に（まだ）合致できてないってことなんだろうか。
日常的に使ってるとブランチは常に2～3個必要になるし、
瞬間的には 4個とかにもなるんだけど、みんな困ってないのかな。
555:デフォルトの名無しさん
11/08/20 04:18:26.06
Shelve Changesも実は嘘コミットだと思えば気分が楽になるんじゃね？
いやShelve Changesがどんなものか知らんけど。
556:デフォルトの名無しさん
11/08/24 15:54:04.86
>>535
NILFS
557:デフォルトの名無しさん
11/08/24 21:49:54.87
たくさんのリポジトリを一気にPull(Fetch)できるGUIのツールって無いかな
GitやHgのリポジトリ一つずつ更新していくの面倒
いや、サブディレクトリにあるリポジトリでfetchをする
スクリプト書けばいいのかもしれないけれども、GUIの方が良いし
558:デフォルトの名無しさん
11/08/25 01:08:57.32
>>557
俺はそんなのシェル一行ですませるけど、GUIのツールがほしいなら作れよ
559:デフォルトの名無しさん
11/08/25 15:02:17.64
GUIのツールで一気に何かするのって俺は怖くてやだ
560:デフォルトの名無しさん
11/08/26 11:34:02.44
復帰
561:デフォルトの名無しさん
11/08/27 19:55:47.01
Bazaar日本語ファイル名の問題がないらしいので手を出してみたが
GUIの既定値が自分の使い方とあっていなかった。
コマンド入力で補助しないと行けない。
Mercurialは自分と合っていそう。
rebase, transplant, splitを使って少しだけ内容の違うブランチを
双方で変更する場合に対応できる。
今までsubversionでリビジョンの範囲をマージする方法でやってきたが
履歴改変にはまりそうだ。
562:デフォルトの名無しさん
11/08/30 18:05:51.79
会社で開発メンバーが増える事になり、バージョン管理システムを使えとのお達しがでた。
条件は以下の通り
・NASでソースは管理する。（購入済み）
・サーバーレスで動くもの
調べた感じでSubVersionしか無いんじゃないかと思ったんだけど、他におすすめありますか？
上の条件に合致すれば 分散だろうが集中だろうが関係無いらしい。
563:デフォルトの名無しさん
11/08/30 18:14:12.96
いやどれでもファイルベースのリボジトリ操作はできるだろうけど、
いろいろ無茶じゃないか……？
そのNASで複数の接続先から同時に同じファイルに排他ロックをかけようとして
ちゃんと動くか程度は確認したほうがいい。
ネットワークファイルシステム越しのロックがかからないようなら
サーバー建てるなり個人リポジトリとマージ用を分けるなり考えたほうがいい。
564:デフォルトの名無しさん
11/08/30 18:17:49.45
NASじゃ無理だろ
誰かのマシンでサーバを動かしてリポジトリはNASに置けばいい
565:デフォルトの名無しさん
11/08/30 18:26:32.70
同時書き込みしたらファイル壊れるな
566:デフォルトの名無しさん
11/08/30 18:33:06.19
いや、それこそsvnならファイルベースアクセスであってもロックファイルを作るぐらいのことはしてる。
だから一台のマシン上で複数プロセスから同時にコミットしても壊れない。
問題はネットワーク越しにそれをやると、ロックファイルを作ったつもりになって相手への反映が遅れるとか
NFSの制限でロック取れなくてもエラーが帰ってこないとか、なんか起きそうなことだ。
567:デフォルトの名無しさん
11/08/30 21:38:17.30
個人毎にリポジトリをもって、マスターのリポジトリへの反映は申請制とか
568:デフォルトの名無しさん
11/08/30 22:00:58.98
確かVSSはサーバーレスで動いたような……
569:デフォルトの名無しさん
11/08/30 22:33:14.62
分散型なら置くだけだからファイルコピーができる状況ならファイル置ける
570:デフォルトの名無しさん
11/08/30 23:54:03.63
>>562
SCMが全くわかってないなぁ、お前んとこの上司わ。
多分その上司は、そのNASがエクスプローラのWindowsネットワークに見えてないと
怒り出すんだろうな、きっと。
571:デフォルトの名無しさん
11/08/30 23:58:32.02
ちなみに、オレんとこの会社では牛NASを殻割りしてdebian突っ込んで、
そこでapache+subversionを動かしてるから、
・NASでソースは管理する。（購入済み）
という条件は満たしてるし、ソースの管理に必要なのはそのNASだけだから
・サーバーレスで動くもの
という条件も確かに満たしてはいる。
しかし当たり前のことだが、エクスプローラでは見えない。
つか、わかってないやつには見えないように設置する。これ、重要じゃね?
572:デフォルトの名無しさん
11/08/31 01:28:58.70
562の条件だとエクスプローラで見えなくても良さそうだが、
リポジトリを直接覗いて何が入ってるかわからん！なんて言われるレベルだとどうしようもないな
573:デフォルトの名無しさん
11/08/31 09:45:03.18
何も考えず独りよがりの思い込みでNASを買ってくる時点で、
どうしようもないレベルという条件は既に満たしてしまっている気がするが...。
574:562
11/09/01 17:08:25.56
みんなレスサンクス。
SCMについては俺もしっかり理解できてなくて勉強しながらやってるから勘弁してくれ
NASへのファイルの同時書き込みとかの問題は言ったんだけど
「今時のNASでそんなのあるわけないだろ、自宅で使ってるがそんな事起きたことが無い」
とか言われてナシのつぶてだった ('A｀)
んで、別のサーバ動かしてリポジトリをNASに置く件については
「サーバーとNASが同時稼動前提とか何考えてるんだ」らしい。
575:562
11/09/01 17:15:34.40
>>570
エクスプローラで見えてないとキチンと運用されているか俺がわからんとか言うタイプ
>>571
NAS(LS-WVL) を殻割りしてサーバー入れる手を考えてたんだけど、
「保証受けれなくなるし、もう半分ぐらい移行したから無理」とか言われるし
576:562
11/09/01 17:17:03.76
>>568
VSSは使いにくいって上司がいってｒ
>>569
分散型ってマスターの場所にサーバー入れて管理みたいな図を見たんだけど必要無い？
必要無いなら保存先がNASってだけでいけそうかなぁと
もう文句言いまくるくせに自分では絶対しない人なんで
ﾏﾝﾄﾞｸｾ('A｀) ｳﾞｧｰ
577:デフォルトの名無しさん
11/09/01 17:34:23.24
まあ、やってみなよ。リポジトリが壊れても知らんけど
いざとなったら日付フォルダで…
578:デフォルトの名無しさん
11/09/01 17:57:08.96
>>574
自宅用途でそもそも同時書き込みが発生するかよ。
本当にファイルに排他制御がかかるかテストさせてくれないのであれば
個人リポジトリを分けて、マージ担当を置いたほうがいいな。
579:デフォルトの名無しさん
11/09/01 18:22:06.68
>>576
保存先がNFSならいけたんだが、単なるNASだと無理。
あきらめろ。
580:デフォルトの名無しさん
11/09/01 18:26:56.25
どんなたいそうなNAS導入したのかと思ってググったら、それ15,000円位のゴミじゃん
業務でそんなの使うの？
サーバアプリ動かせるちゃんとしたの導入すれば？
581:デフォルトの名無しさん
11/09/01 20:18:22.50
まあ分散型なら自分とこのリポジトリが生き残っている可能性があるか…
582:デフォルトの名無しさん
11/09/01 20:26:10.00
分散型にして、そのNASは無いものと考える。
583:デフォルトの名無しさん
11/09/02 02:05:35.26
たしかにGitでロック競合しておかしくなったとしても
なんとかなっちゃいそうだよな
584:デフォルトの名無しさん
11/09/02 05:57:20.39
ダメ上司もつと大変だな
声かけしてコミットしなよ
585:デフォルトの名無しさん
11/09/02 06:51:53.18
確かにGitやMercurialならpushの前に声掛ければいいな
586:デフォルトの名無しさん
11/09/02 08:30:15.16
その上司の下じゃ何使っても駄目なんじゃ
587:デフォルトの名無しさん
11/09/02 08:37:09.09
分散型とか理解出来なさそうだ
588:デフォルトの名無しさん
11/09/02 08:52:00.66
今まで鯖も立てずによく業務がこなせたなとある意味感心する
589:デフォルトの名無しさん
11/09/02 20:20:34.83
QNAP TurboNAS の CPUがそこそこ上位の奴 (Mervell ARM じゃなくて、Intel ATOMの) なら、
Subversion が動くようだ。(ipkg で導入できるっぽい)
URLﾘﾝｸ(www.google.co.jp)
Mercurial, Git, Bazaar, TFS については知らん。
Python と gcc と mod_wsgi が用意されているようなので、Mercurial は動きそうな気もする。
URLﾘﾝｸ(www.google.co.jp)
590:589
11/09/02 20:26:47.83
訂正。Subversion は一番安いの (TS-112 \20,000未満) でも用意されてる。
591:デフォルトの名無しさん
11/09/02 22:28:53.51
>>589 *nix系NASならbootする途中でのっとっちまえばなんでもありじゃん
gccのクロスコンパイラなんて簡単にできるんだしw
592:デフォルトの名無しさん
11/09/04 21:57:37.98
>>587
そんなときこそ Bazaar ですよ。
分散型が理解できないアホには集中型として、理解できる人には分散型として使える。
593:デフォルトの名無しさん
11/09/04 22:10:42.07
>>562
うちは Bazaar で共有リポジトリを共有フォルダ上において
push/pull あるいはmergeしてるから、NASを使っているのと
ほぼ同じ構成だな。
594:562
11/09/05 13:51:32.54
>>592
のやり方が一番幸せになれるんじゃないかと思った。
まだ自分がバージョン管理システムについて勉強中なんで
具体的な実現方法は見えてないんだけど、基礎的なものを勉強できる資料でおすすめって何かある？
リポジトリとかブランチとかさっぱりな初心者でも分かる資料・・・ orz
595:562
11/09/05 13:54:16.56
>>588
今までは自分が全部のソース管理をしてたんだよね。
でも今年の中頃から打ち合わせだとかで不在が多くなって
例の上司が「俺がソース管理をしてやろう」ってなってからデグレが８回。
全部自分が対応してなんとか復旧 orz
596:デフォルトの名無しさん
11/09/05 14:26:55.34
>>594
書籍・ドキュメント・実績豊富なGit・Mercurialを素直に使いましょう
まず近場の本屋に行きましょう
Bazaarが選択肢に入らないことは明かです
597:デフォルトの名無しさん
11/09/05 15:17:27.87
ClientのOSを聞かずに何かをお勧めしちゃうの？
598:562
11/09/05 15:21:47.38
Clientは Windows XP以上のOS全般です。(32bit、64bit混合)
599:デフォルトの名無しさん
11/09/05 15:59:53.41
>>595
>今までは自分が全部のソース管理をしてたんだよね。
どうやってたのよ？
で、上司が管理したらなぜデグるのか、原因はわかってる？
バージョン管理システムは管理を楽にしてくれるし、 変なことできにくくしたり、
変なことしても復旧が容易だったりするけど、それでも変なソースをコミットして
混乱に陥るってことが皆無というわけじゃないよ。
600:デフォルトの名無しさん
11/09/05 17:44:12.82
分散型を選んで統合マネージャー型のワークフローで運用すればいいんじゃね
URLﾘﾝｸ(progit.org)
どう運用するかが肝でどのツールを選ぶかはたいした問題じゃないと思う
601:デフォルトの名無しさん
11/09/05 17:56:40.55
なぁ、将来にわたって考えると数人月以上もコストがかかるやり方をやり始めるより、
5～20万出して(まともなサーバ or プログラムが実行できるNAS)(+UPS)を買った方が断然良くないか
602:デフォルトの名無しさん
11/09/05 18:18:38.93
それだったら問題の上司を飛ばすのが一番だよw
603:562
11/09/05 19:02:18.38
>>599
今まではPG一覧の資料作って、修正する際は申請してもらって修正中フォルダへ移動
PG一覧へ修正者の記載。
修正が終わった段階で修正中フォルダからメインフォルダへ移動→PG一覧に更新日を修正状況を更新
上司がデグらせたのはこの辺の管理を全くせずに勝手にフォルダ移動OKにしたところ。
あとPG一覧も修正せずにいたからこうなった感じ
604:デフォルトの名無しさん
11/09/05 20:05:34.11
>>603
その運用がちゃんとできているなら、ツール入れればだいぶ省力化できると思う。
その上司じゃどうしようもないから、早めに管理システム入れたほうがいい。
605:デフォルトの名無しさん
11/09/05 20:11:31.83
>>603
Tracとかredmineを検討したほうがいいんじゃない？鯖いるけどｗ
606:デフォルトの名無しさん
11/09/05 23:17:15.66
鯖立ち上げまで一発でインストールしてくれる
そんな夢のようなツールないですかね
607:デフォルトの名無しさん
11/09/05 23:55:40.10
>>603
うげぇ。そのPG一覧はExcelってオチか。
それはマズイ。
608:デフォルトの名無しさん
11/09/06 11:04:59.10
そのレベルだと VCS 入れたら入れたで問題起きそうだねえ
609:デフォルトの名無しさん
11/09/06 12:10:54.34
各モジュールに担当が決まっているような職場で、オプソ界隈のVCSがどれくらい効果的に使えるかねぇ?
…とか茶々入れてもしょうがないな。DVCSにして、マネージャ級だけがプッシュできるリポジトリを作るに一票。
>>600
610:デフォルトの名無しさん
11/09/06 17:12:20.61
画像ファイルをリポジトリに入れてるんだけど、色を変えただけでファイルサイズが同じだと
変更を認識してくれなくて酷い目にあった。
試してみたら
bzr : NG
git : NG
hg : OK
svn : OK
って感じだった。
これって常識？
611:デフォルトの名無しさん
11/09/06 17:13:31.88
バナリはなあ、、、
タイムスタンプ見るかどうか？
612:デフォルトの名無しさん
11/09/06 17:38:44.83
mjd?
ありえんなあ。
613:デフォルトの名無しさん
11/09/06 18:04:07.75
>610
VCSによっては、タイムスタンプもサイズも同じなら中身まではチェックしないってのはある。
タイムスタンプが変わってるのにサイズが同じってだけで変更無し扱いになるってのはちょっと考えにくい。
614:562
11/09/06 18:10:44.18
>>604
上司がやってなかったところがシステム化されるので大丈夫かなと思います。
>>605
まだどのバージョン管理システムを使うか検討段階なんで
どういうものがあるかも含めて教えてもらえると助かります。
鯖は無しでいいやつがいいです・・・・orz
615:デフォルトの名無しさん
11/09/06 19:30:58.94
>>614
各ホストファイル共有ベースでやってるならなおのことDVCSがいいね。
616:デフォルトの名無しさん
11/09/07 00:08:14.87
>>614
聞いてる感じだとMercurialが無難そう。GUIクライアントもこなれてるし。
日本語ファイル名をつかうなら、個人的にはBazaarを推したいけど。
とりあえず、HgInitでぐぐって出てきたページを読んでみるといいよ。
オリジナルは英文だけど和訳もあるはず。
617:デフォルトの名無しさん
11/09/07 00:32:56.06
>>610
＞git : NG
これは信じ難いなぁ
618:デフォルトの名無しさん
11/09/07 11:29:43.76
>>610
同じサイズのバイナリファイルということで
dd if=/dev/urandom of=file count=1
で試してみたけど再現しないな。何かやり方を間違っているだけでは。
619:デフォルトの名無しさん
11/09/07 12:15:08.63
ある程度以上の大きさのファイルは index に含まれなく、ファイル全体比較もしないんじゃないかな?
(一部だけ比較してるとか)
620:デフォルトの名無しさん
11/09/07 13:46:36.72
>>610
gitとbzrとsvnで確認してみた。
同サイズでタイムスタンプが同じだと、確かにgitとbzrはNGだった。svnはOK。
同サイズでタイムスタンプが異なるとgit、bzr、svnの全部がOKだった。
621:デフォルトの名無しさん
11/09/07 13:50:30.82
え、タイムスタンプが関係してくるSCMって大丈夫か？
622:デフォルトの名無しさん
11/09/07 13:55:41.41
バイナリーは特別扱いだろ
623:デフォルトの名無しさん
11/09/07 16:18:44.38
>>622
それは、バイナリファイルの場合は特別にタイムスタンプによって何か処理するということ？
624:デフォルトの名無しさん
11/09/07 16:37:24.24
まずバイナリの定義を述べてもらおうか
625:デフォルトの名無しさん
11/09/07 16:47:33.27
>>624
そのVCSでテキストレベルのdiffが取れないのがバイナリの定義じゃね？
626:デフォルトの名無しさん
11/09/07 16:52:46.13
>>624
gitとかsvnはバイナリファイルかどうかを判断してんだけど、知らないの？
627:デフォルトの名無しさん
11/09/07 17:29:05.52
>>624
mercurialだとNULバイト(0x00)が存在するものをバイナリファイルとして扱っているよ
628:デフォルトの名無しさん
11/09/07 17:30:24.65
gitのこと全然知らないんだけど、軽くググったところによると、「同サイズで同じexifを持ってれば同じとみなす」
とかいうことかも。
ファイルそのものの属性としてのタイムスタンプを見てるとは信じがたい。
629:デフォルトの名無しさん
11/09/07 17:35:55.51
気になるならテキストモードでやればいいだけ
それが専用プラグインなんかを突っ込む(Excelなんかはそうやるだろ？)
この手の質疑応答は10年ぐらいから嫌という程みてきたわｗ
630:629
11/09/07 17:40:21.02
×この手の質疑応答は10年ぐらいから嫌という程みてきたわｗ
○この手の質疑応答は10年以上前から嫌という程みてきたわｗ
要は該当するファイル群に対して強制的にハッシュを取るようにすればいいだけの事
631:620
11/09/07 17:45:28.75
gitとbzrとsvnで確認したのはWindows7上でした。
テキスト・バイナリ同じ結果となりました。
Linuxでは、ctimeを任意に変更することができなかったので
同じタイムスタンプのデータは作成できませんでした。
gitでは、chmod(ctime更新)したらそのテキストはmodifiedに
なりadd&commitできましたので、ctimeで判断しているように思えます。
632:デフォルトの名無しさん
11/09/07 17:48:52.87
>>630
何いってんの
633:デフォルトの名無しさん
11/09/07 18:03:41.17
バイナリだろうがテキストだろうがハッシュはとるでしょ。
ファイルサイズの大小ならともかく、テキストかバイナリかでその辺の挙動を変える意味はないし。
毎回全ファイルのハッシュ計算するわけにもいかないし、タイムスタンプとサイズが一致してたらとりあえず
未変更とみなすっていうのはそれなりに妥当な落としどころだと思う。
634:デフォルトの名無しさん
11/09/07 18:09:47.26
ひとりだけ勘違いくんが居るよ
635:デフォルトの名無しさん
11/09/07 18:17:45.90
とりあえず差分は無理だからな。丸ごと保存することになる場合が多い
636:デフォルトの名無しさん
11/09/07 18:17:49.92
>>633
何いってんの
どのSCMのコード見ての発言なの
637:デフォルトの名無しさん
11/09/07 18:21:51.64
ネットワーク越しのクライアント使う場合も、ローカルファイルのメタデータ送ってるって事か？
638:デフォルトの名無しさん
11/09/07 18:23:46.11
>>633
毎回全ファイルのタイムスタンプとサイズをやりとりするの？
639:デフォルトの名無しさん
11/09/07 18:26:01.40
>>635
svnは内部的にはバイナリファイルも差分で持ってるぜ
640:デフォルトの名無しさん
11/09/07 18:34:11.97
これマジか
gitとbzrは怖くて使えんわ
641:デフォルトの名無しさん
11/09/07 18:49:21.28
>>633
取らない物が殆ど
仕様をちゃんと読め
642:デフォルトの名無しさん
11/09/07 18:52:36.71
タイムスタンプがどうとか言ってる奴はバージョン管理を何だと思ってるの？ｗ
643:デフォルトの名無しさん
11/09/07 19:03:14.53
画像なんかのバイナリをバージョン管理に含める人がまだいるんだなぁ。
こういう人達はDBに沢山の画像をつっこむ以上に愚かだわ。
644:デフォルトの名無しさん
11/09/07 19:04:40.83
github の画像差分とか見てみろ
古い常識に囚われてはいかん
645:デフォルトの名無しさん
11/09/07 19:09:17.24
古い常識つーか今も常識でしょ。
リポが肥大して後で消そうにも消せない問題は未だ健在(出来る物も有るけどね)。
そんな拡張によるニッチな要求を満たした例を上げて「今はバイナリも突っ込むのが常識」なんて言われても説得力がないわい。
646:デフォルトの名無しさん
11/09/07 19:46:50.49
ゲームなんかだとバイナリ突っ込むけどなあ。
647:デフォルトの名無しさん
11/09/07 19:49:21.44
自分の常識があらゆる場合において普遍と思ってる奴は結構多いからな
648:デフォルトの名無しさん
11/09/07 19:52:05.38
ゲーム開発でバージョン管理にバイナリ突っ込む？えっ？
定期的にスナップショットをとるだけだろ…
あぁ同人か…
649:デフォルトの名無しさん
11/09/07 19:57:00.50
やっと10年前のレベルに追いついてる土方が沸いたか
650:633
11/09/07 20:01:27.36
>>641
マジで？これは恥ずかしい。
でもGitとBazaarはハッシュ取ってるよね？
>>642
そうは言っても、>>620 に書いてないMercurialも含めて、そういう挙動をしてるからなあ。
ちなみにタイムスタンプって言ってるのは、最後にコミットした時点のタイムスタンプじゃなくて、
ローカルで最初に変更チェックした時のタイムスタンプね。
BazaarとMercurialについては、一回ファイルの変更チェックしたら、サイズかタイムスタンプが変わらない限り再チェックされないようになってるように見える。
Gitは今手元にないから分からん。
651:デフォルトの名無しさん
11/09/07 20:08:37.60
見えるとかわからんとか言うぐらいなら一々レスするなって・・・・
652:620
11/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:デフォルトの名無しさん
11/09/07 20:27:04.66
要件上、画像の編集履歴を取りたい＋過去版を参照・取得したい
というのが必須なら、やはりVCSに突っ込むのがベターな選択だと思うよ。
ただその場合は、プログラムコードの管理をメインに開発されたVCSよりは、
Adobe Version Cueのような画像・映像データのアセット管理をメインに据えた
製品を選定するのが良いと思う。……というかそれは板違いの話になるな。
ちなみにウチは帳票定義用のバイナリーファイルをSVNに突っ込んでる。
Excelとか、Wordとか、PDFとか。
654:デフォルトの名無しさん
11/09/07 21:22:09.87
バイナリを入れないってのは、機械生成できる実行形式みたいな
のを入れないっていう意味だろ女子高生
655:デフォルトの名無しさん
11/09/07 21:31:19.43
>>648
画像データの内容とプログラムの仕様が一致していないとマズいから、
コードとデータを一緒くたにSubversionで管理してるよ。
以前までコードとデータを別々に管理してたけど、
コードだけ更新してデータを更新しないとか、逆のこととかが頻発するんだよね。
特に納期直前にそんな事あったら目も当てられん。
656:デフォルトの名無しさん
11/09/07 21:48:56.84
>>655
ディレクトリ、ファイル単位で別々のリビジョンをチェックアウトできるSubversionでは、
その要件は満たさない
657:デフォルトの名無しさん
11/09/08 00:24:05.54
>>656
そうなのかな。よく理解できてないけど。
658:デフォルトの名無しさん
11/09/08 00:38:53.93
タグくらいつけるだろ
管理できる
659:デフォルトの名無しさん
11/09/08 11:28:05.50
>>655
うむ。一番楽だ。重いけどな。
>>656
わかりやすく説明してちょ。
660:デフォルトの名無しさん
11/09/08 12:45:06.80
わざと一部だけ違うバージョンのファイルを混ぜてバージョンが一致してないとか言い出す揚げ足取り
661:デフォルトの名無しさん
11/09/08 14:01:54.84
>>629
> この手の質疑応答は10年ぐらいから嫌という程みてきたわ
そうなの？何か別の物と勘違いしてない？
今回の問題は「（フォーマット不明の）画像ファイルをSCMで扱うとき、ファイルの日付と
サイズが同じ場合、内容が異なっていてもSCMによっては同一のものと認識する」だよ？
GitやMercurialのFAQに書いてたりするのかな？
662:デフォルトの名無しさん
11/09/08 14:06:41.17
>>652
bzrで--unchangedつけてもダメ？
663:デフォルトの名無しさん
11/09/08 14:40:48.36
少なくともgitはファイルスタンプなんて見てない
画像はexifを見てるんだろうが、気に入らなきゃ自分で設定出来る
664:デフォルトの名無しさん
11/09/08 15:36:12.91
てか、プログラムで扱う画像ファイルにはexifなんか無いのが多いのでは？
665:620
11/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:デフォルトの名無しさん
11/09/08 17:03:17.59
>>665
gitの場合、.gitattributes ファイルに
*.foo binary
と書いとけば、拡張子.fooファイルはバイナリだと扱われる
これで試すとどうなる？
667:デフォルトの名無しさん
11/09/08 17:42:49.51
>>620
OKってどういうこと？
svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
「変更なし」になるんだけど。
変更を検知できないんならNGじゃね？
>>631
gitはパーミッションも管理対象だからじゃね？
668:デフォルトの名無しさん
11/09/08 17:53:14.49
>>667
> svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
> 「変更なし」になるんだけど。
まじか
svn使えねー
669:デフォルトの名無しさん
11/09/08 18:17:29.09
GitについてLinux(Debian Lanny)とMac OS X(10.6)で確認したら
サイズとctimeが同じでも、中身が違えば変更検知されたのだが
670:デフォルトの名無しさん
11/09/08 18:28:23.18
中身を見るなんて無駄な処理は要らない
タイムスタンプを変えないなんてわざとそうているのなら
運用する側が工夫すればよい
671:620
11/09/08 18:37:47.23
>>667
私の環境のTortoiseSVNだと、変更したファイルをクリックして状態を
観ると変更ありになり、コミット可能でした。
>>669
ファイルのみのctimeが同じな場合は、変更が検知されましたが、
その親ディレクトリのctimeを一致させた場合は、だめでしたので、
665ではそのように記述しました。
672:デフォルトの名無しさん
11/09/08 18:50:46.18
>>671
.git/ がある親ディレクトリまで含めて、全てのディレクトリとファイルの
ctimeを同じにしたけど、中身が違えば変更が検出されたぞ
どうなってんだ
673:デフォルトの名無しさん
11/09/08 18:53:09.32
このスレっていつからVIPになったの？
674:デフォルトの名無しさん
11/09/08 19:25:21.57
620は他のVCSに難癖を付けたいだけのSVN厨
675:デフォルトの名無しさん
11/09/08 21:37:47.88
URLﾘﾝｸ(stackoverflow.com)
676:デフォルトの名無しさん
11/09/09 18:59:34.46
svnはこれだな。
URLﾘﾝｸ(stackoverflow.com)
URLﾘﾝｸ(feather.cocolog-nifty.com)
を読む限りでは、
svnは>>667の通りで、
bzrは>>650っぽいけど、初めの状態からタイムスタンプが変わらない限りは
svnと同様ファイルサイズ等のチェックはしない…らしい。
svnで試してみたがやはり変更は検出されない。>>610>>620は何か勘違いしてる。
>>668
bzr/gitでも試したがタイムスタンプ一緒だと変更検知できないよ。