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

1 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:26:04 ] バージョン管理システムについて語りましょう ●過去スレ バージョン管理システムについて語るスレ pc11.2ch.net/test/read.cgi/tech/1193332500/ バージョン管理システムについて語るスレ2 pc11.2ch.net/test/read.cgi/tech/1215520728/ バージョン管理システムについて語るスレ3 pc12.2ch.net/test/read.cgi/tech/1228366972/ バージョン管理システムについて語るスレ4 pc12.2ch.net/test/read.cgi/tech/1242918130/ バージョン管理システムについて語るスレ5 pc12.2ch.net/test/read.cgi/tech/1255241922/ バージョン管理システムについて語るスレ6 hibari.2ch.net/test/read.cgi/tech/1270640436/ バージョン管理システムについて語るスレ7 hibari.2ch.net/test/read.cgi/tech/1283780922/ 237 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:13:01.59 ] そもそも、utf-8 vs utf-16 じゃなくて utf-8 or utf-32 vs utf-16 という 話だったと思うんだが。 utf-8 : utf-16 = 1:1.1〜2 utf-16 : utf-32 = 1:1.9〜2 つまり、utf-8とutf-16の効率の差よりも、utf-16とutf-32の差のほうが大きい。 utf-8 < utf-16 << utf-32 utf-8 と utf-16 の差をみてutf-16が非効率だと言うなら、utf-32はもっと 使いものにならない。 238 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:16:53.52 ] >>237 >>224 ダブスタ乙 それは都合の悪い時にもっと都合の悪い方を dis って誤摩化してるだけだろ 239 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:18:52.01 ] >>238 utf-16の非効率を指摘しながらutf-32はOKという自分のほうがダブスタ だっていう認識はないんだな。。。 240 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:20:38.04 ] 横からごめんよ。 よく分からんが、ここで争ってる文字コードは、どこで使う文字コード？ バージョン管理システム内だけで使う文字コードじゃないの？ それとも、各開発環境で使用してる文字コードを、 バージョン管理システムでは、わざわざ変換して保存するとかの話？ 241 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:21:53.26 ] >>240 なんか内部エンコーディングと外部エンコーディングの区別もつかない奴が 暴れてるだけ。どの部分の文字コードの話とか全然話題になってない。 242 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:23:17.21 ] >>239 俺は UTF-8 の方が効率的だという話しかしていない。 君が勝手に UTF-32 と比較して UTF-16 を擁護しようとしているだけ。 当然 UTF-8 に対しては何の反論にもなっていない。 UTF-32 を採用する事があるとすれば、それは効率ではなく別の理由。 243 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:25:05.29 ] >>240 >バージョン管理システム内だけで使う文字コードじゃないの？ つ >>164 244 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:25:40.70 ] >>242 この議論はそもそも >>210 から始まったんだが。。。 UTF-16 を採用することがあるとすれば、それは効率と扱いやすさのバランス。 245 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:25:56.41 ] >>241 ふーん バージョン管理システム内で使う文字コード(ログとか)なら、 開発環境に合わせて、好きな文字コード選べた方が良いし、 開発環境で使用してる文字コードを、変換して保存するとか トラブルの元にしかならないからやめて欲しいのは俺だけか？ 246 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:28:47.22 ] >>244 効率も悪いし、サロゲートペアが必須で扱い辛い文字コード乙 247 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:29:23.71 ] >>243 あーなるほどね。 そう言う話なら、ぶっちゃけどうでも良いや。 248 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:30:07.68 ] >>247 そう、ぶっちゃけどうでも良いのです。 249 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:30:08.18 ] つまり、ファイル名をunicodeで扱うかバイト列で扱うかという話に、 何故か今までWindows APIがUTF-16という点でしか登場する機会のなかった UTF-16をdisり始めた >>210 が現れて、スルーできずにUTF-16の利点を 説明しだす奴が現れて、さらに何故かUTF-16がUTF-8より優れているという 議論をしていると勘違いしてる奴が現れた。 250 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:32:09.41 ] >>249 そして今、君が颯爽と現れてこれからこのスレを有意義な話題で盛り上げてくれる訳だ。 251 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:32:49.71 ] >>246 効率: UTF-8 < UTF-16 << UTF-32 処理しやすさ: UTF-32 < UTF-16 << UTF-8 効率と処理しやすさのどっちか片方しか必要ない場合は君の言うとおり。 どっちも必要な場合はバランスが良いフォーマット。 252 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:36:34.42 ] ファイル名なんて、システム依存なんだから、 文字コードを考えたって意味ないじゃん むしろ、そのシステムで使えないファイル名を付ける奴が悪いってことじゃなくて？ 253 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 03:39:34.62 ] >>251 結局、固定長を前提に出来ない時点で UTF-16 に処理し易さなんて無いよ UTF-8 が ascii の範囲では固定長だから処理がし易いと言ってるのと同じ 254 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 04:02:39.82 ] utf8もutf16もutf32もサロゲートペア使って表せる範囲は全て同じでしょ？ 基本的に処理なんて、変換位しかないし、一回書けば終わりなんだから 処理のしやすさなんて考えても意味ないじゃんって、突っ込んだら負けなの？ あと、変換とかで考えるとコードセパレート問題とか考える方が余程頭痛いけど…？ あぁ、結合文字とかも考えると、もっとめんどくさいのか… 255 名前：デフォルトの名無しさん [2011/02/26(土) 06:50:22.82 ] utf16で盛り上がっているようですが、NTFSはutf16ではありません。ucs-2です 256 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 06:58:56.83 ] 何その主張？ utf16じゃなくてutf-16とでも言いたいの？ それともucs-2はunicodeじゃないと言いたいの？ 257 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 07:28:10.17 ] >>256 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なのか？という疑問もあるらしいし。 jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07 258 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 07:30:25.22 ] >>256 hibari.2ch.net/test/read.cgi/tech/1251208950/472 472 名前：デフォルトの名無しさん [sage]： 2010/11/28(日) 03:40:53 >468 Windows SDKが定義する16bitのWCHARという型って意味でWCHARって書いたんだけど、紛らわしかったか。すまん。 UNIXのファイル名がバイト列に過ぎないのと同様に、生き別れのサロゲートペアなんかも入れられたはず。BOMやU+FFFFも入るかも。 259 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 07:31:18.33 ] >>257 つ UTF-16 == UCS/Unicode Transformation Format 16 260 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:19:28.28 ] 内部コードがUTF-いくつなんてどうでもいいだろ。 外から見て差が出るところを話そうぜ……。 261 名前：デフォルトの名無しさん [2011/02/26(土) 10:30:56.66 ] >>260 うん。 bzrはいつになったら、コンソールでのエラーメッセージなどが日本語になるの？ 262 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:34:13.89 ] bzrのアンチ活動とか不毛すぎるだろ…… 263 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:37:46.68 ] >>262 svn/hgはメッセージ日本語化されているよ 264 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:41:05.75 ] 自分が使う時にはいらないが、素人に使わせる事ような場合はメッセージが 日本語化されていると嬉しいかもしれんなぁ。 265 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:55:44.74 ] >264 素人がコンソールで使うわけ無いだろ。GUI必須。 266 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 10:55:58.34 ] どんだけdisっても、git、hg、bzrの三者は、向こう十年は使われ続ける体制ができちゃったし、 気に入らない物が残っちゃてご愁傷さまとしか言いようがない。 次の十年に向けての啓蒙活動を頑張ってください。 >>264 素人ならGUI使わせるんじゃないかな。 267 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 11:13:32.83 ] >>266 そして、素人のwindiff、kdiffが化けますというクレームに、玄人が対応できていません、と答えるのですね 268 名前：methane mailto:sage [2011/02/26(土) 12:12:01.68 ] >>261 そろそろi18nしたいな。bzr-2.4までにできればやるよ。 >>267 bzr qdiff は、ファイルのエンコーディングをGUI上で選択できる ようにはしておいた。玄人は素人にエンコーディングを教えて あげてください。 269 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 12:42:29.67 ] >>268 WindowsでCP932で表すことができないファイル名のファイルはwindiff、kdiff3立ち上げられないよね？ cmd.exeでdiffしたとき、ファイルの中身がutf-8だった場合、激しく化け化けになるよね？ 270 名前：methane mailto:sage [2011/02/26(土) 15:15:05.28 ] >>269 前者は何とかする予定。 後者はさすがに無理ゲー（勝手にdiffの出力を変えたらpatchが動かない）なので プラグイン作ってオプションで回避するかな。 俺は | gvim - で見てる。 271 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 15:23:25.20 ] >>270 ということは、bzrのパッチもLinuxではロケール依存なのですね？ Windowsで作成されたパッチをLinuxであてるには、ja_JP.SJISでチェックアウトしないといけないのですね？ 272 名前：methane mailto:sage [2011/02/26(土) 15:37:40.65 ] >>271 何処をどう読めばそうなるんだろう…？ ファイル名をロケール関係なく出力するからwindowsのコマンドプロンプトに utf-8のファイルの内容を出力すると化けるんであって、それをリダイレクトで patchファイルにしてLinuxに持って行ってpatchできるよ。 ただし、ファイル名はロケール依存になっちゃってるから、日本語ファイル名の patchを作るときにはdiffは使えなくて、代わりにbundleという形式を使う。 273 名前：methane mailto:sage [2011/02/26(土) 15:38:21.18 ] あ、間違えた。 s/ファイル名をロケール関係なく/ファイルの内容をロケール関係なく/ 274 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 15:42:10.39 ] bzrのcmd.exeの標準出力はCP932だよね？ ファイル名がCP932でファイルの中身がUTF-8の場合。 これを化けずにどうやって読むのでしょうか？ 275 名前：methane mailto:sage [2011/02/26(土) 15:46:43.42 ] >>274 そのケースではファイル全体を化けないように観るのは無理。 GUI使うかコマンドラインでも変換するプラグインを使って。 276 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 15:50:34.51 ] >>275 そのプラグインとは？ 277 名前：methane mailto:sage [2011/02/26(土) 16:18:29.23 ] >>276 gigo-ice.org/scm/bazaar/plugins/encdiff.html 278 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 16:49:58.73 ] UTF-256とか作っちまえよ 279 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 16:52:14.55 ] >>278 スレ違い hibari.2ch.net/test/read.cgi/tech/1278923059/781 280 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 18:07:45.87 ] 使える文字が増えれば良い訳じゃない 増えたら、増えたで、また、やっかいな問題が出てくるもんだ 281 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 19:49:35.74 ] >>231 IDEを使うなら、utf-8ロケールのLinuxデスクトップで、 EclipseならGit、NetbeansならMercurialを使うことでオールオッケー 282 名前：デフォルトの名無しさん mailto:sage [2011/02/26(土) 20:26:39.66 ] どでもいいんだが, プロジェクトが Unix 前提で構築されてて ファイル名の銘々規則が <module-name>:<function>.<ext> な, VCS に MS Windows でつないでファイル名が 読めないって騒ぐのはよしてほしい はなっから命名規則がやばいんで Windows からみると, まともなファイル名は見えないって言ってるのにw 283 名前：デフォルトの名無しさん mailto:sage [2011/02/27(日) 00:59:26.45 ] どうでも良いと言いつつ、文句を言う奴っているよね 284 名前：デフォルトの名無しさん mailto:sage [2011/02/27(日) 01:03:08.98 ] 最近の本を見るとbzrを以上に推してるな 最近の本で言えばプログラマが覚えるべき○○の事とかも最初にbzrの名前が挙がってた だから他の分散管理はもっとがんばれ 勢いがいないぞ 285 名前：デフォルトの名無しさん [2011/02/27(日) 01:23:27.31 ] >>184 うん、いいと思うよ。俺も一人だけ作業ならそうしてる 286 名前：デフォルトの名無しさん mailto:sage [2011/02/27(日) 05:42:50.73 ] >>284 git, hgの本は売っているけど、bzrの本は売ってる？ 287 名前：デフォルトの名無しさん mailto:sage [2011/02/27(日) 05:47:23.01 ] 売ってない気がする bzrはアジャイル設計とかそういうプロジェクト管理系の本でよく見かけるようになったね 288 名前：デフォルトの名無しさん mailto:sage [2011/02/27(日) 06:23:31.25 ] >>284 git, hg本体は枯れていて安定期に入ってるから勢いが無いようにみえるかもしれない TortoiseHg 2.0 が３月１日に出る予定なので、hgは勢いつくかもしれない いろいろ目玉はあるけど、このスレ的には、MacOSX対応かな？ 289 名前：デフォルトの名無しさん mailto:sage [2011/02/28(月) 01:10:26.03 ] >>133 Debian LinuxではGitは2010/04/03まではgit-coreパッケージ、それ以降はgitパッケージです。 2008/01/10にgitパッケージ(Gitとは別物)がgnuitに改名されました。 2010/04/03にgit-coreパッケージがgitに改名され、git-coreはgitのダミーパッケージになりました。 ダミーパッケージをインストールすると自動的に本来のパッケージもインストールされます。 つまり、Debian LinuxにおけるGitのインストール数は、 2010年3月まではgit-coreのグラフ、2010年後半からはgitのグラフで表されます。 GitはすでにCVSを越え、今年中にSubversionを越えそうです。 Popularity contest statistics for bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion 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 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 <ianb@erislabs.net> Thu, 10 Jan 2008 22:04:26 +0000 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 > lists.debian.org/debian-devel/2009/09/thrd2.html#00661). > -- Gerrit Pape <pape@smarden.org> Sat, 03 Apr 2010 15:07:19 -0500 290 名前：デフォルトの名無しさん mailto:sage [2011/02/28(月) 17:37:23.77 ] >284 全然見ないよ。 最近は、本そのものをね。 bzrは、btrfsと同じで名前が途轍もなく格好悪いので geek心をくすぐらないと思う >>288 OSX対応って・・・MacHgで十分だったんだけど・・・ Finderに統合って、結構鬱陶しいってことがSubversionの時に分かったし・・・ 291 名前：デフォルトの名無しさん mailto:sage [2011/04/01(金) 03:23:44.79 ] Monotone が 1.0 になったみたいだけど、国際化対応とかユーザー認証の暗号化とかあるし、 期待してもいいんだろうか。 292 名前：デフォルトの名無しさん [2011/04/02(土) 20:39:47.88 ] あげたら 293 名前：デフォルトの名無しさん mailto:sage [2011/04/02(土) 20:48:33.91 ] 431 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 21:52:13 >430 ＞リポジトリデータはSQLiteで管理する。 キモの部分が他人任せかよ。 432 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:09:21 キモかどうかは判断が分かれるな バックエンドの処理については実装部分の話で速度に影響する もしmonotoneが速かったらGITもMercurialも産まれてなかったかもしれない 433 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:14:39 po3a.blogspot.com/2007/12/subversion.html > もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。 > ほんとに。連中は「本物のデータベース」を使っているよ。 > 「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も > 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな > これらすべての設計上の決定のために、できてきた結果はゲロゲロで > 保守不可能なカオスだ。 294 名前：デフォルトの名無しさん mailto:sage [2011/04/02(土) 20:49:36.36 ] 434 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:29:00 ｹﾁｮﾝｹﾁｮﾝだなｗ Cが至高なのは同意だが 435 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:42:13 Linus は最初 BitKeeper に変る SCM でMonotone を最有力に挙げていたが、 動作速度が遅いから Linus版 Monotone としてGitを作ったんだよな。 436 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:42:59 そこは別にいいんじゃね？ 437 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:44:07 しょっちゅう使うツールは速いが正義なんだよなぁ。 438 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 22:48:02 で、Monotoneは、user-visibleなとこでは、どの辺に新規性があるわけ？ 公開鍵がどうこうのあたり？ 439 名前：デフォルトの名無しさん [sage]： 2010/11/07(日) 23:00:55 Monotone はファイル名をUTF-8に変換して管理してる。 これは Git に持ち込まなかった概念で、速度を犠牲にしたバカげた設計だと Linus は思ったのだろう。 295 名前：デフォルトの名無しさん mailto:sage [2011/04/02(土) 23:53:55.07 ] 速度を犠牲にしたバカげた設計をしてしまったのがSubversionとBazaarかw 296 名前：デフォルトの名無しさん mailto:sage [2011/04/03(日) 01:08:09.17 ] ttp://www.infoq.com/news/2011/04/haskell-git 297 名前：デフォルトの名無しさん mailto:sage [2011/04/03(日) 02:51:43.75 ] SubversionはCなのに遅いからなぁ。あの遅さはUTF-8のせいだけじゃないんじゃないか。 まあでもCVSの代替としては長く使わせてもらったし、あの時点では最良だったと思う。 298 名前：デフォルトの名無しさん mailto:sage [2011/04/03(日) 03:14:47.45 ] 結局、どれもこれも帯に短し襷に長し、決定版と言うのはないのかね？ 299 名前：デフォルトの名無しさん mailto:sage [2011/04/03(日) 21:22:38.97 ] ないから色々あるんじゃないか？ 300 名前：デフォルトの名無しさん mailto:sage [2011/04/03(日) 21:26:45.16 ] 帯も襷もあるが、襷としても使える帯は無いし、 帯としても使える襷は無い、ということか。 301 名前：デフォルトの名無しさん mailto:sage [2011/04/06(水) 22:47:50.27 ] >>296 > The two leading distributed version control systems are Git and Mercurial, > with Darcs, Bzr and others much less widely used. > Typically the systems are used by their language implementers; > Darcs, by Haskell developers, Mercurial by Python developers and Git for C developers. 302 名前：デフォルトの名無しさん mailto:sage [2011/04/08(金) 10:18:19.21 ] Subversionのしかもwindows版TortoiseSVNから使い始めた俺は 遅くてもこんな物なんだろうと思っているからきっと幸せ。 つーか、俺、最初に手をつけた物が良いという思い込みが強くて なかなか移行できない性格で難儀。 303 名前：デフォルトの名無しさん mailto:sage [2011/04/08(金) 11:24:36.98 ] >>302 VSSに触らなくて良かったな 304 名前：デフォルトの名無しさん mailto:sage [2011/04/08(金) 14:53:29.00 ] パスが含まれているようなファイルはどう管理したらいいのですか？ オープンなリポジトリにそのままコミットするわけにはいかないと思うので。 305 名前：デフォルトの名無しさん [2011/04/08(金) 14:56:19.22 ] 2文字読んでpathかと思ったらpasswordか。 * sensibleなデータだけ別ファイルになるような構成にして、リポジトリに入れないようにする。 * 暗号化したものを入れておいてデコード手段はリポジトリに入れないようにする。 など。 306 名前：デフォルトの名無しさん mailto:sage [2011/04/08(金) 15:38:36.19 ] パスワードは環境変数にしてるなあ。仕事じゃないけど。 307 名前：デフォルトの名無しさん mailto:sage [2011/04/08(金) 17:35:21.28 ] なるほど・・・参考になりました！ ありがとうございます。 308 名前：デフォルトの名無しさん mailto:sage [2011/04/13(水) 14:20:21.44 ] これからバージョン管理を導入しようと思い調べたのだけれど、 有名どころだけでも結構あるんだね。 数人で1プロジェクトのソースが100ファイルで合計1MBに満たない ようなレベルならTortoiseSVNあたりで十分かな？ ネット上の情報も一番多い感じなので、取っつきやすいと感じた。 それとも、今から覚えるなら、こっちにしておけっていうのあります？ 309 名前：デフォルトの名無しさん mailto:sage [2011/04/13(水) 14:33:52.97 ] やっぱsvnが無難でしょ。 TortoiseSVNってことはWin環境なんだろうけど、サーバー側はVisualSVN Serverを勧めておく。 さらにVisual Studio使ってて金が出せるなら、AnkhSVNよりVisualSVNがお勧め。 何だかんだ言って、インテグレーションの出来が違いすぎる。 310 名前：デフォルトの名無しさん mailto:sage [2011/04/13(水) 15:48:40.56 ] >>309 ありがとう。 ちょっとVisualSVN Server、VisualSVNこの辺を調べてくる。 名前が似てるけど、全然別物なのか。 311 名前：デフォルトの名無しさん mailto:sage [2011/04/13(水) 19:54:25.29 ] VisualSVNそんなに良いの？いくらするんだっけ？ AnkhSVNもまあまあ悪くはないかと思ったけど 312 名前：デフォルトの名無しさん mailto:sage [2011/04/13(水) 23:17:07.73 ] AnkhSVNでも入れないよりは全然マシ。 今やってるプロジェクトはそれすら使っていないから VS上でファイル名変更されると履歴が参照できずバージョン管理の意味が無くなってる。 313 名前：デフォルトの名無しさん mailto:sage [2011/04/14(木) 02:06:48.18 ] Mercurialなら、名前変更の推定処理が出来るのに。 314 名前：デフォルトの名無しさん mailto:sage [2011/04/14(木) 02:18:52.78 ] Hgもリネームは推定なのか。Gitもそう。 315 名前：デフォルトの名無しさん mailto:sage [2011/04/14(木) 05:50:39.51 ] >>314 hg addremoveコマンドが推定。"--similarity 類似度"でパーセントを指定できる。 ファイルの移動はリポジトリに記録される。 316 名前：デフォルトの名無しさん mailto:sage [2011/04/14(木) 14:42:44.77 ] >>315 え、移動はリポジトリに記録される、けどリネームは推定なの？ リネームと移動は同じじゃないか…？ 317 名前：デフォルトの名無しさん mailto:sage [2011/04/14(木) 14:57:42.25 ] >>316 hgのファイルの移動はコピーして削除。これはリポジトリ（マニフェスト）に記録される。 コピーしたものもマージ時に反映される。 ファイルの移動はhg renameコマンドを使うのが一般的。 hg addとhg removeコマンドがあって、それぞれ、ファイルを追加したとき、削除したとき、 パラメータ無しで追加、削除を自動的に認識するコマンド。 hg addremoveはそれを合体させたもので、--similarity 100がデフォルトの値で、 ファイルが改変されていないものは移動と認識されて、commit時にそれが反映される。 318 名前：デフォルトの名無しさん mailto:sage [2011/04/14(木) 15:11:44.05 ] >>317 ＞これはリポジトリ（マニフェスト）に記録される 「コピーして削除」のみならず「移動」としての情報が記録されるということ？ つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな？ それとも--similarity 100の時だけ「移動」として特別に記録？ 319 名前：デフォルトの名無しさん mailto:sage [2011/04/14(木) 15:46:11.01 ] >>318 > ＞これはリポジトリ（マニフェスト）に記録される > 「コピーして削除」のみならず「移動」としての情報が記録されるということ？ リポジトリ（マニフェスト）には、コピーしたというのと削除したというのが別々に記録される。 aaa -> bbb ・bbbはaaaのコピー ・aaaは削除 > つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな？ > それとも--similarity 100の時だけ「移動」として特別に記録？ hg addremoveがファイルの移動をコピーと削除として判断する。 hg status のオプション"--copies"で確認可能。 この結果をcommitで確定させる。 320 名前：デフォルトの名無しさん mailto:sage [2011/04/14(木) 17:17:45.25 ] >>319 なるほど、そうなるとsvnと似たやり方かな。 Gitはそういうの一切記録しなくて、履歴を表示する時に動的に分析してる。 全く同時期に同じ目的で開発されたものだけど、けっこう違うんだねえ。 321 名前：デフォルトの名無しさん mailto:sage [2011/04/15(金) 06:18:40.99 ] Goodbye Subversion, Hello Mercurial: A Migration Guide blogs.atlassian.com/developer/2011/03/goodbye_subversion_hello_mercurial.html 322 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 09:25:35.79 ] ひさびさにTortoiseHgをあぷでとした チャンクごとのコミットが面倒なことになってないかい なんだよこれ 323 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 10:18:19.53 ] >>322 TortoiseHg 2.0の大幅なユーザインターフェースの更新に抵抗がある方は、 1.1.xの最新版を使うことをお勧めします。 https://bitbucket.org/tortoisehg/stable/downloads 324 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 10:37:51.10 ] そうですか よくみたらメジャーアップデートしてたんだ 日本語の方マニュアルやリリースノートも更新してくれればなあ！ 325 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 20:04:58.45 ] Git 1.7.5がリリース、メッセージの国際化へ一歩 www.atmarkit.co.jp/news/201104/25/git.html 326 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 21:03:39.77 ] 日本語ファイルが使えるならgit一択なのにな 327 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 21:06:26.08 ] >>326 使えるよ 328 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 21:09:21.90 ] あれ、そなの？ Win、Mac、Linuxの環境でsvnのように何の問題もなくなったの？ 329 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 21:11:41.67 ] >>328 さて、svnのどこが何の問題が無いのでしょうか？ 330 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 21:37:51.11 ] Git一択というほどGitいいのか。 今、MercrialとBazaarを試用しているけれど、Gitも試してみるか。 331 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:10:29.20 ] >>329 日本語のファイルの取り扱いが問題ありません 他はすべて日本語の扱いに問題有り 332 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:28:01.24 ] >>331 つ>>8 svnも問題あり、というよりマルチプラットフォームで問題ないものは無い。 333 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:28:50.00 ] >>332 それは既にパッチあるだろ 334 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:30:51.91 ] パッチどころか本家で既に対応済み 何年前の話だよ… 335 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:51:51.89 ] で、bzrも2.3だといけるらしい。 336 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:53:23.91 ] gitとhgｵﾜﾀｗ 337 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 00:20:04.65 ] svnは対応はできていません。 subversion.tigris.org/issues/show_bug.cgi?id=2464 bzrもだめです。 https://bugs.launchpad.net/bzr/+bug/172383

---

---

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

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