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

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

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

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

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

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

UTF-32（笑）

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

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

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

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

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

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

>>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を
選んでいるのは、それなりにメリットがあるから。

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

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

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

>>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るべき。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そもそも、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はもっと
使いものにならない。

>>237
>>224

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

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

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

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

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

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

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

つ >>164

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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

>>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も入るかも。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UTF-256とか作っちまえよ

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

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

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

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

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

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

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

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

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

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

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

>>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

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

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

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

あげたら

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++ の抽象化」も
> 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
> これらすべての設計上の決定のために、できてきた結果はゲロゲロで
> 保守不可能なカオスだ。

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 は思ったのだろう。

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

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

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

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

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

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

>>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.

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

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

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

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

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

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

など。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>326
使えるよ

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

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

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

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

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

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

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

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

gitとhgｵﾜﾀｗ

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

OSXなんて捨て捨て

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

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

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

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

Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の
扱いには満足していたんだし、Mac OS X の問題もとりあえず対応策が広まったし、
Unicodeでファイル名を扱うことを危険だと叫んでるのはただのFUD
Unicodeはすべての問題を解決してくれるわけではないが、文字コード周りの問題に
対するコストパフォーマンスの高い対応策。

>>342
GitとMercurialでファイル名に「ユニコード」が使えないという誤解を相変わらずバラ撒いている方がFUD

言い忘れたけど上の画像はOSXね

>>343
このスレでだれがそんなFUDを言ってる？
それとも、Mac OS X のNFD(モドキ)正規化問題に対応できてないというのがFUD？

>>342
> Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の
> 扱いには満足していたんだし、

満足なんかしてないよ。
波ダッシュとかの問題とか考えれば、永続的にメンテが必要なシステムに
ファイル名変換が行われるものなんか使わないよ。

>>344
Windowsでばーかというファイルを作成してMacでチェックアウトして
編集せずに git diff したら、何もしてないのにファイル名が変更されたって
報告されない？

>>345
つ>>208

>>347
GitHubにでもレポ作ってくれれば試すよ
興味あるし

>>346
たしかに、みんなは言い過ぎだな。
でも、波ダッシュ問題もWindowsだったらUTF-16で、LinuxやMacではUTF-8で扱えば
一切Shift-JISとの変換なんて起こらないし、多くの人は一部の文字が使えない
ことよりもリポジトリ内に複数の文字エンコーディングのファイル名が混ざる事や
たくさんの独自パッチ済みクライアントが乱立する方が管理が面倒だと感じて
CVSからSubversionへの変化を喜んでいた。

WinCVS日本語版でみんなこのオプション使いましょーねというルール決めても時々
設定間違ってコミットする人がいてリポジトリの内容が文字化けしていた時代に
戻りたいという人がどれくらいいるか。

>>347
gitは知らんが、hgはMacユーザがaddremoveすればWin/Linux/Macユーザみんなハッピー

>>349
https://gist.github.com/941544/
git clone git://gist.github.com/941544.git

>>351
Windows の hg って utf-8 ファイル名まともに使えるようになったんだっけ？

>>353
cygwin、fixutf8

>>351
あと、その方法だとLinux/Winユーザーがpullしてファイル名がNFDになると、
コマンドラインからファイル名指定するときに普通に日本語入力システムで
変換するとNFCになっちゃうからファイル名指定できなくて全然ハッピーじゃない。

>>354
fixutf8 ってもう安定して使えるのかな。TortoiseHGとの連携大丈夫？

cygwinを使う方法については、cygwinが必要だというのを明示せずに
「utf-8使えるよ」というのは、まどかシステム以前のQBのような気がするので、
ちゃんと「cygwin使えばutf-8使えるよ」と言って欲しい。

>>355
hgでコマンドラインでファイル名指定するのはhg log FILEぐらい。
hg add/remove/addremoveは自動認識するし。

>>357
チェックアウトしたファイルを開こうとして
$ vim ばーか.txt
ってやる場合を考えると、hgで直接ファイル名指定する機会が少ないというのは
リポジトリ内にNFDを突っ込む問題の一部しかカバーできてないと思う。

まとめ
日本語を使うのなら、、
集中型ならsvn
分散型ならbzr

日本語は使わないのなら、、
速いのが好きならgit
googleが好きならhg

>>358
たしかに「ば」が先頭だとシェル補完が厳しいなぁ・・・

>>352
git diffだと何も表示されないがgit statusだとUntracked fileとして表示されるね
WindowsのMsysGitを使った場合だとLinuxやMacではこういうことが起きるのか
勉強にはなったが、どうしようかなあ

ソースコードの中身ならまだしも、ファイル名に日本語とか情弱の極みだろ

まだ>>362みたいなことを言ってる馬鹿がいるんだな

ぶっちゃけどのバージョン管理システムかの問題じゃなくてWindowsの問題だよね

ファイル名はutf-8ではなくutf-7にしよう

自分、英語がプアなもんでファイル名に日本語が欠かせません！

英語にしてもそこそこ把握できる場合（予想）
『ワルプルギスの淫夢.txt』
『奴隷少佐ルクレツィア.txt』

英語にしたら把握に時間がかかるか訳がわからない場合（予想）
『目覚めると従姉妹を護る美少女剣士になっていた.txt』
『俺のフラグはよりどりみデレ.txt』



というような場合もあるんじゃないかな？
仮定、想像の話だけど。

確かにそうだな。
それはそれとして、そのtxtの中身について話をしたいのだが。

非実在テキストファイルですから。
何分、仮定、想像の話なので。

>>364
Windowsはutf-16 のAPIを提供しているのでそれを使えば問題ない。
どっちかっつーと、Mac OS X の方が、バージョン管理システムに限らず
ファイルをアップロードするときとか、zipファイルの中身とかいろんな
場面に影響するので凶悪。

>>369
ファイル名の話してんのに何言ってんの？
論点のすり替え乙

>>370
ファイル名の話だよ？
Windowsは10年以上昔(NT 4.0)からファイル名はUnicodeで扱っている。
Shift-JISなどでアクセスするAPIはレガシー用の互換APIで、基本的に使うべきではない。

厳密に言えば NT 3.1 (93年) だけど、サーバー、ワークステーション向けを
のぞいたらWinXP (01年) だから、10年以上ではないな。

いやだからファイル名の
話だろ？

Mercurialは、pythonがクソでレガシーAPI使ってるのが癌なんだろ。

あ
最新レス見ずに書いちゃった

>>374
Python はどちらでも扱えるようにしている。
open(u"ほげ") ならUnicode APIで、open("ほげ") ならASCII APIを使う。
bzrは前者、mercurialは後者を使ってる。

cygwin は、 fopen("ほげ"); すると、 "ほげ" を utf-8 でデコードして、
UTF-16にエンコードして、 CreateFileW に渡している。

>376
それがクソって言ってんの

>>377
えー、これがクソならどうしろと、、、
C#やJavaみたいにバイト列でファイルパスを指定するの禁止したらUnix系で
すごく使いにくくなるんだけど。
Python の仕様は超現実的で、RubyやPerlよりもずっとWindowsで使いやすいと
思ってる。

というかそれならMercurialで問題になってるのは何なの

>>379
http://mercurial.selenic.com/wiki/EncodingStrategy

>>379
英語のwikiにはNTFSはUTF-16となっているが、実際は２バイトのバイト列。
UTF-16としては不正な値も格納される。

NTFSがUTF-16とは書いていないか。
> kernel has a mix of byte-width and wide character APIs

Windowsシステムオンリー。日本語ファイル名あり。日本語ディレクトリあるかも。
Git、Mercurial、Bazaarから、上記の条件で考えた場合、分散型初心者が取っつき
やすいのは日本語対応が進んでいるBazaarでしょうか？

その条件ならシェル統合がまともに動くMercurialじゃないか

Bazaarは日本語対応進んでいないでしょ。

Windows onlyならhg、bzrのどちらでもいいと思う
でかいファイルを扱うならhgかな

書籍の有無、Web上での情報量、CUI/GUIのメニューの日本語化を含めて日本語対応と言うべきであって、
Mercurialが一歩抜き出ていて、CUI/GUIのメニューは >>325 でGitも対応する方向だと言う認識だが。

bitbucketとlaunchpadなら断然bitbucket
githubの方がもっといいけど

分散だと日本語環境はbzrが独占状態なのよねぇ。
他は何をやってんのやら。

>>389
> 分散だと日本語環境はbzrが独占状態なのよねぇ。
> 他は何をやってんのやら。
「Windowsのファイルシステムの」日本語環境でしょ。
Windows上で日本語ファイル名を使わなければ、Git、Mercurialでは何も不自由しないけど。

そうはいっても
○○支社向け.docとか
○○部長月間予定.xlsとか
いう日本語ファイル名って結構使うからねぇ

>>391
リポジトリを分ければ良い。
そういうファイルがあるところだけsvnにすれば良い。
svnはリポジトリを一ヶ所にするというのが一般的のようだが、
別に一ヶ所にする必要もない。

運用ポリシーで複数の管理システムを使うのはちょっとね
後々の事を考えてシンプルにしないとさ

Windowsだけで使う分にはHgでも日本語ファイル問題ないだろ？

>>394
CP932に無いUnicodeの文字も増えてきているからねえ・・・

○○支社向け.docとか○○部長月間予定.xlsとかは分散してる必要無いんじゃないか。
どうせマージ出来ないだろうから、むしろ分散してたら不都合な気がする。
そういうのはsvnでいいんじゃね。

>>396
Mercurialはロックを実装する気でいるぞ。
http://mercurial.selenic.com/wiki/LockExtension/NewDesign

>>397
分散型でlockとかｗｗｗ
というのは釣りですが、それでワークフローがうまく回るなら良いですね。
特に仕事でアジャイル（）とかだと分単位で作業が入り乱れるだろうから、
バグトラッカとかでやりとりするよりもスムーズかも知れない。

かといって、1プロジェクトに関わる設計書とかが単一の管理から外れるのも困る。
結局のところ、運用でごまかせって感じになっているのがなぁ。
誰だよ1バイト圏意外に住んでいるやつは。

>>396
中央リポジトリ関係無く好きに各ローカルリポジトリにプッシュ/プル出来るから分散のメリットは大ありだよ
人間の相関と分散管理はすごく相性がいいから無駄なんていっちゃいかん

×無駄なんて
○不都合だなんて
失敬

>>400
ワードとかエクセルのマージ作業はどうするの？

それって別に分散かどうかは関係ないよね

>>403
マスターリポジトリにプッシュするまでもない物をとりあえず確認するために
個人のローカルリポジトリにアクセスしたりとか
個別相談受けて訂正する時にその人のローカル除いたりとか色々ある
メッシュ網じゃないsvnなんかじゃこういうのは出来ないのさ

gitやhgが「Windowsでは」Unicode APIを使わずにバイト列でファイル名を扱うのはなんなんだ
バイト列なら>>376の言うようにPythonが対応しようが解決できないよね、これ
BazaarのようにUnicodeと決めているならUnicode APIに渡すときに変換なりするわけでしょ
でもバイト列で扱う方針なら変換できないよね
localeに応じて変換するのだろうか
マルチバイトのファイル名のマルチプラットフォームの問題はそもそも解決できない問題なの？

根本的には、ファイルシステム毎に使える文字が違うんだから細かい差異まで吸収できるわけがない。
やろうと思えば主要ファイルシステムの動作をエミュレートできるようにしたうえで、addした時のファイルシステムを覚えておくことになるだろうし。

それとは別に、必要な変換をしてくれないのは単なる無理解と手抜き。
gitについてはLinux上で最高のパフォーマンスが出せれば後はどうでもいいという大義名分があるけど、hgは単に開発者が無理解なだけだろ。
(bzrの互換漢字を正規化してしまう問題も、そんなことをするファイルシステムが現存しない以上やり過ぎと言える)

・欧米人にはファイル名にUnicodeを使う需要が無い
・欧米人はファイル名にCP1252(ISO-8859-1)が使えれば満足
・欧米人はLinuxでもファイル名はISO-8859-1を使っている
・Linux/UnixでロケールをUTF-8にしているのは日本人が主
・日本人はLinuxでEUC-JP/Shift_JIS/UTF-8の混在に慣れているが、これは日本の特殊事情

>>406
> hgは単に開発者が無理解なだけだろ。

無理解とは思えないが。
http://mercurial.selenic.com/wiki/EncodingStrategy

cmd.exeとGUIアプリの扱いが違うというのは、このスレでは話題になっていなかったが。
bzrがcmd.exeでCP932の方が無理解だと思うが。

hgが叩かれる時のリンクじゃないかそれ

cmd.exeでもW版APIを使えばokというのが周知されてないのも無理解の象徴だな

>>409
cmd.exeでwは使えない。
wprintf()がcp932とかcp1252の時にデータが欠損する。

>>409
bzrでお馴染みのpythonのコーデックエラーは、cmd.exeのことを考慮していない証拠。

使えるっての。
libcではなく自分でAPI呼べよ

>>412
chcp 1252 して日本語混じりのをwprintfしたら何が出力される？
だったら、printfでバイト列で出力した方がマルチプラットフォームアプリとしては
正しいと思うが。

>>413
cmdでUnicode使わない背景には、cmdのフォントの設定によっては表示されない
恐れがあるからという理由があったはず。
まぁ、一番は単に他の部分のファイルのインタフェースと整合性を取るのが大変
だからだろうけど。
CLIでunicode使いたかったら cygwin + minitty が最強。

>>412 だった。

UnicodeじゃないからUnicode版API使えないと言いつつ、
得体の知れないバイト列をANSI版APIに流し込む矛盾。

>>412
出力って何のこと？diffとか？

>>416
CP932と繁体字がASCIIと互換が無いから問題なのであって、
それ以外のコードページとLinuxでは、シングルバイト用のAPIで何ら問題が無い。

>>413
さすがPowerShell ISEさんに隙はなかった・・・

>>419
Mercurialは--encodeオプションかHGENCODING環境変数で、UTF-8が指定できるから、
PowerShellでも問題ない。これが正しい多言語化。

--encodingだった。
--encodingmodeってのもある。

>>420
や、俺が言ってるのはコンソールとしてのpowershell_ise.exeのことね
chcpコマンドがまともに機能するWin7標準のアプリ
従来の対話型コマンドが動作しないのが玉に瑕

>>422
PowerShell ISEってフルで言わないとだめなのか。
PowerShell ISEでMercurialでchcp 65001が最強。

>>423
うん、同意

chcp 65001 をしたら、fopenがutf-8を受け付けるようになるの？

>>313
そのwprintfはwcstombsしてるんだろ。

まずWriteConsoleWでUTF-16のまま無変換出力を試みる
→エラーになったらコンソール以外にリダイレクトされてるから
保存用コード(ロケール使うのが正しいがオプションでUTF-8を提供してもいい)に変換して改めてWriteFile
がWindowsでの正しいUnicode対応コンソールアプリの作り方。

>>413だった

>>426
Mercurialはファイル名とファイルの中身以外は内部UTF-8なんだからwcstombsを使う理由が無い。
http://mercurial.selenic.com/wiki/EncodingStrategy#Functions
にある通り、fromlocal()、tolocal()、colwidth()という関数が用意されている。

>>428
すまん、アンカーミスなんだ。
元はcmd.exeでWが使える使えないの話の流れなんだ。hgの実際の実装は関係ないんだ。

>>429
バージョン管理と何の関係があるの？

PowerShell ISEは旧来のコマンドプロンプトの諸問題を解決してくれて便利
シェルとして使いにくいのが悲しい点

gitでリモートからdiffを取る機能が無いか
gitスレで聞いたんだが基本的に存在しないらしい。

svnから物凄い機能後退だと思うのだけど、
bzrとかhgとか或いは、darcsとかmonotoneでも
出来ないのが通常なのだろうか？svnでは
svn diff -r 123:456 svn://server/repo/trunk
とかで出来たと思うんだけど。

普通に考えたらdiff取るだけなのに毎回リモート見に行く必要があるsvnのほうが……

SVN脳と言わざるをえないｗ

そうまでリモートに集約したいなら集中型のsvn使っとけば丁度良いよ

gitスレでも指摘されてるじゃないか
集中型じゃなくて分散型の思想について勉強してこいよ

ゲソなりく〜ん

>>432みたいに新しい環境に拒絶反応示して興奮してる人って、後で恥ずかしくなったりしないのかね？

全成果プリントアウト(しかもシリアルプリンタで)がいいとおもうよ☆

いや、思想とかキモイです。
全部できないのか。酷い有様だな。

>>440
ssh gesonari@kimoi /usr/bin/git --git-dir=/svn/nou diff v0.1 v0.2

>>440
bzrはできる。

もうさわんなよｗ
タダの基地外なんだから。

bzr は遅くて泣けてくる・・・

>>444
最近はそうでもないぞ。
といっても、Windows以外のユーザーが最新のbzrを使うにはソースから
インストールするかFedoraかUbuntuの最新版を使わなきゃいけないけど。

＞使っていたソフトの開発元が svn+trac からgithubに
＞変わってしまってかなり機能後退と分かりゲンナリです。
このソフトって何だろうね。
意図せずGitHubに移行しなきゃいけなくなってゲソナリってことみたいだけど、
そこまでイライラするぐらいなら古いバージョンでsvn+trac使うことは出来ないのかな？

＞酷い有様だな。
おまえの頭がな

分散型がキモかったら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 も結構追いつきつつある(と思う)。
> あんまり日本語ファイル管理することもないんだけどね。

>>433
svnはリモート見に行く必要は無いんだが何いってんの?

>>449
それは作業領域の話。
特定のリビジョン間のdiffを見る場合、リモートを見に行く必要がある。

svnの仕組みもしらないsvnﾏﾝｾｰがﾌｧﾋﾞｮｯてると聞いて

スレがずいぶんと酷い有様だな。

ということでsvk最強

>>445
いや、最近久し振りに使ったら遅くて泣けた・・・

>>454
毎日使ってるけど、遅くて泣きたくなるのは、画像ファイルとかバイナリファイルを
たくさんリポジトリに突っ込んじゃった場合だけ。
どんな状況で遅かった？手元のバージョンが良くてもサーバー側のバージョンが
悪かったりしない？

>>455
launchpadの遅さは異常

>>456
試しにやってみたら、 bzr branch lp:mysql-server が 73771 リビジョンの
ブランチに 16m37sec かかった。
速いとは言わないけど、別に1日たっても終わらないとかじゃないし、最初の
1回だけだし、十分実用的な速度だと思う。
github や bitbucket に mysql のミラーないかな？

24時間経過しても終わらない上にエラーで失敗したりするgit cvsimportとかと比べたら
16分とか一瞬だった

無理すんなよw

>>457
Linuxカーネルは？
bitbucketじゃないところにhgのミラーはあるよ。
確かhgのポリシーにのっとって、バージョン毎にリポジトリが分かれていたから、
単純比較できないかもしれないけど。

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 の方が速いんだろうけど、別に泣きたくなるほど遅くはないな。

Emacs も酷いね。

>>461
初回はどー考えてもsvn有利だろw

てか履歴1個だけじゃ他の分散型と比べられないよなー

>>462
$ time bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk emacs-trunk
real 17m46.033s
user 7m24.300s
sys 0m15.460s

2月辺りにはなんか問題あったらしいけど、改善されたらしいね。

time の履歴が流れちゃったけど、 savannah から git で emacs を clone
したら5分弱だった。emacsの場合はgitの方が4倍くらい速いな。

とりあえず、一晩たっても終わってないとかそういうのはなさそうだから、
実用上問題にはならないだろ。

bzrはやいなぁ
hgから乗り換えるかな

bzrの遅さはpull, push, merge全部が遅いってことでしょ。
インターネット越しじゃなくて、イントラネットでも。

バージョン上がる度にbzrは早くなってるな

俺もいつかは bzr が速いって言える様になるのかな・・

bzrはhgより早いし次はsvnとgitだな

と、bzr信者は何の根拠も無く申しております

hgはオワコン

と、bzr信者は何の根拠も無く申しております

時代はgitとbzrの2強の時代へ

と、bzr信者は何の根拠も無く申しております

マジレスするとGitとhgだろうな。どっちも似てるんだけどね。
GitHub vs Google Codeか。Launchpadはいまいち人気無いよね。

gitは男の子。bzrは女の子。hgはハードゲイ。

github は本当に良く出来てるよね
必要な情報が無駄無く配置されていて使い勝手がとても良い

gitはM$捨ててるからM$で遊んでる俺の選択肢にはなり得ない

>>461
githubのruby、trunk以外のブランチも入っているじゃん

>>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.

gitもhgもutf-8に対応しているが、cmd.exe、MSysなど、MSの環境が糞なので、
まともに使えないってことだ。

>>481
うん、完全に同じ条件ではないとあとで気づいた。
だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
してはあながち的外れな比較でもないと思う。

まぁ、やりたかったことは、bzrとgitのどっちが速いかを調べることではなくて、
一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
一晩経って終わらないとかそういう事が無いことが確認できただけで満足。

本気で比較したかったらLAN上で帯域やレイテンシやパケロス率を制御した環境を
作れるはずだけど面倒なのでパス。

>>484
> 一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
> 遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
> 一晩経って終わらないとかそういう事が無いことが確認できただけで満足。

launchpadにアカウントを持っている人が一部の人では？
Emacsはlaunchpadではないけど、github・bitbucketに比べてcloneが目に見えて遅いのは
普通の感覚だと思うが。

>>484
> だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
> ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
> してはあながち的外れな比較でもないと思う。

git・hgはリポジトリに全部のブランチを入れるかブランチ毎にリポジトリを分けるか、
柔軟性があるけど、bzrはブランチ単位でしかcloneできないんじゃないの？
githubのrubyはgit-svnを叩いているから、ブランチだらけの状態だと思うけど。

launchpadは遅いというよりちょくちょく落ちてるのがなあ……

>>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に敵わないけど、遅いという印象を払拭するには
インタフェース面でもできることがありそう。

「一晩」が実用の判断基準っておかしくない？
git cvsimportやらgit-svnやらhgsubversionやらhg convertの最初の一回目が遅いのは当たり前。
だから、rubyのgithubみたいにミラーがあるんじゃない？
一回cloneすれば、その後のpullは差分だけど、そのpullもbzrは重いって指摘は
ぐぐればいっぱい出てくるけど？

> ぐぐればいっぱい出てくるけど？
これよそでは言うなよ恥ずかしいから

>>489
厳密な比較は面倒だからしないけど、きっとgitやhgよりも遅いんだろうな。
でも、俺は実用的な速度だと思ってるから使い続けてる。MySQLだって
あれだけ大きいプロジェクトで本当に使い物にならないほど遅かったら
とっくに乗り換えてるだろ。

bzrが実用にならないほど遅いという結論がでないとなにか困るの？

bzrでもsvnに比べたら御の字じゃないの？

常識で考えてGitが速すぎるんだよ。
clone中のあのいかにも速そうなインジケータとか、最初に何となくやるであろう
Linuxカーネルのcloneの速度とか、最初から狙ってると思う。

実用になる人も居れば、ならない人も居るってだけじゃないの

今使ってる人は使い続ける理由が欲しいだろうけど、今使ってなければ
別に思い入れもないし、遅いのが嫌なら bzr は選ばないでしょ

>>491
MySQLは万人がハックしてパッチを送るタイプのプロジェクトでないでしょ。
Emacsのビルドにbzrに接続することを要求されて、それで、bzrの重さの認識が一気に浸透したと思うけど。

cvs、svnもゼロから始めるソースはそんなに重くないけど、
だんだん重くなるよね。
bzr信者は感覚が麻痺しているんじゃないの？

cvsがデファクトスタンダードでsvnがそれに置き換わるかと思われたけど、
svn離れが加速しているよね？

遅いものは主流になり得ないというのは歴史が証明していると思うけど。

信者呼ばわりか。まぁ否定はしないけど。
別に bzr が今後も主流になりえないかもしれないけど、Canonicalが潰れる
までは衰退することもないし、その時に考えるからいいよ。
俺は単に使い物にならないほど遅いとdisられがちだから本当にそんなに
遅いのか実験してみて、俺に取っては許容範囲だと判断しただけ。

Emacsの件はいろいろ不幸だった。savannahのサーバーのセットアップが
悪かったり、タイミング的に bzr 2.1 以前を使ってるユーザーがまだ
多かったり (lennyのデフォルトのbzrなんて1.5とかいう使い物にならない古さ)
したからな。

> cvs、svnもゼロから始めるソースはそんなに重くないけど、
> だんだん重くなるよね。
svn の場合、ファイルシステム(リポジトリのフォーマットのこと)によって違うよね。
以前の bdb の場合はリビジョンが増えてもチェックアウトは速かったけど、
今のデフォの fsfs の場合はリビジョンが増えるとチェックアウトが遅くなる。
その半面、 fsfs ではホットコピーが簡単になり、壊れなくなったけど。

信者認定プログラム：OS　エディタ　プログラミング言語　これにVCSが仲間入りか。
他にもキーボード配列とか文字エンコーディングとかあるけどね。

Emacsはbzrの重さの認識が万人に浸透するほどハックされてるのか
Lisperの一人として胸厚だわ

友情は厚い、ですが胸は熱い、じゃないでしょうか？

鍛えてるんだろ

git>>>>bzr>>>>>>>>>>>>>>>>hg
今はこんな感じか。
hgの一時の勢いはどこへやら。

windowsオンリーの環境で分散型を取り入れる時、
git、hg、bzrからhgを選んで導入も終えてそこそこ使えるようになってきたのに、
だれだよオワコンとか言うのは！

>>502
hg いいと思うよ。そのうちWindowsでちゃんとUnicode API使えるようになりそうな気配だし。

>>501
2chのスレの勢いだとそうかもね。
hgの場合、日本語で語れる場所が他にもあるから。
そこで取り上げられていた、このスレに絶好のネタが2chでは取り上げられていないし、
住み分けができてるんじゃない？

おっと、>>503に例のネタ、先を越された

>>483
それもひっくるめてgitが糞という評価になるんだが。

MS 製品を使ってない俺には何が問題かさっぱり

なんども書いてるがcmd.exeっていうかWindowsのコマンドプロンプトでもUnicodeは使えるぞ。
UTF-8ではなくUTF-16になるから、#ifdefが必要になるだけで。

MS製品に依存してる連中がオレ様野郎ばっかというのがよく分かる。
Linux使ってる人が「VSSはLinuxで使えないから糞」なんて言わないからな。
別の意味では言ってるかも知れないが。

>>506 >>508
svnのmac portsのような対応をgitに望んでいるのか？

TortoiseCVSもTortoiseSVNも1つ落としてきてインスコするだけで使えるんだが
TortoiseGIT(笑)はそうじゃないんだよな
それを導入することによりよっぽど捗るとか利点がない限り
そんなまんどくせーものわざわざ手間かけてまでつかわねえよ

>>511
CVSとSVNのパフォーマンスとマージに満足なのですね？
CVSとSVNのマージはまんどくさくないのですね？

>>509
VSSがいいといっても見向きもしないでしょ、その人達は
文句を言うときは実装と一緒
gitがいいという話を聞いてうっかり使ってしまい文句のみを垂れ流す、それがWindowsユーザー


と、こんな風なレスを期待しているのか？
不毛じゃね？

>>513
> VSSがいいといっても見向きもしないでしょ、その人達は
VSSが糞なのは周知

>>512
自分の使わない機能がいくら速かろうが関係ないの
おわかり?

マージ使わないならrsyncとかtarballとかでいいんでは……

>>515
TortoiseCVS(笑) TortoiseSVN(笑)

>>515
使わないんじゃなくて使い方がわからないんだろ
おわかり?

>>518

>>515

>>515

きょうも元気だごはんがうまい
おかわり?

一人で開発する時は dropbox のフォルダに cp -R してるわ

dropboxとかねーわ

>>524
もっと良い奴あるの?

>>517
？

>>525
SugarSync

>>527
どこら辺がいいの?

SugarSyncとDropboxは良く比較されるしググればすぐ分かるぞ・・・・

いや、もちろん違いは知ってるんだけど、SugarSync のメリットがよく分からん

Github for Mac
https://github.com/blog/878-announcing-github-for-mac

code.google.com でも git が使える様になったらしいね

http://code.google.com/p/support/issues/detail?id=2454#c43

>>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.

github、bitbucket優位の状況は変わらないだろう

Windows上にあるエロ画像とかエロ動画とか日記とかが雑多に保存してあるホームディレクトリを
まるっとバージョン管理するには何使ったらいいの

dropBox

テキストとそれ以外はバージョン管理のシステムを分けたほうが良い？

>>536
え？dropboxってバージョン管理できたの？別スレで
ttp://d.hatena.ne.jp/shibamu/20101014/p1
見て阿呆かと思ったけど意味があったのか…

>>537
同期して管理する必要が無いんだったら分けた方が良い、かも。
無関係なもの一緒くたにすると重くなりがちなので。

>>532
サーバのオプションどうなってるんだろうね。
sf.jpはrebaseできないの知らなくてすげー困ったんだけど。

>>538
俺もソースツリーのバックアップを dropbox に置いてるけど、何か問題あるのか?

バージョン管理は別途ツールを使ってるよ

>>540
>>538はバックアップじゃねーぞ

>>541
dropbox のディレクトリは単なるローカルのディレクトリでしょ
ビルドしてオブジェクトファイルが更新されたらバックグラウンドで
アップロードが走るのが嫌とか、そういう話?

元質問エロ画像やエロ動画や日記のバージョン管理を求めている。

>>540-542
ごめん俺drop boxのこと全く知らないし興味もないしスレ違いなので忘れて。

最良のバックアップは配布だ。トモダチにコピーして回る。

で、どんな得ろ画像だ? JSと熟女と太めは歓迎なので俺とトモダチになれ。

この板的にはJSと言えばJavaScriptだな。

dropboxならファイル単位で履歴管理できるしシェアもできる。
ソースの管理には向かないが、画像の管理にはそこそこ便利。
で、ソースのバックアップをdropboxに置くくらいなら、リポジトリを置いてしまうのも手。

gitで複数のブランチそれぞれに個別の未コミットのファイルを残したまま
ブランチを渡り歩くことってできる？
イメージとしてはbazaarで複数ブランチを同時にいじってて放置したまま
ブランチ間をcdで移動するみたいな。

diffとかはファイルとしての実体は不要でいいんだけど
gitは未コミット分をかかえたままになるのがちょっと困ってる。
いちいちstashとか嘘commitとかするのは
その判別含めて自動化できないと面倒で…。

MercurialならShelveがあるのにな

少し調べてみたけれど、
Mercurial の Shelve って git の stash と完全に同等に見えるけれど、そうでもないの？

TortoiseHgにあったShelve Changesは
ファイルごとに退避ができてstashより便利だなーって思った覚えが。

>>548
ブランチの数だけcloneしたら？

>>552
自分も一旦はそう考えたんだけど、それだと結局bazaarと同じ運用になって、共有リポジトリ使えない分だけ損してるような…。

ツリーは1つ、というのが気に入ってbazaarからgitに移行しようかと試してるんだけど
標準ではサポートされない（というか人気のない？）使い方なのかな。

濱野さんの本にはこう書いてある。
あとから追いやすくなるのでコミットは意味ごとに独立させるべき、
意味（意図）が同じコミットはあとからまとめるのもよい、
ローカルリポジトリは意味ごとにrebaseなどで改竄もむしろ推奨。

ということは、ブランチも意味ごとに直交させて切るべきだと思うんだけど
そーするとなぜ未コミット分がブランチをまたいで受け継がれるんだろう。
ブランチをまたぐ際にstashとか破棄前提の嘘commitが必要ってのは
単に実装が思想に（まだ）合致できてないってことなんだろうか。
日常的に使ってるとブランチは常に2〜3個必要になるし、
瞬間的には 4個とかにもなるんだけど、みんな困ってないのかな。

Shelve Changesも実は嘘コミットだと思えば気分が楽になるんじゃね？
いやShelve Changesがどんなものか知らんけど。

>>535
NILFS

たくさんのリポジトリを一気にPull(Fetch)できるGUIのツールって無いかな
GitやHgのリポジトリ一つずつ更新していくの面倒

いや、サブディレクトリにあるリポジトリでfetchをする
スクリプト書けばいいのかもしれないけれども、GUIの方が良いし

>>557
俺はそんなのシェル一行ですませるけど、GUIのツールがほしいなら作れよ

GUIのツールで一気に何かするのって俺は怖くてやだ

復帰

Bazaar日本語ファイル名の問題がないらしいので手を出してみたが
GUIの既定値が自分の使い方とあっていなかった。
コマンド入力で補助しないと行けない。
Mercurialは自分と合っていそう。
rebase, transplant, splitを使って少しだけ内容の違うブランチを
双方で変更する場合に対応できる。
今までsubversionでリビジョンの範囲をマージする方法でやってきたが
履歴改変にはまりそうだ。

会社で開発メンバーが増える事になり、バージョン管理システムを使えとのお達しがでた。

条件は以下の通り

・NASでソースは管理する。（購入済み）
・サーバーレスで動くもの

調べた感じでSubVersionしか無いんじゃないかと思ったんだけど、他におすすめありますか？
上の条件に合致すれば 分散だろうが集中だろうが関係無いらしい。

いやどれでもファイルベースのリボジトリ操作はできるだろうけど、
いろいろ無茶じゃないか……？

そのNASで複数の接続先から同時に同じファイルに排他ロックをかけようとして
ちゃんと動くか程度は確認したほうがいい。
ネットワークファイルシステム越しのロックがかからないようなら
サーバー建てるなり個人リポジトリとマージ用を分けるなり考えたほうがいい。

NASじゃ無理だろ
誰かのマシンでサーバを動かしてリポジトリはNASに置けばいい

同時書き込みしたらファイル壊れるな

いや、それこそsvnならファイルベースアクセスであってもロックファイルを作るぐらいのことはしてる。
だから一台のマシン上で複数プロセスから同時にコミットしても壊れない。

問題はネットワーク越しにそれをやると、ロックファイルを作ったつもりになって相手への反映が遅れるとか
NFSの制限でロック取れなくてもエラーが帰ってこないとか、なんか起きそうなことだ。

個人毎にリポジトリをもって、マスターのリポジトリへの反映は申請制とか

確かVSSはサーバーレスで動いたような……

分散型なら置くだけだからファイルコピーができる状況ならファイル置ける

>>562
SCMが全くわかってないなぁ、お前んとこの上司わ。
多分その上司は、そのNASがエクスプローラのWindowsネットワークに見えてないと
怒り出すんだろうな、きっと。

ちなみに、オレんとこの会社では牛NASを殻割りしてdebian突っ込んで、
そこでapache+subversionを動かしてるから、
・NASでソースは管理する。（購入済み）
という条件は満たしてるし、ソースの管理に必要なのはそのNASだけだから
・サーバーレスで動くもの
という条件も確かに満たしてはいる。

しかし当たり前のことだが、エクスプローラでは見えない。
つか、わかってないやつには見えないように設置する。これ、重要じゃね?

562の条件だとエクスプローラで見えなくても良さそうだが、
リポジトリを直接覗いて何が入ってるかわからん！なんて言われるレベルだとどうしようもないな

何も考えず独りよがりの思い込みでNASを買ってくる時点で、
どうしようもないレベルという条件は既に満たしてしまっている気がするが...。

みんなレスサンクス。

SCMについては俺もしっかり理解できてなくて勉強しながらやってるから勘弁してくれ

NASへのファイルの同時書き込みとかの問題は言ったんだけど
「今時のNASでそんなのあるわけないだろ、自宅で使ってるがそんな事起きたことが無い」
とか言われてナシのつぶてだった ('A｀)

んで、別のサーバ動かしてリポジトリをNASに置く件については
「サーバーとNASが同時稼動前提とか何考えてるんだ」らしい。

>>570
エクスプローラで見えてないとキチンと運用されているか俺がわからんとか言うタイプ

>>571
NAS(LS-WVL) を殻割りしてサーバー入れる手を考えてたんだけど、
「保証受けれなくなるし、もう半分ぐらい移行したから無理」とか言われるし

>>568
VSSは使いにくいって上司がいってｒ

>>569
分散型ってマスターの場所にサーバー入れて管理みたいな図を見たんだけど必要無い？
必要無いなら保存先がNASってだけでいけそうかなぁと

もう文句言いまくるくせに自分では絶対しない人なんで
ﾏﾝﾄﾞｸｾ('A｀) ｳﾞｧｰ

まあ、やってみなよ。リポジトリが壊れても知らんけど
いざとなったら日付フォルダで…

>>574
自宅用途でそもそも同時書き込みが発生するかよ。
本当にファイルに排他制御がかかるかテストさせてくれないのであれば
個人リポジトリを分けて、マージ担当を置いたほうがいいな。

>>576
保存先がNFSならいけたんだが、単なるNASだと無理。
あきらめろ。

どんなたいそうなNAS導入したのかと思ってググったら、それ15,000円位のゴミじゃん
業務でそんなの使うの？
サーバアプリ動かせるちゃんとしたの導入すれば？

まあ分散型なら自分とこのリポジトリが生き残っている可能性があるか…

分散型にして、そのNASは無いものと考える。

たしかにGitでロック競合しておかしくなったとしても
なんとかなっちゃいそうだよな

ダメ上司もつと大変だな

声かけしてコミットしなよ

確かにGitやMercurialならpushの前に声掛ければいいな

その上司の下じゃ何使っても駄目なんじゃ

分散型とか理解出来なさそうだ

今まで鯖も立てずによく業務がこなせたなとある意味感心する

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

訂正。Subversion は一番安いの (TS-112 \20,000未満) でも用意されてる。

>>589 *nix系NASならbootする途中でのっとっちまえばなんでもありじゃん
gccのクロスコンパイラなんて簡単にできるんだしw

>>587
そんなときこそ Bazaar ですよ。
分散型が理解できないアホには集中型として、理解できる人には分散型として使える。

>>562
うちは Bazaar で共有リポジトリを共有フォルダ上において
push/pull あるいはmergeしてるから、NASを使っているのと
ほぼ同じ構成だな。

>>592
のやり方が一番幸せになれるんじゃないかと思った。

まだ自分がバージョン管理システムについて勉強中なんで
具体的な実現方法は見えてないんだけど、基礎的なものを勉強できる資料でおすすめって何かある？

リポジトリとかブランチとかさっぱりな初心者でも分かる資料・・・ orz

>>588

今までは自分が全部のソース管理をしてたんだよね。
でも今年の中頃から打ち合わせだとかで不在が多くなって
例の上司が「俺がソース管理をしてやろう」ってなってからデグレが８回。

全部自分が対応してなんとか復旧 orz

>>594
書籍・ドキュメント・実績豊富なGit・Mercurialを素直に使いましょう
まず近場の本屋に行きましょう
Bazaarが選択肢に入らないことは明かです

ClientのOSを聞かずに何かをお勧めしちゃうの？

Clientは Windows XP以上のOS全般です。(32bit、64bit混合)

>>595
>今までは自分が全部のソース管理をしてたんだよね。

どうやってたのよ？

で、上司が管理したらなぜデグるのか、原因はわかってる？

バージョン管理システムは管理を楽にしてくれるし、 変なことできにくくしたり、
変なことしても復旧が容易だったりするけど、それでも変なソースをコミットして
混乱に陥るってことが皆無というわけじゃないよ。

分散型を選んで統合マネージャー型のワークフローで運用すればいいんじゃね
ttp://progit.org/book/ja/ch5-1.html#id103

どう運用するかが肝でどのツールを選ぶかはたいした問題じゃないと思う

なぁ、将来にわたって考えると数人月以上もコストがかかるやり方をやり始めるより、
5〜20万出して(まともなサーバ or プログラムが実行できるNAS)(+UPS)を買った方が断然良くないか

それだったら問題の上司を飛ばすのが一番だよw

>>599
今まではPG一覧の資料作って、修正する際は申請してもらって修正中フォルダへ移動
PG一覧へ修正者の記載。

修正が終わった段階で修正中フォルダからメインフォルダへ移動→PG一覧に更新日を修正状況を更新

上司がデグらせたのはこの辺の管理を全くせずに勝手にフォルダ移動OKにしたところ。
あとPG一覧も修正せずにいたからこうなった感じ

>>603
その運用がちゃんとできているなら、ツール入れればだいぶ省力化できると思う。

その上司じゃどうしようもないから、早めに管理システム入れたほうがいい。

>>603
Tracとかredmineを検討したほうがいいんじゃない？鯖いるけどｗ

鯖立ち上げまで一発でインストールしてくれる
そんな夢のようなツールないですかね

>>603
うげぇ。そのPG一覧はExcelってオチか。
それはマズイ。

そのレベルだと VCS 入れたら入れたで問題起きそうだねえ

各モジュールに担当が決まっているような職場で、オプソ界隈のVCSがどれくらい効果的に使えるかねぇ?

…とか茶々入れてもしょうがないな。DVCSにして、マネージャ級だけがプッシュできるリポジトリを作るに一票。
>>600

画像ファイルをリポジトリに入れてるんだけど、色を変えただけでファイルサイズが同じだと
変更を認識してくれなくて酷い目にあった。
試してみたら
bzr : NG
git : NG
hg : OK
svn : OK
って感じだった。

これって常識？

バナリはなあ、、、
タイムスタンプ見るかどうか？

mjd?
ありえんなあ。

>610
VCSによっては、タイムスタンプもサイズも同じなら中身まではチェックしないってのはある。
タイムスタンプが変わってるのにサイズが同じってだけで変更無し扱いになるってのはちょっと考えにくい。

>>604
上司がやってなかったところがシステム化されるので大丈夫かなと思います。

>>605
まだどのバージョン管理システムを使うか検討段階なんで
どういうものがあるかも含めて教えてもらえると助かります。

鯖は無しでいいやつがいいです・・・・orz

>>614
各ホストファイル共有ベースでやってるならなおのことDVCSがいいね。

>>614
聞いてる感じだとMercurialが無難そう。GUIクライアントもこなれてるし。
日本語ファイル名をつかうなら、個人的にはBazaarを推したいけど。

とりあえず、HgInitでぐぐって出てきたページを読んでみるといいよ。
オリジナルは英文だけど和訳もあるはず。

>>610
＞git : NG
これは信じ難いなぁ

>>610
同じサイズのバイナリファイルということで
dd if=/dev/urandom of=file count=1
で試してみたけど再現しないな。何かやり方を間違っているだけでは。

ある程度以上の大きさのファイルは index に含まれなく、ファイル全体比較もしないんじゃないかな?
(一部だけ比較してるとか)

>>610
gitとbzrとsvnで確認してみた。
同サイズでタイムスタンプが同じだと、確かにgitとbzrはNGだった。svnはOK。
同サイズでタイムスタンプが異なるとgit、bzr、svnの全部がOKだった。

え、タイムスタンプが関係してくるSCMって大丈夫か？

バイナリーは特別扱いだろ

>>622
それは、バイナリファイルの場合は特別にタイムスタンプによって何か処理するということ？

まずバイナリの定義を述べてもらおうか

>>624
そのVCSでテキストレベルのdiffが取れないのがバイナリの定義じゃね？

>>624
gitとかsvnはバイナリファイルかどうかを判断してんだけど、知らないの？

>>624
mercurialだとNULバイト(0x00)が存在するものをバイナリファイルとして扱っているよ

gitのこと全然知らないんだけど、軽くググったところによると、「同サイズで同じexifを持ってれば同じとみなす」
とかいうことかも。
ファイルそのものの属性としてのタイムスタンプを見てるとは信じがたい。

気になるならテキストモードでやればいいだけ
それが専用プラグインなんかを突っ込む(Excelなんかはそうやるだろ？)
この手の質疑応答は10年ぐらいから嫌という程みてきたわｗ

×この手の質疑応答は10年ぐらいから嫌という程みてきたわｗ
○この手の質疑応答は10年以上前から嫌という程みてきたわｗ

要は該当するファイル群に対して強制的にハッシュを取るようにすればいいだけの事

gitとbzrとsvnで確認したのはWindows7上でした。
テキスト・バイナリ同じ結果となりました。

Linuxでは、ctimeを任意に変更することができなかったので
同じタイムスタンプのデータは作成できませんでした。
gitでは、chmod(ctime更新)したらそのテキストはmodifiedに
なりadd&commitできましたので、ctimeで判断しているように思えます。

>>630
何いってんの

バイナリだろうがテキストだろうがハッシュはとるでしょ。
ファイルサイズの大小ならともかく、テキストかバイナリかでその辺の挙動を変える意味はないし。

毎回全ファイルのハッシュ計算するわけにもいかないし、タイムスタンプとサイズが一致してたらとりあえず
未変更とみなすっていうのはそれなりに妥当な落としどころだと思う。

ひとりだけ勘違いくんが居るよ

とりあえず差分は無理だからな。丸ごと保存することになる場合が多い

>>633
何いってんの
どのSCMのコード見ての発言なの

ネットワーク越しのクライアント使う場合も、ローカルファイルのメタデータ送ってるって事か？

>>633
毎回全ファイルのタイムスタンプとサイズをやりとりするの？

>>635
svnは内部的にはバイナリファイルも差分で持ってるぜ

これマジか
gitとbzrは怖くて使えんわ

>>633
取らない物が殆ど
仕様をちゃんと読め

タイムスタンプがどうとか言ってる奴はバージョン管理を何だと思ってるの？ｗ

画像なんかのバイナリをバージョン管理に含める人がまだいるんだなぁ。
こういう人達はDBに沢山の画像をつっこむ以上に愚かだわ。

github の画像差分とか見てみろ

古い常識に囚われてはいかん

古い常識つーか今も常識でしょ。
リポが肥大して後で消そうにも消せない問題は未だ健在(出来る物も有るけどね)。
そんな拡張によるニッチな要求を満たした例を上げて「今はバイナリも突っ込むのが常識」なんて言われても説得力がないわい。

ゲームなんかだとバイナリ突っ込むけどなあ。

自分の常識があらゆる場合において普遍と思ってる奴は結構多いからな

ゲーム開発でバージョン管理にバイナリ突っ込む？えっ？
定期的にスナップショットをとるだけだろ…
あぁ同人か…

やっと10年前のレベルに追いついてる土方が沸いたか

>>641
マジで？これは恥ずかしい。
でもGitとBazaarはハッシュ取ってるよね？

>>642
そうは言っても、>>620 に書いてないMercurialも含めて、そういう挙動をしてるからなあ。

ちなみにタイムスタンプって言ってるのは、最後にコミットした時点のタイムスタンプじゃなくて、
ローカルで最初に変更チェックした時のタイムスタンプね。

BazaarとMercurialについては、一回ファイルの変更チェックしたら、サイズかタイムスタンプが変わらない限り再チェックされないようになってるように見える。
Gitは今手元にないから分からん。

見えるとかわからんとか言うぐらいなら一々レスするなって・・・・

git statusやbzr statusでmodifiedってならないだけならいいんだけど･･･
私の環境(Win7pro 32bit、bzr2.4.0、git 1.7.6 mysgit)だと、
ファイル名を指定してcommit(gitの場合はaddでファイル名指定後)も、
できないのが困る。

この現象が、私だけなのか、誰かWindowsでの動作を試してみてくれませんか？

要件上、画像の編集履歴を取りたい＋過去版を参照・取得したい
というのが必須なら、やはりVCSに突っ込むのがベターな選択だと思うよ。

ただその場合は、プログラムコードの管理をメインに開発されたVCSよりは、
Adobe Version Cueのような画像・映像データのアセット管理をメインに据えた
製品を選定するのが良いと思う。……というかそれは板違いの話になるな。


ちなみにウチは帳票定義用のバイナリーファイルをSVNに突っ込んでる。
Excelとか、Wordとか、PDFとか。

バイナリを入れないってのは、機械生成できる実行形式みたいな
のを入れないっていう意味だろ女子高生

>>648
画像データの内容とプログラムの仕様が一致していないとマズいから、
コードとデータを一緒くたにSubversionで管理してるよ。

以前までコードとデータを別々に管理してたけど、
コードだけ更新してデータを更新しないとか、逆のこととかが頻発するんだよね。
特に納期直前にそんな事あったら目も当てられん。

>>655
ディレクトリ、ファイル単位で別々のリビジョンをチェックアウトできるSubversionでは、
その要件は満たさない

>>656
そうなのかな。よく理解できてないけど。

タグくらいつけるだろ
管理できる

>>655
うむ。一番楽だ。重いけどな。

>>656
わかりやすく説明してちょ。

わざと一部だけ違うバージョンのファイルを混ぜてバージョンが一致してないとか言い出す揚げ足取り

>>629
> この手の質疑応答は10年ぐらいから嫌という程みてきたわ
そうなの？何か別の物と勘違いしてない？
今回の問題は「（フォーマット不明の）画像ファイルをSCMで扱うとき、ファイルの日付と
サイズが同じ場合、内容が異なっていてもSCMによっては同一のものと認識する」だよ？
GitやMercurialのFAQに書いてたりするのかな？

>>652
bzrで--unchangedつけてもダメ？

少なくともgitはファイルスタンプなんて見てない
画像はexifを見てるんだろうが、気に入らなきゃ自分で設定出来る

てか、プログラムで扱う画像ファイルにはexifなんか無いのが多いのでは？

>>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もできませんでした。

>>665
gitの場合、.gitattributes ファイルに
*.foo binary
と書いとけば、拡張子.fooファイルはバイナリだと扱われる
これで試すとどうなる？

>>620
OKってどういうこと？
svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
「変更なし」になるんだけど。
変更を検知できないんならNGじゃね？

>>631
gitはパーミッションも管理対象だからじゃね？

>>667
> svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
> 「変更なし」になるんだけど。

まじか
svn使えねー

GitについてLinux(Debian Lanny)とMac OS X(10.6)で確認したら
サイズとctimeが同じでも、中身が違えば変更検知されたのだが

中身を見るなんて無駄な処理は要らない
タイムスタンプを変えないなんてわざとそうているのなら
運用する側が工夫すればよい

>>667
私の環境のTortoiseSVNだと、変更したファイルをクリックして状態を
観ると変更ありになり、コミット可能でした。

>>669
ファイルのみのctimeが同じな場合は、変更が検知されましたが、
その親ディレクトリのctimeを一致させた場合は、だめでしたので、
665ではそのように記述しました。

>>671
.git/ がある親ディレクトリまで含めて、全てのディレクトリとファイルの
ctimeを同じにしたけど、中身が違えば変更が検出されたぞ
どうなってんだ

このスレっていつからVIPになったの？

620は他のVCSに難癖を付けたいだけのSVN厨

http://stackoverflow.com/questions/1778862/how-does-git-detect-that-a-file-has-been-modified

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でも試したがタイムスタンプ一緒だと変更検知できないよ。

サイズの同じ画像ファイル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 してみたら変更が検知されたよ

ごめん、gitは検知した。検知できなかったのはhg。
svn NG
bzr NG
hg NG
git OK

つか file stat関係って、cifs とローカルで微妙に仕様が違ったりするんじゃないっけ？

毎回全ファイルの内容をチェックしてたらステータスの確認に時間がかかるから仕方ない。
変更したファイルはtouchすればいい。

>>680
だなー。内容変えたらタイムスタンプも変えておけってこった

PHPがGitに移行するみたい
ttp://news.php.net/php.internals/55293

変更したファイルをtouchすれば良いだけの話なのに
ぐだぐだと粘着してた奴が
svnも検知できないと分かったとたんパッタリ消えたのが笑えるwww

ていうか、普通変更したらタイムスタンプ変わるよね

待てよ、Mercurialでいいだろ！？

最近sf.netよりgithubなプロジェクト多いな
sf.netだと古くて動かないこと多いし

でも日本語ファイル名あったらsvnの方がいいのになんでgitなんだろ

日本語ファイル名なんてそんなにないんじゃない?

とにかくSourceForgeが使い辛いことにみんなが気づいてきたのが一因にあると思う
用途によってはsvnのほうが良いとしても、githubとSourceForgeには超えられない壁がある

もうVSSでいいじゃん
VSSのどこが気に食わないんだ？

全て

まあリヌース君が「svnは肥溜めの糞の中にあるサナダ虫の糞の中にある細菌の糞」って言っちゃったからなあ

少なくともフリーのバージョン管理システムと言えばCVS、と考えていた時代にリビジョンの概念を導入したSVNの功績は認められるべきだと思うんだが。糞とまで言われるのは使っていた自分としては哀しすぎる。

svnもよいものだったと思うよ。いまだに使われてるのもその証だし
CVSよりイケてるのがほぼsvnだけだった、て時代が長かったてのもあるけど

まあ、より使いやすい(と誰かが考える)ものに変わってくのはなんでも同じ
svnがそこにあって、それが気に入らなかったからLinusもgitつくったわけだし
よくもわるくも、svnがなければhgもbzrも育ってないと思う
だからsvnはよくやった、いままでごくろうさん、て感じかね

俺としては、ファイルシステムレベルでVCSをブチこんでくれないかな、
と前から思ってるんだけど。そういう構想とかないのかなあ

>>693
振り回され過ぎ。ほぼ完璧にUnicode対応
出来てるのは今でもsvnだけだし、
業務に使うのにこれほど信頼できるものも他にない。
リポジトリがネットワーク的に近ければ十分現役。
OSSのリポジトリは遠いからDVCSの速度が必須というだけ。1コミットに数分とかありえないだろ

>>694
Lionだと、全てのドキュメントが自動セーブ＆自動バージョニングされるらしいぞ、知らんけど

>>695
ローカルで履歴弄り放題のgitもいいもんだぞ
Windowsだと未だにsvn一択なのが悲しいが・・・

>>695
> 振り回され過ぎ。ほぼ完璧にUnicode対応
> 出来てるのは今でもsvnだけだし、
> 業務に使うのにこれほど信頼できるものも他にない。
バックアップが無くて全てパー
サーバがクラックされて全てパー

>>698
そう煽るなら上2行は引用しないのが適切

mercurial >>> git

>>696
Windowsにはシャドウコピーがあるね

>>698
バージョン管理システムと関係ないような気が

>ファイルシステムレベルでVCS
TRON

>>698 >>702
Gitならサーバークラックされて顧客情報流出しても平気と聞いて

ジャーナリングファイルシステムの話が出るなら Plan9 が話題に出るべきじゃないの。

LinuxならNILFSだよな

>>703 TRONにはねーよ。
VMSかな。

WebDAVが名前の通りにversioningするのはいつの日か

BitbucketがGitに対応したって、マジすか？

まじすよ。

　

はてなとmixiはgit使ってるんでしょ？

LLVMはGit使ってないよ

なぜ、アホみたいな煽り合いになるのだ？

Q:タイムスタンプが同じだと〜
A:touchする運用でよくね？
で済む話が

信奉者が信じたくない(>>617)とか言い出したり。
そんな使い方が悪い(>>643)とか言い出したり。
使用上正しいと(>>641)とか言い出したり。

その言い争いで何か得るものがあるわけ？
アホ過ぎて分からんわ。

そんな2ヶ月前の話をほじくり返すお前もアホだ

まて、0.025光年先からレスしたのかもしれないんだぞ

>>716
どういう計算だよ。2ヶ月なら1/6年だろ。

計算は分からんが、概念としてどっちなんだろう
1光年みたく1光月という距離の単位があるとして
『1光月の彼方で、1ヶ月後に読み取ってその時書き込んだものがさらに1ヶ月後に我々の目に届く』
のか
『2光月の彼方で、2ヶ月後に読み取ってその時書き込んだものが瞬時に我々の目に届く』
のか、どっちでもないのか

不特定の人がパッチを投げ合いながら開発するオープンソースの開発モデルと
企業内で自分の担当のソースをいくつか修正してcommitする開発モデルではかなり違うキガス

そもそも光年は時間の単位じゃないだろ・・・

>>720
距離だよ。そんなことは常識だ。
光速より速い伝達手段がないから、仮に0.08光年離れたところからレスするなら
往復で0.16光年。即ち58日掛かるだろってこった。
因みに、0.025光年なら高々9日ほどだから往復でも18日。
二ヶ月前の話を穿るにしては中途半端すぎる。

>>716は光回線じゃないんだよ

TCPなんだからパケット１往復でレスできるわけ無いじゃんよ

スレチなのは重々承知だが素朴な疑問が
>>721
「光速より速い伝達手段がない」っていうのは
『とても軽い1光年の長さの棒があったとして、棒の端を押すかひねるかすると
その反対側が動き出すのはどんなに早くても1年後』
になるの？
せーの、で動き始める事にならないから音が水や金属を伝わる速さに差が出るのと
似た話になるんだろうか？？？

物理板でやれ
http://kamome.2ch.net/sci/

ありがとう、そこ行ってみる

スレ汚しすまんかった

テンプレ読んだけどmecurialとGITの一騎打ちでsubversionは論外でOK？
subversion使ってる人多いみたいだけど。

分散型の機能が必要なら論外。
不要なら鉄板。

>>728
集中型だとsubversionが鉄板なのか。どうりで名前をよく聞くわけだ。
どうも有り難う。

>>727
TortoiseSVNなどクライアントの成熟や日本語環境の安心度、集中型であるがゆえのシンプルさなどがSubversionの利点。

分散型は日本語環境が不安なので１人TortoiseSVN

Mercurialは最近ファイル名にUnicodeが使えるようになったらしい
Bazaarは前からUnicode使える
GitはCygwin版とかUTF-8対応msysgitにすればいいがTortoiseGitで文字化けする
Cygwin版GitとCygwin版GitGUIならいいのか？でもあれはTortoiseより使いづらい

だからこの3者で日本語の扱いに問題ありそうなのはGitだけということになった

>>732
> Mercurialは最近ファイル名にUnicodeが使えるようになったらしい
まだなっていない。

Windowsのネイティブ環境(cygwinじゃない環境)でUTF-16が扱えないということで、
それ以外の環境であれば、Unicodeのエンコードの一つUTF-8を扱うのに
MercurialもGitも制約は無い。

Macもいれてやれよ…

>>733
「日本語の扱いに問題がある」ってんだからWindowsのことだよ。
頭悪いな

日本語ファイル名使う時点でクズ

>>736
日本語嫌いな人？？国に帰れば

え？Macも日本語の扱いに問題あるだろ

ありまつけど

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をパワーアップ……岡本 隆史

下のようにレイアウト組んでましたが、表の部分を右にずらそうとmarginを指定しても動いてくれません。
説明文と表と説明文の３つをdivで囲って、表の部分をtable{position:relative;left:20px}とかしたら
理想の通りになったんですけど、考え方としてこれでいいのでしょうか？

┏━━┓説明文
┃ 図　┃表
┃　　　┃説明文
┗━━┛

使い勝手がよいGUIがあるものが一番

>>741 誤爆でした。どうも騒がせて済みません。

いえいえ

>>744
http://hibari.2ch.net/test/read.cgi/tech/1261676778/213
http://hibari.2ch.net/test/read.cgi/tech/1272358443/83
http://hibari.2ch.net/test/read.cgi/tech/1321350331/22
http://hibari.2ch.net/test/read.cgi/tech/1318935200/82
http://hibari.2ch.net/test/read.cgi/tech/1290415962/444
http://hibari.2ch.net/test/read.cgi/tech/1314133332/444
http://hibari.2ch.net/test/read.cgi/tech/1315141054/25
http://hibari.2ch.net/test/read.cgi/tech/1321282584/4
http://hibari.2ch.net/test/read.cgi/tech/1156332916/186
http://hibari.2ch.net/test/read.cgi/tech/1177431417/279
http://hibari.2ch.net/test/read.cgi/tech/1295493964/744
http://hibari.2ch.net/test/read.cgi/tech/1300000513/237
http://hibari.2ch.net/test/read.cgi/tech/1163319215/911

よ

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

私はsvnを続けるよ

僕は Subversion 1.6 を使い続けるよ。

fossil ってのは実際どんなもんだろうかと思って、
バージョン管理ツール総合スレらしきここを覗きにきた。

一言も登場しとらんのな。

fossilは1〜2年に一回くらいの頻度で、バージョン管理系のスレやBTSスレかWIKIスレで見かける気がする。

昔WinMXっていうＰ２Ｐ型のファイル交換ソフトがあったけど、
あんな感じでWindowsにインストールしたらいきなりファイル交換を自動的にし合うような
そんなバージョン管理ソフトはまだ出現しませんかね？

そんな使いにくそうなソフトは、いつまでたっても出現しないと思う。

dropbox

RCSをGUIで表示できるアプリありませんか？

どうしてBazaarって人気ないの？

>>756
GNUだから

>>756
bzr-explorer が中途半端に使いにくい

GNU tla由来のbazaarとCanonicalのbazaarは別モンじゃね?

ぼくはBazaar使ってるんだけど、結構良いと思うんだけど。
subversionから移行して便利だなあって思ってるんだけど。
gitとかhg使ったことないから、そっちのほうがいいのかもしれないけど。

>>757
どうしてGNUだと人気ないの？

>>758
なんか良いGUIクライアントありませんかね。

>>760
あなたがWindowsを使っているのか、Linuxを使っているのかわからないけど
俺はwindows から使っている感想を書く。
SVNの場合TortoiseSVNを使う限り、SVNのコマンドを意識する必要は全く無い。

ところがBazaarの場合、TortoiseBZRにしろBzr-Explorerにしろ、BZRコマンドが
動いているのが見えるし、エラーが起きるとBZRコマンドを実際に打たないと復旧出来ない
場合がたまにある。GUIツールはGUIだけで完結してほしい。
特にWindowsの場合はそうでないと、グループで使うのはちょっと無理。

>>761
たしかに。TortoiseSVNは優れていますね。

hgやgitはWindowsでGUIツールで完結できるものはあるのでしょうか。

>>761
> SVNの場合TortoiseSVNを使う限り、SVNのコマンドを意識する必要は全く無い。
だって、svn.exeが付いてないんだもん。

>>763
最近のTortoiseSVNには付いてるよ。

>>761
Subversionっていうか、TortoiseSVNが優れてるっていう話だね。

うちの会社もSubversion使ってる。
Linuxでコマンドラインだけど。
ファイル数がめちゃめちゃ多いとcoするにもupdateするにも時間もメモリも食い過ぎていい方法か、いいソリューションが無いかと検討中。

SVN、管理ファイル1個になってそのへんマシになったんじゃないの？

開発途中で乗り換えるのは危なすぎるが、次のやつで試してみたいところではある

>>765
そういう場合は本格的にgitを考えたほうがいいかも

TortoiseSVNが優れてるってのは他に比較するものを知らないから優れているって信じているだけではないか？
他のものと比較してとりたてて優れているところはないが。

bazaar は遅い。

>>768
他の物って何？具体的なソフト名を挙げてくれ

>>770
TortoiseCVS

>>768
・Windows上の
・フリーで使える
・GUIの
・バージョン管理ソフト

の中では、やっぱ一番順当に使える完成度じゃなかろかね。
CVSよりはSubversionのが良いし、
かといって、Gitやらhgやらござーるやらにおいては、
今度はtortoiseの完成度が…だし。

ＣＶＳのが優れてるとかはじめてみたわｗ

TortoiseRCSのようなものはありませんか。単体で動くものでもかまいません。

TortoiseCVSはCVSクライアントとしては十分な完成度
CVSとSVNでは出来ることが違うのだからTortoiseCVSとTortoiseSVNを比較しても無意味
TortoiseHgとbzr-explorerはWindowsだけが動作環境では無いので、TortoiseSVNと比較しても無意味
TortoiseGitはgit extensionsという代替がある
TortoiseBzrは世界的に使われているのか疑問

GUIだったらWinCVSが一番良かった。
時点でEclipse。

>>755
RCSではないが、似たようなことをする Visual SouceSafe というものがある。ディスコンに向かってるけど。
GUI で RCS って面倒なだけだよ?

各種分散型にインポートしろ

>>777
そうなんですか。
履歴とかをグラフィカルに見たかったので。

RCSのグラフィカル履歴っていったい…

ラインエディタからスクリーンエディタにすれば、よりグラフィカルに。

板の移動を管理するバージョン管理ソフト

第二の内柴を出さないためのバージン管理ソフト

分散型バージョン管理ソフトって、
簡単に言えばファイル交換ソフトにバージョン管理を組み合わせただけでしょ

Winny にバージョン管理とssh通信付ければ、
最強の分散型バージョン管理ソフトが出来たのに、

↓仁義なきなんとかネタの突っ込み禁止

>>784
マージできんモン送られても困るがな。

履歴ログも閲覧出来んし。

自分用のコミットを勝手に同期されても困る

パッチの順序性をどこで確保するかが難しいな。

あれ？他のすれが消えてる？

移転だってさ

ラピュタ混乱の最中にやらんでも

�d�j

移転していない件orz

ってハード換えたのか

バージョン管理の行き着く先が git なのかな　？

git を本質的に超える バージョン管理はもう現れないのかな？

ｈｇ

>>796
HGが、”本質的”にgitを超えているとは思えないな
多少の機能の違いがあるだけで似たり寄ったりですな

>>797
ファイル名の扱いが構想通りに実現すれば、他のVCSを超越すると思う

>>798
望みが低すぎる

本質ってどういうこと？
どれも思想が異なるわけだが

>>800
gitとhgは思想は一緒。リポジトリへの保存方法とコマンド体系が違うから別物に見えるけど。

妖怪人間bazaar が　hg のような普通の人間になろうとしているのが痛い

>>800
思想がちがうのはdarcsだけ

>>798
gitが優れてる部分が多いことは間違いないんだけど、
バイナリを頻繁に扱わなくちゃならない環境にとってはgitじゃ駄目なんだよなぁ

>>804
バイナリが得意なVCSってなに？

>>805
Mercurial 2.0リリース、バックポートに有用な「graft」コマンドや
サイズの大きいバイナリファイルを効率よく扱う拡張などが導入される
http://sourceforge.jp/magazine/11/11/04/0354255

>>806
それは単に実体を共有したりするだけだろ。そんなもんgitならデフォだ。
そして頻繁にバイナリの変更があるようなのはどっちもダメだ。

svnならバイナリも差分で格納してくれる。

>>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

bazaarのバイナリの扱いはどうなっていますか

hgの新機能についてはよく知らないけど、gitもpackすれば
バイナリに限らず差分形式になる

巨大なバイナリを扱おうとするとgitもbzrも大量のメモリーを使用した。
この点はsvnが優れている。hgは試してない。

・何をした？
・OSは？
・メモリのキャッシュに残ってただけでは？

svnと分散型を比較するのなら、svnのサーバも比較してね

いずれもMicrosoft Windows XPで比較。タスクマネージャーの仮想メモリ量
で見た。
1.7GBくらいのファイル1個をコミットしてみた。
hgはファイルサイズくらいのメモリーを消費した。
bzrはファイルサイズの倍(もっとかも)のメモリーを消費した。
svnは数百メガバイトくらい。
svnはサーバーを使わずローカルのファイルシステム上にSVNROOTを設定した。
ただしbzrをテストしたのはだいぶ前なので改良されてるかも。

>>814
仮想メモリ量じゃなかったかも。手元にXPがないんですまん。

ユーザモードのアドレス空間は2GBしかないのに3.4GB消費したの？

bzrはだいぶ前だったから記憶があいまい。っていうか人のテストにケチをつける
前に自分でやってみればいいのに。

>>811>>814
gitとhgのどっちを試したのか分からん

>>818
すまん。gitとbzrとsvnだった。

>>817
テスト内容が非現実的。svnでサーバーを使わない目的が不明。

>>820
だから誰でも簡単にできるテストなんだから、好きにテストすればいい。

>>821
svnが優位というのは根拠が無いでOK？

>>822
好きにしたら?
誰かの参考になるかと思って単にテスト結果を並べただけだよ。
svnを応援する気なんてない。実際svn使ってないし。

SubversionとMercurial使っている人に聞きたい。
理論的な上限じゃ無くて、実運用的な作業フォルダのサイズってどの程度にしている？

なんか、直ぐにファイル無くしたとか、上書きしたとか削除したとか言い出す人がいて、
管理フォルダまとめて管理してしまおうかと。でも、6.5GBで、ファイル数38,000くらいあるんだ。
さすがにこれをひとまとめは無茶だよね。Windows環境でファイルサーバー的にしか使ってない。

バージョン管理ソフト使うよりはファイルの書き換え毎にバックアップで戻るソフトさがした方が良いか。
そんなのあるのか知らないけど。

バージョン管理とは別にpdumpfsでも走らせとけばいいんじゃねーの

>>824
Subversionはディレクトリ（フォルダ）単位でチェックアウトできる。
Mercurialはサブリポジトリという機能がある。

バージョン管理ソフトの欠点は
使い方を理解している人が明示的に使わない限りは
全く機能しないってところだな

>824
WindowsのMercurialで、ファイル数2万ぐらいの画像ファイルの管理をした時の不満点は、
・TortoiseHGのパフォーマンス劣化が酷い
・上位のディレクトリ名を変更したら、ファイル追加と同じぐらい激しくリポジトリ肥大
・addのcommit中に共有違反で読めないファイルがあった時、リポジトリがぶっ壊れた

特に最後の奴が痛かった。常識的に考えて、エラーならアトミックにロールバックしろよ。

ごめんなさい

リポジトリ破壊とかﾋﾄﾞｽｗ

だからリポジトリをバージョン管理しておけって言ったのに…

>>828
Mercurialって最近largefile拡張とかサポートしてたキガス

>>824
そのくらいなら実際に開発してた。
ディレクトリの切り方がまともなら十分可能。
常にその数を相手にするのはきついなあ。

>>817
ケチつけられるのが嫌ならいい加減なこと書かなきゃいいのに。

>>834
いい加減だったのは謝る。でも誰もsvnサーバーで巨大ファイルのテストを
してないのにケチだけつけるのは驚きだ。

見事なお子様反応。
「ぼく悪くないもん！」

テストになってないし無意味だからなｗ

>>835
お前2chは初めてか？力抜けよ。

テストしてみた。1.4GBのzipファイルをコミットしてみた。
ローカルファイルシステムを使った場合 → svn.exe が約10MB使用
svnserveを使った場合 → svnserve.exe が約10MB、svn.exe が約8MB使用
ファイルの最後にわずかな変更を加えて再コミットした場合も同様だった。

>>839
svnのバージョンは？
1.6と1.7ではクライアントは全く違う。

>>840
たまたまはいってた古い1.5.2でやった。何でやればいい?

>>841
1.7

>>842
VisualSVNのコマンドラインツールでやった。サーバー、クライアントとも1.7.2。
1回めのコミット→サーバー20MB、クライアント5.5MB
2回目のコミット→サーバー20MB、クライアント5MB
使ったファイル→Jazz RationalTeamConcert3.01配布ファイルのzip 1.4GB
2回めのコミットの前に「echo a >> ファイル」でファイルに内容を追加した。

Git、Eclipse.orgでCVS、SVNを超える
http://www.infoq.com/jp/news/2011/12/eclipse-git

時代はgitだな。

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

>>844
この著者はgithubが言いたいだけなんじゃないか。
Atlassianに買収される前のbitbucketは頻繁にサーバが落ちていたけど、
最近はほとんど無くなった。
機能もどんどん多くなってきている。githubとほとんど変わらない。
容量制限無し、プライベートリポジトリ、git/hg両方対応と、bitbucketの方が利便性が高い。
個人では公開はgithub、プライベートはbitbucketと使い分けているのが多い。
今後、githubからbitbucketに移動するプロジェクトも増えるのではないか。

どうしてbazaarちゃんを無視するの

>>848
Atlassianに聞いて

ファイラーなに使ってますの？

分散バージョン管理システムの詳細なガイド
投稿日 2010年2月21日
http://www.infoq.com/jp/articles/dvcs-guide

> 最初の頃パフォーマンスが悪かったため、Bazaarは周囲に影響を与える多くの
> 早期採用者(MozillaやSolaris、OpenJDK)を失いました。

Bazaarって遅いのかよｗ

大量のバイナリファイルを多くのユーザーで編集する環境で
git選択しにくいのはパフォーマンス云々よりlock出来ないのが痛い。

そんなわけで一定以上のリソースがある場合はPerforce
そうじゃないときはsvnって選択になっちゃってる。

適材適所でいいんじゃない？

>>853
その適材適所にみんな悩んでいるんだと思うが
いくら適材適所でも3も4も管理システム導入とか非現実的だし

>>852
つ>>397

>>397はリンク切れで新しいリンク
http://mercurial.selenic.com/wiki/LockExtension
Mercurialの主要コミッタ作なんで品質は大丈夫だろう

アイコンのビットマップ程度ならばともかく、ソースコード対象にしている版管理ソフトに巨大バイナリ管理を求めるのは間違っている。

>>857
これまでは

> ソースコード対象にしている

だったけど、今後

> 巨大バイナリ管理を求める

ってことで、ツールも対応してくれって言うことでしょ。

Subversion なんかじゃフツーにバイナリ管理するけど
git/Mercurial じゃできないのプププのプー
って話にならね?

>>859
Mercurialは、largefile extensionとlock extensionがあるとこのスレにあるのが見えない盲目？

>>860
話の流れも見えない馬鹿?

>>861
Mercurialは巨大バイナリも、ワード・エクセルなどを想定したロックも、両方対応しているってのが分からない馬鹿？

>>862
たぶん859は857に対してレスしてるんじゃね？

svnのバイナリ管理も程度に依るよな。
ゲームのグラフィクスなどの大型、大量バイナリを突っ込むと実用性に問題が出るほど重くなる。
Perforceはマシみたいだけど。

だねえ。
10G 前後ならまあ、なんとかなるけど、数倍になるとアウトだよ!
Perforce だとイケる? 桁上がったくらいはどう?

>>865
>Perforce だとイケる? 桁上がったくらいはどう?

評価版があるみたいだから、試してみれば？
http://www.toyo.co.jp/ss/perforce/download_soft_2010.2.html

自分ならバイナリの容量が1Gを超えるならsvnなりコード用のバージョンコントロールは使用しないがな。

とりあえずお前の内臓が破裂するぐらいのボディブローは出せるがな（笑

>>868
そのボディブローでVSSを抹殺してください

まだ使ってるとこあるのか

フリーソフトは駄目ってところが未だに多いからな。

>>868
うは〜、腹いてー（笑）

要はGitHub日本法人(仮)とかが有料サポートすればいいんだな？

安心と信頼のCanonical印のBazaarをお使い下さい

始まる前から終わってた

>>873
git技術者検定とかやりそうだなｗ

>>874
Bazaarはマジでこのままだとジリ貧だろ
Linux関連の開発で使う限りではgitの方が使っているプロジェクトも技術者も多いし

Bazaarは今のバージョンで打ち止めして、新規に再設計した方が良いと思うわ

>>870
>まだ使ってるとこあるのか

あるよ〜、って言うかそこそこの規模だとなかなか入れ替えられない。

VSSとBazaarの究極の組み合わせ
http://d.hatena.ne.jp/wonderful_panda/20111212/1323643703

自分のまわりにいないってだけで、書籍、Webドキュメント、記事、
膨大なOSSプロジェクトといっぱいありますが？

https://twitter.com/#!/methane/status/148328106841751552
> git へ移行する最大の障壁は、「gitのことならなんでも訊いて！」という人がいないこと。
> バージョン管理システムのワークフローの構築とかはこう言った先導者が必要。
> bzrは問題あったらぼくがなんでも解決できてたけど、gitはぼくが教えて欲しいくらいだしな。

>>880
この人は何者？

>>881
このスレの前半を見よう。
Bazaarの泥舟から脱出を検討している亡命予備者

BitKeeperってバイナリ管理どうなん

>>880
methaneさんは社内の人員のことを言ってると思うよ。
業務で使う場合、社内に強力に推進できる人がいないと結構大変だよね。

https://twitter.com/#!/methane/status/148657202620661760
今でも一応3つとも使ってますが、会社ではbzrを使うメリットがあまりないので、git, hg への移行を考え中。

[Bazaar]Git, Git, Git. たまに違うのが聞こえればHg. なぜこの俺を認めねぇ

Bazaar さん遅いですやん

最近は速いです

リポジトリをXMLで保持して相互乗り入れできるようにすれば全て解決。

>>889
XMLなんか使わなくても、git-svn/hgsubversion/hg-gitで相互乗り入れできる
bazaarはクソだからbzr-svn以外ダメダメだけど

>>867
その場合は専用のバージョン管理ソフト使ってるってこと？
エイリアンブレインとか？

今のプロジェクトだと画像その他のリソースが30Gくらいあるんだが、
その管理どうするかでかなり悩んでるんで、どうしてるのか聞いてみたい。

>>891
うちの職場だと、独自インフラツールを作って運用している。

話としては、Perforceとかエイリアンブレインあたりを耳にするね。

VSSが陥落したぞ
http://twitter.com/#!/msdnjp/status/149414774063628288

どうせだれも使わない

っていうかとっくに死んでるものだとばかり……

とっくに死んでるプロダクトが御輿に担がれるのは現場でまれによくある。特にMS。

今移行中ですっ＞＜；

TFSは何か操作するたびにSQLServerがもりもりメモリーを食うのが泣ける。
リソースガバナー設定するしかないのかなぁ、アレなんか面倒そうだなぁ……
TFSを入れるなら多少でもSQLServerの知識がないとダメそうなのがつらい。

今さらサーバーレスなVSSに戻るつもりはないけど、運用の難易度が高いのがネックだね。

TFSとはまた棘の道を。
svnにしとけばあとでgitにでもhgにでも行けるのに

俺が今やってる現場もほとんどUNIX+Javaの開発しかやってないのに
なぜかめでたくSubversionからTFSに移行したよ
アホが発言力持つとロクなことにならん…

TFSって何なのか分かんなかったらggって分かった。
MSが、VSS殺して作った新しい奴なのね。

見た感じ管理者がExcelで管理したいが為に作られてるのか。
使い勝手が開発者視点じゃないんだろうな……

TFSとはまた棘の道を。
svnにしとけばあとでgitにでもhgにでも行けるのに

TFSって結構金がかかるイメージがあるんだが、実際どうなんだろうな

TFS??
Macとかlinuxとか使ってる人どうするんですか？死ぬの？

MicrosoftからEclipse用のTFSプラグインが公開されてるから
MacやLinuxからでも一応利用はできるよ。
ただしプラグイン自体の出来は微妙。
ぶっちゃけ親切心じゃなくて嫌がらせで公開してるんじゃないかと思う。

>>904
>ぶっちゃけ親切心じゃなくて

内容はよくわかってないけど投資を承認する、偉い人を説得するためだろ。

偉い人にはわからんのですよ

テストやらビルドが１パッケになってるのはウケがよさそうではあるが…、
MSの作るものだから、どうせダイアログ出したままフリーズするんだろうなぁ

msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！
http://d.hatena.ne.jp/nitoyon/20120221/msysgit_utf8

日本語ファイル名問題が解決したから、もう高速なGitを選ばない理由はありません。
これで日本でも次期デファクトスタンダードVCSはGitに確定ですね。

宗教上の理由かなんかで意地でもやらないと思ってたけど
ようやくWindowsでも普通に日本語ファイル名が使えるようになるのか。

絶対やってほしくなかったな

# つか、開発部隊の半数以上が欧米の連中なのにも関わらず
# 日本語ファイル名をつけるのはやめれ >某社の某プロジェクトの下っぱ

30年前に「Unicodeは糞」って言ってた奴を思い出したｗ

ソースはともかくドキュメント類は日本語のファイル名が普通だし
それらがソースと一緒に管理できるのはいいことなのかな
Gitがドキュメント管理に向いてるのかという問題は置いといて。

もしかしてMercurialから移行しても良いの？!
がっかり感が半端ないとか言わないよね

>>913
Mercurialはfixutf8が先にあったから、今回のmsysgitはそれに追いついた。
Mercurialもfixutf8の機能を公式にするという動きがある。
これで問題になっているのは、過去のリビジョンをcheckoutできなくなること。
fixutf8では移行時にhg addremoveを使いましょうということになっていて、
fixutf8を無効・有効を切り替えればその時点のリビジョンのチェックアウトはできる。
今回のmsysgitがそこまで考えているか疑問。

ファイルのタイムスタンプを保持できるバージョン管理システムありませんか(´・ω・｀)

>>915
チェックアウトなりエクスポートなりしたファイルのタイムスタンプを
コミット時のそれにしたいってこと?

なんでまたそんな不便なことを……

>>916
そう思うのはGitに慣れ切った証拠だね

いや、Gitは使ったことはおろか、インストールしたこともないんだが。

>>918
タイムスタンプなど不要って思ったのはなんで？

>>917
普通に考えれば、古いコミットに戻してmake、ができなくなるのは不便だろうな。
cvsでもsvnでもgitでもhgでも同じ。

ところが、subversionではファイルのタイムスタンプをコミット時刻にするオプションが用意されてるんだよ。

>>921
へえ。逆(co時にコミット時間をタイムスタンプに設定する)ができるのは知ってたが。

え？逆じゃなくて、co時にファイルのタイムスタンプをコミット時刻にできるということなんだが。

…ごめんなさいすごくボケてました。

>>921
へぇ、そりゃWindowsｗの人が喜びそうだ。

OS関係あんの？

・makeみたいなツールがないからタイムスタンプが更新されている必要がない。
・しばしばタイムスタンプありきでファイル管理を行なっている。
・タイムスタンプが変わっていると天地が引っ繰り返ったように大騒ぎをする人がいる。
こんなところか?w

>>927
> ・makeみたいなツールがないからタイムスタンプが更新されている必要がない。

はぁ？どんだけ物知らないんだよ

しっくりこないんです！

Windowsの人ってなんでバッチファイルでやるの
バッチファイルを日本語のファイル名でわけわかんない名前にしたりとか

>>928
それじゃ物識りの人が教えてくれまいか。

すいません。忙しくて時間がたちました。

>>916
ファイルのタイムスタンプで管理されていて、
それを変えて出すと怒られるんです(´・ω・｀)
バージョン管理とかされてなくて、ぼくは個人的に使っていたのです。

>>927
その通りです。タイムスタンプで管理されていて、変えると偉い人が有頂天になります。

>>921-923
それができるのですね。調べてみます。
ぼくは今、分散バージョン管理に興味を持っていて、そのどれかでできればいいなあと思ってたのですが。
いまのところ、Subversionだけなんですね。

>>930
本当はもっと便利なスクリプト言語を使いたいのですが、
どのバージョンのWindowsでも特別なインストールや設定なしに普遍的にあるのがそれそかないんです(´・ω・｀)
管理で何かちょっとしたことをやろうと思うとそれしかないんです。

ぼくは日本語のファイル名は使いません(´・ω・｀)

WSH使えば

>>932
あ、はい。

それとPowerShellも考えたのですが、比較的新しめのWindowsにしか乗ってないのと、
デフォルトで乗ってるやつでも、スクリプトの実行を許可する設定にしないと動かないんです(´・ω・｀)

バージョン管理とレス違いですいません。

そこまでインストールや設定変更を嫌うのにバージョン管理システムのインストールは許容するのか?
まとめてインストールすりゃいいだろ

>>936
いや、すいません。バッチファイルの話は乗っかっただけで、別の仕事の話です(´・ω・｀)
バージョン管理は今の仕事のお話です。

>>935
実行ポリシーについて言えば、起動オプションで
-ExcutionPolicyに好きな値設定すればどうとでもなるよ(管理者権限不要)

>>932
946 名前：デフォルトの名無しさん [sage]： 2011/11/02(水) 19:25:52.78
TortoiseHGを最近使いだして、その使い勝手に感激しています。
そこで質問なんですが、ファイルの更新日時も管理対象にすることはできないのでしょうか？

特定のリビジョンへ更新した際に、更新日時もそのときのものに変更されれば
最高なんですが。


947 名前：デフォルトの名無しさん [sage]： 2011/11/02(水) 19:40:30.94
>>946
タイムスタンプ更新是非については総合スレの話題として、
それらしき拡張はあるようだ。
http://mercurial.selenic.com/wiki/UsingExtensions
http://mercurial.selenic.com/wiki/TimestampExtension
http://mercurial.selenic.com/wiki/TimestampModExtension


948 名前：デフォルトの名無しさん [sage]： 2011/11/02(水) 21:58:54.77
>>947
TimestampModExtension
これ使ってみました。
手間いらずでバッチリ希望通りの動きをしているようです。
どうもありがとうございました。

Windows 7 + Visual Studio 2010 の環境でSubversionを使用して一人で
開発しているのですが、一人作業でもSubversionから分散型に移行する
利点ってあります？
一人での作業だと分散型にする意味あまりなし？

>>940
一人でさらにtrunk一本（ブランチを作らない）であれば、Subversionのままでも構わないだろう

>>940
複数拠点で作業するなら、分散型の方が何かと好都合だぞ。

>>941-942
レスありがとうございます。

リリース用にブランチ切って、リリースするタイミングでタグ付けして、リリース後はブランチは保守用として残すという
のと、たまーに実験機能用のブランチを切るというような一般的な使い方ですが、ブランチは使用しております。
このブランチの運用方法でいくと、ブランチの考え方が違うMercurialは無しですかね。
(運用方法を変えればいいという話もあるが・・・)

どうも家で一人で作業している場合、コミットの回数が1回多くなる(マスターへの反映)という手間が増えるだけでは・・・
とか考えてしまう。
速度的には自分のPCで鯖立ててる状態なので、分散型に変えても有利になるわけでもないですよね。

でも確かに、ノートPC持って外出するときとかは、マスターからノートPCのリポジトリに落としてコーディングして、
気が向いたときにマスターに反映させるとかいうのは楽でいい気もする・・・。

そもそもこのスレに来た経緯ですが・・・

(1)「msysGitがUTF-8をサポート」という記事を見て、分散型が気になり出す。
(2)分散型について調べて、いろいろと分散型の利点を学習。
　 その課程でGitの管理ファイル(.git)はルートディレクトリだけに置かれることを知る。
(3)Subversionの管理ファイル(.svn)が各ディレクトリにあることに若干嫌気がさしていた
　 ということもあり・・・Gitおいしいです（＾ｑ＾）。
(4)Subversionも1.7から管理ファイルが一つになったことを知る(現状、Subversion1.6を使っています･･･)。
(5)あれ、一人で作業するならSubversionを1.7にアップデートでよくね？
(6)いや、でも一人で作業する場合でも分散型にする利点あるのでは・・・。　←いまここ

というわけで、Subversionから分散型に移行しようとした動機がかなり不純であったので、
一人作業での利点を色々考えたのですがしっくりこないということもあり質問した次第です。
(いい機会なので、分散型に移行しようかなという気分にですが、どうも最後の一押しが･･･)

>>944
＞(4)Subversionも1.7から管理ファイルが一つになったことを知る
それは知らなかった。今度試してみよう。(git から乗り換える気はないけどね。)

>>943
> このブランチの運用方法でいくと、ブランチの考え方が違うMercurialは無しですかね。
この運用方法だとMercurialの「名前付きブランチ」の方がしっくりくる。
Gitのブランチの方が違和感が大きい。

ここで bzr と言ってみるテスト

>>944
別にsvnでもcsvでも分散は出来るんだが。。
分散型の利点は、実は分散でなはいという実感。

svnから見てgitやhgの一番嬉しい点は、amendなりrollbackなりできることだと思ううっかり屋の俺。
分散自体はsvnsyncなりsvkでもできるし、ワーキングコピーと同じディレクトリにリポジトリ本体を置く分散型よりsvnスタイルのほうが安心な気はする。

むしろ、ひとりで開発するときに分散型が向いてるとおもうけどね。

軽いし、サーバー立てなくてもいいし、実験用ならブランチしなくても丸ごと
cloneしちゃえばいいし。

svn は 1.7 でけっこう良くなったんだけど、まだ周辺ツールが
ついてきてない感じ……

ここでbzrリポジトリをUSBメモリに入れて持ち歩いている私が颯爽と登場。
え? お呼びでない? こりゃまた失礼いたしました。

>>どうも家で一人で作業している場合、コミットの回数が1回多くなる(マスターへの反映)という手間が増えるだけでは・・・
その使い方ならわざわざマスターを別に作る必要がないんじゃない？
好きに履歴を改ざんできる気持ちよさ（手軽さ・気楽さ）に慣れるとsvnには戻れないな

調べたなら知ってるとは思うが、使ったことないとイメージしにくいかもしれないので一応補足
Git を例にとると、ルートディレクトリにしたい場所で「git init」で .git ディレクトリができる
これが管理ディレクトリでもありリポジトリそのものでもある
ノートPC持って外出するならそこからcloneして、帰ったらpushすればいい

みなさまレスありがとうござます。

>>946
以下のページを見てみると
ttp://keijinsonyaban.blogspot.com/2010/10/successful-git-branching-model.html
Subversionの「タグ・リリース用ブランチ・実験用ブランチ・トランク」が、
Gitの「master・release + hotfix・feature・develop」ブランチにそれぞれ該当するという
ことになり、運用の考え方は同じになるのかなと思いまして。
(いや、そもそも作業ごとに全部ブランチを作って不要になったらブランチを消すという
運用が「ブランチの考え方」という点においてはSubversionとは全然違うところか)

Mercurialだと無名ブランチという物が存在して、ブランチ自体の考え方が違うのかと
考えてしまったのですが、むしろ基本的にはSubversionと考え方は同じで、さらに気軽
にブランチを切れるという感じでしょうか
Mercurialのブランチやタグの運用指標が書かれているページなどあれば教えて
いただけたら幸いです(探したが見つからず・・・)。

>>947 >>951
Bazaarは情報が少ないのが何とも。分散型で検索してみると、ほとんどGitの情報で、
たまにMercurial、さらにたまにBazaarが出てくる感じですよね・・・。

>>948-950
CVSやSubversionよりも後発ということで、分散型を導入することで分散型とは関係ない
部分の利点の恩恵も受けられると。コミットした後に修正もれに気付いて再コミットでログ
が汚れるということが日常茶飯事なのでamendやrollbackはたしかに良いと思いました。

> 軽いし、サーバー立てなくてもいいし、実験用ならブランチしなくても丸ごと
> cloneしちゃえばいいし。
サーバー立てなくてもよいってのはリポジトリにfile://を指定できるSubversionでも同じでは
ないでしょうか？(そういう意味ではない？)

実験用ならその運用というのはなるほど納得。無駄なブランチができなくて良いですね。

>>954
Mercurial Advent Calendar 2011
http://partake.in/events/902cd6d9-0215-4ea3-b51f-b8ff32e56426
あるプロジェクトのMercurial導入の軌跡
http://d.hatena.ne.jp/troter/20111225/1324823716

タダなんだからとりあえず試せよ

>>952-953
> その使い方ならわざわざマスターを別に作る必要がないんじゃない？
なるほど。あくまでも複数人で作業する場合に成果物を共有するためにマスターリポジトリを
作成する必要があるわけであって、一人作業の場合はローカルリポジトリ自体がまさにマスター
リポジトリと考えればいいわけで、そこで作業してる分にはわざわざpush/pullの必要がないと。

> Git を例にとると、ルートディレクトリにしたい場所で「git init」で .git ディレクトリができる
> これが管理ディレクトリでもありリポジトリそのものでもある
DropBoxにリポジトリを置く運用をしているので、リポジトリは作業しているディレクトリとは別に
あった方がうれしいですが、たとえばGitだと「git --bare init」で可能みたいですね。


それにしても、このスレの住人は優しいですね。
一人作業でも利点が多いということが十分理解できました。
みなさま最後の一押しありがとうございます！
GitとMercurialの両方で仮運用してみて、気に入った方を使ってみようと思います。

>>956
THX。これはわかりやすい。

>>957
いや、まったくおっしゃる通り。ちょっと仮運用してみます。

>>951
かつての俺ガイル
USB メモリなくして涙目になって
dropbox に置くようになった

仕事関係では mercurial 使ってて、
個人では bazaar 使ってる

ブランチの使い方が両者で全然違うので
ツールが違えば運用ルールも変わる的な
面倒くささがうざい

>>958
リポジトリを別に置くのは--separate-git-dirでないかな。
--bareはサーバー用にワーキングディレクトリを使わない宣言だった希ガス

GitHubに脆弱性、第三者が権限のないリポジトリへのアクセス権を取得可能
ttp://slashdot.jp/

insiderman 曰く、
3月4日、GitHubに脆弱性が発見された（GitHubのブログ）。同日中に問題は修正され、現在これによる影響をチェックしているとのこと。

この問題は、GitHubが使っているRuby on Railsに含まれていたMass assignmentという脆弱性を使ったもので、
実例としてこれを用いて不正な日付でIssueを登録したり、本来なら登録する権限がないSSH公開鍵の登録が行われていた模様。
これはRuby on Railsの問題であり、Issueで議論が行われている。

Ruby on Rails側の問題ということで、Ruby on Railsを使っているほかのサイトでも同様の問題が発生する可能性があるようだ

>>958
ぼくはSubversionからBazaarに乗り換えたよ。
Bazaarも試してみてね。

Subversionでもサーバ立てずに使えるよね。
ファイルで。

使えるといえば使えるけど、結局サーバー立てるのに比べて
あまり簡単にならないんだよね。単にプロトコルが file://
になっただけというか。

まずリポジトリを作らなければならないし、
import したあとに作業コピーを作る必要があるし、
リポジトリと作業コピーを別々に管理する必要があるし……

>>954
svnのあれがgitの場合これとか、gitのあれがhgのこれとか、そういう考え方だとはまるよ。
とっかかりとしては、いいかもしれんが。。

>>960
私は逆に、ネットから切り離されている(客先の)環境でも使えるようにUSBメモリを使っている。
# このUSBメモリは更にTrueCryptで暗号化されているから紛失しても大事には至らない想定。
私物は、DropBoxだけどね。

githubを使い、自分で使っているスクリプトtool.rbを公開したいです。
ですが、スクリプト内に（Web APIを使うための）IDとパスワードが含まれています。
よって以下の様にファイルを分離し、私のIDとPASSが記録されているconfig.rbは.gitignoreで無視しようと思いました。
- tool.rb（スクリプト本体）
- config.default.rb（設定ファイルの雛形）
- config.rb（私が使っている設定ファイル）
ですが、tool.rbでconfig.rbをrequireしている場合、ユーザにこのスクリプトを使ってもらうには
config.default.rbをconfig.rbにリネームして貰わなければなりません。
このリネームの手間を無くしたいのですが、どのようにするのが一番良いでしょうか？
アドバイス頂けると嬉しいです _ _

IDとパスワードをスクリプトに埋め込むのをやめて、ふつーにドットファイルなりレジストリなり使うようにすればいいんじゃね？

ruby スクリプトでは pit を使ってるなぁ。

>>968
環境変数やコマンドライン引数で設定ファイルの位置を指定できるようにして、
自分の環境ではそれらを指定して、自分用の設定ファイルを使うに一票。

設定ファイルを.rbにするからいけないんだろ
xmlなりjsonなりの形式にしてconfig.xmlが存在しなければ
config.default.xmlをconfig.xmlにコピーしてから読むようにtool.rbを書けよ

つかバージョン管理は全く関係ねー

管理しやすいように設計するって話なんだから関係はしてるでしょ

>>972
設定ファイルがなければコピーするのはそれでいいと思うが、
その３つのなかじゃ、セキュリティの問題がなければ、
設定ファイルとしては、.rbファイルが一番使いやすいよ。
特にxml は、誰にもメリットがない。xmlは、早く絶滅すべきフォーマット。

XMLは手編集する設定ファイルに向いてないのは同意だが、
マークアップランゲージとしては柔軟で強力だと思う

.

CodePlex、Gitサポートを開始
http://sourceforge.jp/magazine/12/03/26/0529214

　米Microsoftは3月21日、オープンソースソフトウェア向けの
ホスティングサービス「CodePlex」でGitをサポートすることを発表した。
これにより開発者は、Microsoft Team Foundation Server（TFS）、Subversion、
Mercurial、Gitからバージョン管理システムを選択できるようになる

>>944

Subversion、TortoseSVNつかってるなら、普通にアップデートして
作業コピーもアップデート適用すれば、すぐに変更適用できるよ。

あまりに量が多いと大変だろうけど、便利になった。

Gitってリポジトリへのcdが必須のbash厨にありがちな使い方になっちゃうね。

日本語でおk

bash厨って言ってみたかっただけだろw

覚えたての言葉を使ってみたい年頃

次スレ立てときました

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/