バージョン管理システムについて語るスレ8
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん
2011/01/20(木) 12:26:04●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/
バージョン管理システムについて語るスレ7
http://hibari.2ch.net/test/read.cgi/tech/1283780922/
0002デフォルトの名無しさん
2011/01/20(木) 12:26:45CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ～ Rev.3 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1254838551/
Git 2 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1284467898/
【分散型バージョン管理】 Mercurial 【hg】
http://hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/
0003デフォルトの名無しさん
2011/01/20(木) 12:27:35CVS
ttp://ximbiot.com/cvs/wiki/
Subversion
ttp://subversion.tigris.org/
Git
ttp://git-scm.com/
Bazaar
ttp://bazaar.canonical.com/en/
Mercurial
ttp://mercurial.selenic.com/wiki/
Darcs
ttp://www.darcs.net/
GNU arch
ttp://www.gnu.org/software/gnu-arch/index.html
monotone
ttp://www.monotone.ca/
Visual SourceSafe
ttp://www.microsoft.com/japan/msdn/vstudio/products/ssafe/default.aspx
●チュートリアル
Subversionによるバージョン管理(日本語訳)
ttp://subversion.bluegate.org/ (アクセスできない場合は↓)
ttp://www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork
Git入門
ttp://www8.atwiki.jp/git_jp/
git チュートリアル (バージョン 1.5.1 以降用)
ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html
Bazaar Documentation Overview
ttp://wiki.bazaar.canonical.com/Documentation
Mercurial の使い方のチュートリアル
ttp://mercurial.selenic.com/wiki/JapaneseTutorial
0004デフォルトの名無しさん
2011/01/20(木) 12:28:250005デフォルトの名無しさん
2011/01/20(木) 12:30:201. 同時に一人しか編集できないロック機構が必要ですか？
│
├(YES)→ Subversionをおすすめします。ただし、オンラインでしか開発できなくなります。
(NO)
↓
2. 日本語のファイル名が存在し、リポジトリをMS-Windows（CP932）とLinuxやMacintosh OS X（UTF-8）で同期を取りますか？
│
├(YES)→ Subversionを選択してください。WindowsとLinuxでなら、Bazzarで日本語ファイル名の同期も可能かも知れません。
(NO)
↓
3. 実験的なソースコードを頻繁に作成しますか？
│
├(NO)→ Bazzarをおすすめします。Bazzarは他のDVCSに比べると分岐が手間ですが、それ以外は遜色ありません。
(YES)
↓
4. MS-Windowsでの利用をしますか？
│
├(YES)→ Mercurialをおすすめします。設定で、日本語コミット文やCP932のファイル名も取り扱えます。
(NO)
↓
0006デフォルトの名無しさん
2011/01/20(木) 12:31:24│
├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
↓
6. シンプルな操作がお好みですか？
│
├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。
（チェンジセット: 4:ae4c01d241ab）
0007デフォルトの名無しさん
2011/01/20(木) 12:32:11皆様のレスを読んだ上で、再度、大雑把に特性をまとめてみた。
Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・分岐時は、無名ブランチが自動で切られる。名前付ブランチもつくる事ができるが、目印なので必須では無い。
・ブランチ内のチェンジセットは木構造に並ぶ。
・分岐したブランチは、元のブランチに依存する。あるブランチ内のチェンジセットを消すと、別のブランチにある子孫チェンジセットも消える。
・複数のリポジトリで変更を行いpushしても、分岐しているので衝突はしない。ただし、解消が要求されるmulti-head状態になるので、先にpullが望ましい。
Git:
・一つのリポジトリで複数のブランチが扱える。
・分岐時に、ブランチ名を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のリポジトリで変更を行いpushすると、衝突が発生する。先にpullが必要。
Bazaar:
・ブランチだけで運用を行える。リポジトリを作ると、複数ブランチでデータを共有して省スペース、ブランチ作成などの高速化ができる。
・分岐時に、ブランチのディレクトリ配置を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・マージするときは、自分のリポジトリのコミットをメインライン、他のリポジトリのを傍流として記録。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のブランチで変更を行いpush/pullすると、衝突が発生する。先にpullが必要。
0008デフォルトの名無しさん
2011/01/20(木) 12:35:22お前らこの「svnが遭遇してきた問題点とその解決策」を共有したいのでどこに記述あるか教えてください
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/491-495
491 ：デフォルトの名無しさん：2010/12/10(金) 18:02:33
bzr初心者です。2.2.2をMac上で使おうとしてますが、扱うファイル名に濁点が含まれていると
うまく動いてくれません。NFCとNFDの問題が絡んでいるということはわかったのですが、
何か回避方法はあるんでしょうか？（何かパッチを当てるとか。）
492 ：デフォルトの名無しさん：2010/12/10(金) 22:45:46
# だれかutf-8-macなcodec作ってくれ
493 ：デフォルトの名無しさん：2010/12/11(土) 08:29:26
なんだBazaarでも日本語使えないのか
494 ：デフォルトの名無しさん：2010/12/11(土) 14:48:30
Subversionでも解決しているに>>1の「多言語に完全対応」というのは嘘だったのですね
495 ：デフォルトの名無しさん：2010/12/11(土) 21:48:19
svnが遭遇してきた問題点とその解決策が
ハッカーの間で共有知になってないことが問題なのかもしれぬ
591 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:41:23
>>589-590
こっちでいいじゃん
http://d.hatena.ne.jp/hnw/20081024
592 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:42:16
ここも
http://www23.atwiki.jp/selflearn/pages/55.html
593 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:44:57
あとここ
http://hibari.2ch.net/test/read.cgi/tech/1251208950/466-474
0009デフォルトの名無しさん
2011/01/20(木) 15:00:230010デフォルトの名無しさん
2011/01/20(木) 15:14:59append_revisions_only
“True”に設定されていればリビジョンはログにのみ追加され、削除されません。
この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。
通常これは bzr init --append-revisions-only によって設定されます。
http://twitter.com/#!/methane/status/11806331434442752
append_revisions_only = True に設定したブランチでは、連番のリビジョン番号が固定され、ID替わりに使えること。
中央リポジトリ上のブランチはこの設定がおすすめ。
0011デフォルトの名無しさん
2011/01/20(木) 15:15:43もうちょっと詳しく言うと、bzrはgitやhgと違って、「メインライン」という概念があって、
履歴のウチ並列して存在するラインの片方がメイン、残りがマージされたブランチという扱いになる。
通常はメインラインのウチのリビジョンだけを表示することで、別ブランチで開発中にコミットされた
細かいリビジョンを無視して、それをメインラインにマージしたコミット１つにまとめて表示できる。
なので、ローカルで作業中に作ったゴミみたいなコミットをまとめて綺麗な１つのコミットにするみたいな
作業が要らない。
(もちろん、メインラインを無視して、全ブランチが同等という運用をしても良い)
なんだけど、だれかがローカルのブランチから中央のブランチをマージすると、そのローカルでは
メインラインはローカルブランチに、中央ブランチはサブラインになって、それを push すると
中央ブランチのメインラインが置き換わってしまう。
中央 1:A - 2:B - 3:C - 4:D
ローカル 1:A - 2:B - 3:X - 4:Y -(中央からマージ)- 5:Z
(この状況でローカルから中央に push)
中央 1:A - 2:B - 3:X - 4:Y - 5:Z (中央のサブライン 2:B - 2.1.1:C - 2.1.2:D - 5:Z)
(リビジョン番号3と4に割り当てられているリビジョンが変わってる)
これを許さないのが append_revisions_only
0012デフォルトの名無しさん
2011/01/20(木) 18:04:240013デフォルトの名無しさん
2011/01/20(木) 18:44:340014デフォルトの名無しさん
2011/01/20(木) 22:46:02JVM上で動くので、WindowsやLinuxでも、UTF-8環境の native Gitとでも
日本語ファイル名も含めて今のところ相互運用に問題は無い。
まだ実装されてない機能もあるし、GUIで扱うなら eclipse のEGit plug-in
に頼らないといけないところが難点。EGit の UI は悪くないけどね。
0015デフォルトの名無しさん
2011/01/20(木) 22:59:570016デフォルトの名無しさん
2011/01/21(金) 00:10:52文書、テンプレート、画像、なんてディレクトリが作られちゃうんで是非ともutf8のマルチ
バイト文字列のファイル・ディレクトリ名をきちんと操作・バージョン管理できるよう、おな
がいします。
0017デフォルトの名無しさん
2011/01/21(金) 00:43:440018デフォルトの名無しさん
2011/01/21(金) 00:55:06本当は一つにしたかったし、もし無理矢理一つにするんだったらhgを選んだろうけど
0019デフォルトの名無しさん
2011/01/21(金) 01:41:43使用感はどんな感じか聞いてみたい。
特に大きなリソースを扱うプロジェクトでのパフォーマンスなど。
Perforceの対抗馬になるようなら嬉しいんだけど
0020前スレ989
2011/01/21(金) 23:57:50それを書いたのは俺だが……すまん、実務ではまだ使ってないんよ。今年中にはVSSからの移行先としてTFS2010を評価する予定だけど。
まだホワイトペーパー（http://download.microsoft.com/download/A/C/5/AC56DA05-5AEA-4118-B2F9-83C4E70834F1/TFS2010_SCM.pdf）
しかまだ見てないです。ちなみにシェルブ機能の紹介はP.57にあるね。
（ここから下は全部憶測）
個人的には、そもそもIIS+ASP.NET+SharePoint+MSSQLが要るという時点で、パフォーマンスはあまり期待してなかったり。
少なくとも、DBサーバーをインストールするマシンは十分なI/O性能を確保しないと悲惨なことになると思う。
その辺は伝統的な3層クラサバとまんま同じノウハウが適用できる（というか必要になる）ハズ。
あとは評価してみないことには分からないけど、ウチの場合、100MB近いMDBを数十個扱う予定なので、
その結果分かったことがあれば、ここに書くよ（忘れてなければ……）。
0021デフォルトの名無しさん
2011/01/22(土) 04:43:43BASIC認証でしか運用ができないので、Gitではなく、hgwebがあるMercurialを採用することにした。
0022デフォルトの名無しさん
2011/01/24(月) 17:36:100023methane
2011/01/25(火) 16:58:26http://svn.apache.org/viewvc/subversion/trunk/notes/unicode-composition-for-filenames?view=markup
ちなみに、2月リリースのbzr-2.3のベータ版ではもう直ってるっぽい。
0024デフォルトの名無しさん
2011/01/26(水) 06:51:31これで「社会が憎い.properties」が使えるわけですね。
0025デフォルトの名無しさん
2011/01/26(水) 10:39:24誰得アプリに磨きがかかったのですね
0026デフォルトの名無しさん
2011/01/26(水) 11:49:05リポジトリの構造や、ブランチ操作の手軽さはMercurialの方が優位だと思うが、弊社の以下の状況はBazaar優位になっています。
・PM佐藤は「英語わからんし」とつぶやいて、日本語ファイル名を作る。
・PG田中はマカーなので、Windowsは手が汚れると言って触りもしない。
・PG茶谷はLinuxでvimを使うことだけがアイデンティティ。
・ﾃﾞｻﾞｲﾅ鈴木はWindows以外は分からないと言って、Macintosh OS Xを直視もしない。
0027デフォルトの名無しさん
2011/01/26(水) 11:51:090028methane
2011/01/26(水) 12:28:18リポジトリの構造ってMercurial優位だっけ？
bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
0029デフォルトの名無しさん
2011/01/26(水) 12:36:33表現方法が悪いのかも知れないけど、以下の理由でMercurialの方が優位だと思う。
・チェンジセットの関係が木構造で操作が直感的。
・名前無しブランチがあるので、ブランチを作るのが容易。
・名前付ブランチも、まとめてpush/pullできる。
GitもBazaarもブランチは直線的で、分岐するのには操作がいる。clone、push、pullもブランチ単位。
特にBazaarは、ブランチの扱いでディレクトリ配置を意識する必要がある。
0030methane
2011/01/26(水) 12:44:09あぁ、 .bzr とか .hg 内部のファイル／データ構造という意味じゃないのね＞リポジトリの構造
そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。
0031デフォルトの名無しさん
2011/01/26(水) 12:51:50> bzrの方がファイル数少なくて容量小さいし、
hgはコピーをサポートしていて、ファイルの移動はコピーと削除だから
大幅にディレクトリ構成を変更した場合、必然的にリポジトリがでかくなる。
あまりにも大幅な構成の変更の場合、convertをした方が良い
bzrはコピーをサポートしている？
FATの場合、でかいファイルの方がフラグメントやらで都合が悪くない？
gitの場合、packするしないはユーザの自由だが、bzrは勝手にパックしちゃうのか？
> やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
cygwin
あと、例の拡張
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
進化している
マイナーチェンジで基本は全く変わっていないけど
0032methane
2011/01/26(水) 13:02:40bzrはコピーは今はサポートしていない。
代わりに、移動はサポートしていて移動しても容量は増えない。
FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
パックは10、100、1000コミットごとに自動で行われる。
>cygwin
>あと、例の拡張
Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
例の拡張ってなんだろう？
0033デフォルトの名無しさん
2011/01/26(水) 13:12:22> >>31
> bzrはコピーは今はサポートしていない。
> 代わりに、移動はサポートしていて移動しても容量は増えない。
>
> FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
> ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
> パックは10、100、1000コミットごとに自動で行われる。
2GB制限は？
> >cygwin
> >あと、例の拡張
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
> 例の拡張ってなんだろう？
当然知っているでしょ？
MAX_PATHのことを言っているんでしょ？
ANSI APIを使うという方針なんだから仕方がない。
それを横取りしている拡張
0034methane
2011/01/26(水) 13:31:30bzr関連のブランチを格納しまくってるshared repositoryの中をのぞいてみたら、
pack数が12個で最大のものが31MBだから、ソースコード管理では2GB制限は
気にしないで良さそう。動画ファイルとか大容量のファイルの扱いは確かに苦手。
MAX_PATHはANSIとは直交した制限で、CreateFileWとか使っても同じUTF-16の
コードポイント数が制限を受ける。
この制限を回避するためには "\\?\c:\" みたいな書きかたでWin32APIのチェックを
スルーしてファイルシステムにアクセスしないといけないんだけど、これをやると
カレントディレクトリとか一切使えなくなる。
例の拡張ってのが、もしfix-utf8の事を言っているのであれば、僕が昔触ってた時は
utf8<=>utf16の変換をしていただけで、 "\\?\" は使ってなかった。
0035デフォルトの名無しさん
2011/01/26(水) 13:40:40って、これも知っているよね？
もう１つの拡張の方も横取りしている。
パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
そこがANSI APIになっている。
0036デフォルトの名無しさん
2011/01/26(水) 13:48:26>そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。
リビジョン番号30（ハッシュタグ0b70750bdf9b02597741301c695ff46bc75036d4）から分岐するとする。
Mercurial (3ステップ):
hg update -C -r 30
[編集]
hg commit -m "以前のバージョンから分岐"
Git (4ステップ):
git branch NewBranch 0b70750b
git checkout NewBranch
[編集]
git commit -m "以前のバージョンから分岐"
Bazaar (4ステップ):
cd ..
bzr branch -r revno:30 ./OldBranch ./NewBranch
cd NewBranch
[編集]
bzr commit -m "以前のバージョンから分岐"
Bazaarはブランチがファイルシステムと連動しているSVN風なので、ブランチの切り替えが手間。マージもファイルパスを指定する必要がある。
Gitはブランチ切り替えは容易だが、ブランチの切り替えが必要。
Mercurialは、編集対象のチェンジセットと連動して、自動的に無名ブランチが切られる。
個人的には、Bazaarが洗練されているようには思えない。
0037デフォルトの名無しさん
2011/01/26(水) 13:59:05準備無しにBazaarでブランチを切ると、ディスク占有サイズが倍増する。
「リポジトリ」を作っておけば、ブランチを切っても実ファイルはシェアするが、事前準備がいる。GitやMercurialには不要な作業。
後から「リポジトリ」を使うこともできるが、移行作業はいる。
0038デフォルトの名無しさん
2011/01/26(水) 14:07:06Git (3ステップ):
git checkout -b NewBranch 0b70750b
[編集]
git commit -m "以前のバージョンから分岐"
0039デフォルトの名無しさん
2011/01/26(水) 14:09:15git checkout -b NewBranch 0b70750b
0040methane
2011/01/26(水) 14:12:49>hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
>って、これも知っているよね？
bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を
用意してて、同じファイルシステムで clone した後に push / pull したら共有できない
という制限もない。
>もう１つの拡張の方も横取りしている。
>パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
>そこがANSI APIになっている。
もう一つって、win32なんちゃらの事かな？
最近hg使ってないから最近の事情に疎くて、、、またhg使い始める予定だから調べとこ。
一応言っておくけど、 hg のリポジトリフォーマットが効率悪くて使い物にならないとか
言ってもなければ思ってもないよ。
>>26 を hg のリポジトリフォーマットがbzrより優秀と誤読したから反論しただけ。
リポジトリフォーマットは hg, git, bzr 全部、ソースコード管理目的では十分な効率をしている。
hgでMAX_PATHが問題になるのもレアケースで、僕が使ってる限り問題になったことはない。
0042デフォルトの名無しさん
2011/01/26(水) 14:53:47何それ？
0043デフォルトの名無しさん
2011/01/26(水) 15:19:30> >>35
> >hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
> >って、これも知っているよね？
>
> bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を
> 用意してて、同じファイルシステムで clone した後に push / pull したら共有できない
> という制限もない。
http://foozy.bitbucket.org/hgbook-ja/d6ca1334a19d/hgbookch4.html#x27-790004.5
何人かの構成管理ツールの開発者により、この方法 完全にリポジトリ固有のものとしてファイルを複製する
が ディスク使用量削減にそれほど効果的でないとの指摘を受けています。それは事実ではありますが、
ディスク容量の 確保は安価であり、 OS への複製要求を遅延することにより高い性能を得ることができます。
別な仕組みを用いる場合、性能が低下しソフトウェアの複雑さが増しますので、
日々の利用における “体感” に非常に影響を及ぼします。
訳注: つまり、 Mercurial でのハードリンクの使用は、複製を行うことによるディスクヘッドのシークを
低減するのが主眼で、ディスク使用量の低減が主眼ではな い、ということです。
0044methane
2011/01/26(水) 18:32:36簡単に言えば、gitみたいな名前付きブランチを実現するもの。
bzr自体は作業ツリー、ブランチ、リポジトリを分離して自由に構成できるけど、
逆に自由すぎるのが面倒なので、1リポジトリ, 複数のブランチ、1つの作業ツリーの
組み合わせを git のように扱えるようにしてくれるもの。
>>36 で言えば、
bzr colo-branch -r30 NewBranch
の1ステップになる（現在のブランチ=OldBranchのr30からNewBranchを作って、
作業ツリーを新しいブランチのチェックアウトに切り替える）
0045デフォルトの名無しさん
2011/01/26(水) 19:00:02> >>42
> 簡単に言えば、gitみたいな名前付きブランチを実現するもの。
＼ ∩─ｰ､ ====
＼／ ● ､_ ｀ヽ ======
/ ＼( ● ● |つ
| X_入__ノ ミ そんな餌で俺様が釣られクマ――
､ (＿／ ノ /⌒l
/＼＿＿＿ノﾞ＿/ / =====
〈 ＿_ノ ====
＼ ＼＿ ＼
＼＿__） ＼ ====== (´⌒
＼ ＿＿_ ＼＿＿ (´⌒;;(´⌒;;
＼＿＿＿）＿＿＿）(´;;⌒ (´⌒;; ズザザザ
0046デフォルトの名無しさん
2011/01/26(水) 23:34:10旧来のブランチの機能を果す何物かがあるだけ
0047デフォルトの名無しさん
2011/01/26(水) 23:54:130048methane
2011/01/27(木) 00:12:55http://progit.org/book/ja/ch3-2.html
ここでいう 'master' ブランチ とかいうのは名前付きブランチじゃないの？
まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
なるのが bzr-colo
0049デフォルトの名無しさん
2011/01/27(木) 00:40:14プラットホームは Linux で。ほかにも何かおすすめがあれば。
0050デフォルトの名無しさん
2011/01/27(木) 00:43:20bzrはよく分かんないんだけど、
gitは>>46の通りで、SHA1ハッシュに対するエイリアスをブランチと呼んでいるだけで、
内部的には「ブランチを作る」という機能は無いと言っていい。
ただUIとしては「ブランチ」と特化した表現をしたほうが分かりやすいので
「ブランチを作る」というコマンドは存在する（エイリアスを作るだけのコマンド）
0051methane
2011/01/27(木) 00:47:49うん、で、今は内部構造じゃなくてワークフローの話をしているんだから、
>>44 の発言って別に間違ってないよね。 >>45-47 の突っ込みは気にしなくて
いいよね。
0052デフォルトの名無しさん
2011/01/27(木) 00:54:56馬鹿なの？
ブランチの意味知らないんなら喋らないほうがいいよｗｗｗ
0053デフォルトの名無しさん
2011/01/27(木) 01:10:01＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿branch1
＿×＿×＿×＿×＿×＿×＿×＿branch2
×＿×＿×＿×＿×＿×＿×＿＿branch3
＿×＿×＿×＿×＿×＿×＿×＿branch4
×＿×＿×＿×＿×＿×＿×＿＿branch5
0054デフォルトの名無しさん
2011/01/27(木) 02:27:26は？
0055デフォルトの名無しさん
2011/01/27(木) 04:46:40「ブランチ」に対するアプローチが、
・ディレクトリ名を指定
・共有リポジトリ作成後、その下にあるディレクトリ名を指定
・bzr-coloを利用
と3種類もある。
GitやMercurialはシンプルなコンセプトで実装が見えない所が、SVNに似ているので見えてしまうのがBazaarという印象が拭えない。
0056methane
2011/01/27(木) 07:43:19だから俺は >>30 で
>どちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。
って言ったんだけどね。
俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が
安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの
作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
だから、自分では bzr-colo はあまり使ってない。
ブランチ管理についてできるだけ特定のスタイルを押し付けないのがbzrの方針。
逆に言えば「こういうフローで作業しましょうね」という指針を提供してくれていないので
初心者にはどう使ったら良いのか判らなくなるし、gitと同じワークフローを採用すると
gitよりもブランチ管理が手間になったりもする。
この点は結構前からBazaarのMLで議論されていて、bzr-colo は git と同じワークフローを
楽にするプラグインという以上に、将来の bzr の "bzr init" で作成するのを
standalone branchじゃなくてcolocated branchにするための proof of conceptにも
なっている。
0057デフォルトの名無しさん
2011/01/27(木) 07:44:04Mercurialの「名前付きブランチ」は「おまけ」
リポジトリの分離と名無しブランチでも運用可能
cvsのブランチのように消さないことを前提としている
名前付きブランチを乱発すると収集が付かなくなるからcloseする機能が後から出来た
「名前付きブランチ」と「リビジョン番号」はgitには無い
0058デフォルトの名無しさん
2011/01/27(木) 07:46:13> まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
> なるのが bzr-colo
用語はどうでもよいから、bzrは意味不明な用語を乱発しているのか
0059デフォルトの名無しさん
2011/01/27(木) 07:54:07> 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が
> 安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
大量のごみブランチが発生するのは害でしかない
マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
ブランチとやらがbzrの売りらしいが、
大規模コミュニティの開発では何のメリットも無い
0060methane
2011/01/27(木) 07:58:51いちいち突っかかるなぁ。。。
僕が git が定義している用語を知らないし興味もないってだけだよ。
gitはgithubクライアントにしか使ってないから。
bzr ではきちんと用語を定義して使い分けてるよ。
で、git で refs 以下で「コミットに対する名前による参照」を提供しているけど、
この「コミットに対する名前による参照」って git はなんて定義しているの？
「ローカルブランチ」だとブランチが存在する場所が焦点になってしまって、
hgの無名ブランチと違って「名前で参照されている」という点に焦点を当てたかったから
hgの用語を拝借して「名前付きブランチ」と呼んだんだけど。
0061デフォルトの名無しさん
2011/01/27(木) 08:04:16ローカルブランチ、リモートブランチを勉強してから出直してきな
0062methane
2011/01/27(木) 08:07:51> 大量のごみブランチが発生するのは害でしかない
> マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
だからこういう個人の主観による優劣で議論する気ないんだってば。
**俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」
ってならないし、本当に要らないものを整理する気になるから好きってだけで、
別にbzrはそれを強制してないから、 >>59 が bzr を使うときには俺と違う使い方をすればいい。
> github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
意味が分からない。
リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？
0063デフォルトの名無しさん
2011/01/27(木) 08:09:19> 僕が git が定義している用語を知らないし興味もないってだけだよ。
bzr開発者はgitに興味が無いから、bzrは使い勝手の悪い誰得アプリになってしまったのか
0064methane
2011/01/27(木) 08:12:07gitも一応githubクライアントとして少しは使ってるから、
ローカルブランチとリモートブランチは使ってるよ。
どちらもコミットのハッシュ値ではなくて名前で参照できるという点では、
hgでいう「名前付きブランチ」だね。
もちろん完全に同じものとは言ってないよ。
0066デフォルトの名無しさん
2011/01/27(木) 09:01:24> **俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」ってならない
Gitはブランチの一覧ができる。
Mercurialはブランチやヘッドの一覧ができる。
Bazaarはディレクトリを見て、「これブランチだっけ？」と考える必要がある。
目につくところに無いのは、Bazaarとしか思えない。
0067デフォルトの名無しさん
2011/01/27(木) 09:05:55> > github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
> 意味が分からない。
> リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？
意味が分からない
「個人所有のブランチ」って何？
0068デフォルトの名無しさん
2011/01/27(木) 09:19:32> だからこういう個人の主観による優劣で議論する気ないんだってば。
「個人の主観」ではなく、VCS運用の基本ではないか。
Git、Mercurialとも基本機能は単純だが、プロジェクト毎に方法論を確立している。
Bazaarはオープンソースでの実績があまりにも乏しいのもあって、方法論が確立しているように見えない。
0069methane
2011/01/27(木) 09:35:19だから **俺は** って言ってるじゃん。別にbzrがgit,hgより優れてるなんて言ってないよ。
**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
「これブランチだっけ？」なんて考えないし、そもそもコミットしてないデバッグ目的の変更や、
addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
そこに残しているの。
bzrならこんな使い方もできるというだけで、一般的にこの方法が優れているなんて思ってないし、
bzrもこの使い方を強制しているわけじゃない。
>>67
自分がpushできるブランチ
>>68
個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
ワークフローか？個人が便利に使えたらそれで良いじゃん。
0070デフォルトの名無しさん
2011/01/27(木) 09:40:39> >>68
> 個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
> ワークフローか？個人が便利に使えたらそれで良いじゃん。
bzrは個人でしか使えないという認識で良いのですね？
0071デフォルトの名無しさん
2011/01/27(木) 09:41:550072デフォルトの名無しさん
2011/01/27(木) 09:42:120073methane
2011/01/27(木) 09:44:07そもそもこの議論の発端が俺の 「ブランチがディレクトリにひもづく」 発言なんだから、
最初からローカル作業の話なんだけど？
開発サイトでのブランチの管理と、ローカルでの作業ツリー＋ブランチの管理は別物。
0074デフォルトの名無しさん
2011/01/27(木) 09:49:590075デフォルトの名無しさん
2011/01/27(木) 10:00:45> そもそもコミットしてないデバッグ目的の変更や、
> addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
> そこに残しているの。
Subversionの欠点をそのまま踏襲しているのか？
0076デフォルトの名無しさん
2011/01/27(木) 10:20:06>**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
GitやMercurialと比較して、Bazaarは運用にmethane氏のようなコツがいるわけだね。
0077デフォルトの名無しさん
2011/01/27(木) 10:23:160078デフォルトの名無しさん
2011/01/27(木) 10:30:240079デフォルトの名無しさん
2011/01/27(木) 11:01:41bzr特有の概念の「ブランチ」をあたかも普遍的な概念としていて、
誰も理解できないことを書いているのだから、批判と捉えても仕方がない
0080デフォルトの名無しさん
2011/01/27(木) 11:04:120081デフォルトの名無しさん
2011/01/27(木) 12:03:18> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
svnでrepo/projectname/trunkをチェックアウトするのではなく、
repo/projectnameをチェックアウトしてたって事？
変わった使い方だな。
0082methane
2011/01/27(木) 12:19:23project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
をそれぞれ並列にチェックアウトして作業したい事ってない？
僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
というかこれもう完全にbzrの話じゃないよね。
hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。
0083デフォルトの名無しさん
2011/01/27(木) 12:24:13> hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。
いや、あんたがsvn, bzrの特徴として言い出したんだが。
0084デフォルトの名無しさん
2011/01/27(木) 12:41:23> project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
> をそれぞれ並列にチェックアウトして作業したい事ってない？
> 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
hgは同じファイルシステムだとリポジトリはハードリンクだからコストがかからなし、
gitもhgもcheckoutで切り替えればいいだけ
わざわざ全部チェックアウトするメリットは？
0085methane
2011/01/27(木) 12:41:47単に、ブランチごとに作業ツリー作るのが楽と感じる人もいるんだよという
ことが言いたかっただけなんだが、 >>56 を見るとそれが bzr の特徴って
思われても仕方ないな。すまん。
0086デフォルトの名無しさん
2011/01/27(木) 12:50:52> svnでrepo/projectname/trunkをチェックアウトするのではなく、
> repo/projectnameをチェックアウトしてたって事？
> 変わった使い方だな。
なるほど、bzrは"svn switch"も簡単にできないから全部チェックアウトする必要があるのか
0087methane
2011/01/27(木) 12:53:10だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
持っておきたい場合があるんだって。
コミットしない変更とか、バージョン管理下に無いテストデータとか、
色々なゴミファイルが作業ツリー配下にできるから。
別に git stash; git checkout; とかでも良いんだけど、ファイルシステム上に
合った方がテキストエディタで開くにもgrepするにも何かと便利だったりするんだよ。
というかこれもう完全にバージョン管理ツールの話じゃなくて個人の
作業スタイルの話だからやめようぜ。
0088デフォルトの名無しさん
2011/01/27(木) 12:54:050090デフォルトの名無しさん
2011/01/27(木) 12:59:49> だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
> 持っておきたい場合があるんだって。
> コミットしない変更とか、バージョン管理下に無いテストデータとか、
> 色々なゴミファイルが作業ツリー配下にできるから。
分散型で「コミットしない変更とか、バージョン管理下に無いテストデータとか」が
発生すること自体が理解できないのだが
MercurialのMQや"git merge --squash"のような機能が無いってことなのか？
0091methane
2011/01/27(木) 13:22:14違う違う、
cd 1.1; ./foo --test > test.result; cd ..
cd 1.2; ./foo --test > test.result; cd ..
diff -u 1.1/test.result 1.2/test.result
とか、あとは勝手に入れてコミットには絶対含めないprintfデバッグ用
コードとか、ローカルで動かすための設定ファイルetcetc...
最初から最後まで一切バージョン管理には含めないゴミだけど
作業中は残しておきたいファイルだよ。
もちろんそういったデータを管理するためのプラグインもある(pipeline)
んだけど管理するよりディレクトリ分けた方が楽だと思ってるから
分けてるだけ。
だからもうこの話もうやめようぜ。
俺は作業ツリーを複数持ちたいからそうしているだけなのに、
なんでいちいちbzrの機能不足という事に繋げようとするのかねぇ。
bzrが使いにくくないと何か困ることがあるんだろうか？
0092デフォルトの名無しさん
2011/01/27(木) 13:26:28Bazaarが使いづらいと、指摘している人が多いだけ。
このスレだと、比較分析されて当然。
0093デフォルトの名無しさん
2011/01/27(木) 13:36:04> >>90
> 違う違う、
>
> cd 1.1; ./foo --test > test.result; cd ..
> cd 1.2; ./foo --test > test.result; cd ..
> diff -u 1.1/test.result 1.2/test.result
>
> とか、あとは勝手に入れてコミットには絶対含めないprintfデバッグ用
> コードとか、ローカルで動かすための設定ファイルetcetc...
> 最初から最後まで一切バージョン管理には含めないゴミだけど
> 作業中は残しておきたいファイルだよ。
これこそMercurialのMQの目的なのだが。
gitにも輸出されているそうだし。
0094methane
2011/01/27(木) 13:49:43うん、だから、
> もちろんそういったデータを管理するためのプラグインもある(pipeline)
> んだけど管理するよりディレクトリ分けた方が楽だと思ってるから
> 分けてるだけ。
って言ってる。
作業ツリーを分けるのは僕が楽と思ってるスタイルであって、別にbzrが推奨
しているわけではないし、bzrの機能不足で仕方なくこのスタイルをとっている
わけでもない。
ディレクトリを分けるのが面倒という意見に対する反例としてディレクトリを
分けるのが楽と感じる人もいるんだよという意味で自分のスタイルを紹介した
だけで、別にこれがbzrのスタイルではない。
bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
どのスタイルも推奨していない。
が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
可能性が高い。
0095デフォルトの名無しさん
2011/01/27(木) 13:51:58といいつつ愛用しているけれど。
0096デフォルトの名無しさん
2011/01/27(木) 15:24:29No revisions to pull.
しかし、push しようとすると、以下のようになる。
bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/var/tmp/bazaar/trunc/".
これ、もしかしてuncommitして編集しなおさないとpush不可能？
不便すぎない？
Bazaarの--append-revisions-onlyを使っている人いるの？
0097デフォルトの名無しさん
2011/01/27(木) 15:51:150098デフォルトの名無しさん
2011/01/27(木) 15:53:11> （作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
これって、Trac/Redmineを使えば良いだけでは？
0099デフォルトの名無しさん
2011/01/27(木) 16:39:14> bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
> どのスタイルも推奨していない。
> が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
> bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
> 可能性が高い。
Bazaarの言う自由度の高さとGitのこれとは何が違うの？
Pro Git 5.1 Git での分散作業 分散作業の流れ
http://progit.org/book/ja/ch5-1.html
0100methane
2011/01/27(木) 16:45:30branch, merge, push で運用したいなら、 append-revisions-only は設定しちゃだめ。
例えば github のグラフとか見ると、 push したら一番上のラインがゴソっと入れ替わる
ことがあるけど、それを防止するのが append-revisions-only だから。
append-revisions-only を使って運用したら、履歴がこういう風に、ほかのブランチのマージだけになる。
http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes
bzr-colo 使わない場合は、bzr checkout http://example.com/repo/trunk; cd trunk; して、
bzr merge ../my_own_branch; bzr commit; のように、「trunkがローカルブランチを取り込む」
ようにしないといけない。
大規模プロジェクトでは、この trunk に merge して commit は、限られたコミッタが
手動でやるか、PQMみたいなシステムが自動的にレビューが完了したブランチを取り込む。
TortoiseBZR の開発では、細かい修正は直接 trunk の checkout 上でやってしまっている。
bzr-colo を使って作業ツリー1つでローカルブランチ使いたい場合は、多分こんな感じになる。
bzr colo-ify --trunk-name=local # (初回のみ)colo化して、今のブランチを local という名前にする
bzr branch http://example.com/repo/trunk colo:upstream --bind # (初回のみ)trunkを upstream という名前で持ってくる
bzr switch colo:upstream
bzr merge colo:local
bzr commit -m "Add XXX feature."
2回目以降は、bzr switch, bzr merge, bzr commit で良くなる。
ただし、coloは常用してないので嘘ついてるかも。後でやってみる。
0101methane
2011/01/27(木) 16:49:44svnと同じく checkout, update, commit でリモートと同期がとれるのが
git の中央集権よりも svn チックな使い方かな。
会社で導入したとき、svn に慣れた人には branch, pull, merge, commit, push
の一連の操作が面倒らしく、特に非プログラマには最初はすごい不評だった。
今では基本的に checkout を推奨して、bzrを使いこなしたい人だけ
ローカルにブランチ作るということにしてる。
0102デフォルトの名無しさん
2011/01/27(木) 16:53:42それって、Subversionに慣れている人はSubversionで、
Gitに慣れている人はgit-svnのGitで、を使えば出来ることだよね
0103デフォルトの名無しさん
2011/01/27(木) 17:04:14それだとSubversionとgitの両方の環境を維持しなきゃいけないじゃない。
101の方法だとbzrだけに統一できて管理がシンプルになる。
業務でやるなら管理のシンプルさはけっこう重要だと思うがな。
0104デフォルトの名無しさん
2011/01/27(木) 17:15:15Eclipse, Netbeans, Visual Studio, Trac, Redmine, Hudson
これら全てでBazaarはSubversionと遜色無く動くの？
0105103
2011/01/27(木) 18:17:04動かないといけない職場なら、それを前提に検討すりゃいい。
それでbzrが候補から落ちるならそれはそれ。
でもそういう状況にないそれが必要ない職場ならbzrでいいし、実際
methaneさんとこはそういう検討の末にbzr選んだだけでしょ?
0106デフォルトの名無しさん
2011/01/27(木) 18:51:20もしかしてExcel？
だから日本語ファイル名が必要なの？
append-revisions-onlyを使わないとリビジョン番号が変わるんだよね？
チケット駆動の開発をしていて、どのリビジョンで修正しました、ってのは、
どう指定すれば良いの？
make distでリビジョン番号を埋め込んだりするよね？
これもリビジョン番号変わっちゃうよね？
0107methane
2011/01/27(木) 19:02:33あまり普通の会社じゃないからどれだけ役に立つか判らないけど、
TortoiseSVNに慣れたユーザーは以外とTortoiseBZR使って文句が無い
Eclipse, Netbeans は使ってる人いるけど、バージョン管理はコマンドライン
bzr-svn で svn プロトコルで serve することができるので、それを使って
trunk から svn としてチェックアウト＆コミットがどれくらい実用に耐えるのかは
今後検討しようと思ってる。
Trac, hudson は問題なし。Redmineは使ってない。
チケットはtracのURLを設定ファイルに書いておけば、 commit --fixes で連携可能だけど、
僕が見てる範囲だとあまりチケットとコミットの連携はしてないでユルく運用してる。
make dist をするプロジェクトは少ないんだけど、 >>101 に書いた通り
基本 checkout でやりたい人だけ branch する運用なので、 append-revision-only
で問題なく運用できてる。
0108デフォルトの名無しさん
2011/01/27(木) 19:10:28010996
2011/01/27(木) 19:38:110110デフォルトの名無しさん
2011/01/27(木) 19:41:58これまでのレスを見ての通り、日本でBazaarを分散型として使っている人はいない
0111methane
2011/01/27(木) 19:45:00append_revisions_only = False にするか、
trunk をチェックアウトしてそこから merge する。
詳しくは >>100
0112デフォルトの名無しさん
2011/01/27(木) 20:05:110113デフォルトの名無しさん
2011/01/28(金) 11:04:08> >>26
> リポジトリの構造ってMercurial優位だっけ？
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
http://mercurial.selenic.com/wiki/Win32LongFileNamesExtension
0114デフォルトの名無しさん
2011/01/28(金) 11:14:29> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
https://bitbucket.org/remleduff/win32lfn/src/a21c5be76398/src/win32lfn.py#cl-65
0115デフォルトの名無しさん
2011/01/28(金) 11:35:20> >>26
> リポジトリの構造ってMercurial優位だっけ？
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
http://mercurial.selenic.com/wiki/fncacheRepoFormat#Hashing_of_long_paths
> Paths inside the store that would be longer than 120 chars are now hash encoded.
0116デフォルトの名無しさん
2011/01/28(金) 12:41:08リビジョン番号が変化するか、不便を強いられるかの2択か。
0117デフォルトの名無しさん
2011/01/28(金) 12:46:120118デフォルトの名無しさん
2011/01/28(金) 14:06:25違うバージョンになってるってことと比べて、どの程度の不便さなん？
0119デフォルトの名無しさん
2011/01/28(金) 14:11:57リリースノートは別管理でしょ？
Bazaarにあるか知らないけど$Rev$が意味をなさない弊害は大きいと思うが
0120デフォルトの名無しさん
2011/01/28(金) 18:32:49ChangeLogって、CVSのログから自動生成するものだと思っていたが、手書きするのか
Subversion以降見かけたことが無いからぐぐってみたら、こんなの見つけた
http://svnlogbrowser.org/demo/
0121デフォルトの名無しさん
2011/01/29(土) 10:55:21これって何で美乳なの？微乳じゃいかんの？
0122デフォルトの名無しさん
2011/01/29(土) 11:18:080123デフォルトの名無しさん
2011/01/29(土) 11:48:47美乳 EUCでぐぐってみよう
0124デフォルトの名無しさん
2011/01/29(土) 11:55:48次スレがあるのでそちらへどうぞ
http://hibari.2ch.net/test/read.cgi/tech/1291075205/
297 名前：デフォルトの名無しさん [sage]： 2010/09/10(金) 12:24:16
>>290
>>292
>>294
単なるZERO WIDTH SPACEだ？
じゃあお前らは編集者が意図した覚えも無いのに、先頭に勝手にunkoって保存されたりされなかったりする環境に何の問題も感じないの？
エンコーディングが明確になるだ？
文字化け対策の<!-- 美乳 -->かっつーの
いらねーもん無断でつけんなカス
0125デフォルトの名無しさん
2011/02/12(土) 12:37:380126デフォルトの名無しさん
2011/02/13(日) 18:46:29直っていない
https://bugs.launchpad.net/bzr/+bug/172383/comments/15
0127methane
2011/02/13(日) 22:51:01http://irclogs.ubuntu.com/2011/01/25/%23bzr.html#t07:44
0128デフォルトの名無しさん
2011/02/15(火) 02:29:43http://hibari.2ch.net/test/read.cgi/tech/1297704483/
0129デフォルトの名無しさん
2011/02/16(水) 16:58:300130デフォルトの名無しさん
2011/02/16(水) 17:08:320131デフォルトの名無しさん
2011/02/16(水) 17:18:080132デフォルトの名無しさん
2011/02/16(水) 17:20:26githubが目立つからそうかもしれないけど、
hgはbitbucket/google code/codeplexと分散しているのと、
hgwebが簡単に立てられて、自前で立てている所が多いから、
オープンソースでもhgはもっと多いと思う。
hgはWindowsサポートでgitより先に行っていたので、企業内ではさらに多いと思う。
0133デフォルトの名無しさん
2011/02/16(水) 17:35:280134デフォルトの名無しさん
2011/02/16(水) 17:49:06一面ではあると思うが参考になったthx。
0135デフォルトの名無しさん
2011/02/16(水) 22:40:17どのVCSを使うかではなく、
VCSを使って何を作るかである、
とジョン・F・ケネディーも言っていたお。
0136デフォルトの名無しさん
2011/02/23(水) 13:50:37.67思ったけどWindowsのデフォルトロケールをUTF-8に出来ないんだろうかね・・・
Linuxは、UTF-8にできるし、MacはUTF-8
Windowsさえ変えれれば幸せになれるんだけどなぁ・・・(正規化はおいとくとして)
いずれにせよ、GiもHgもバイナリ列でファイル名を扱うってポリシーなんだから
そのバイナリ列を作る部分にフックを置いて変換できるようにしといてくれればいいんだよぉ・・・
0137デフォルトの名無しさん
2011/02/23(水) 14:50:33.54文字コードスレによれば、WindowsでDBCSが２バイトまでと決まっているから無理だそうだ
Mercurialでは関数のよこどりで実現している。あまり美しくないけど
開発者の問題意識はあるという所まで来ているので、大きい声をあげれば
フックみたいなのも実現できるかもしれない
0138デフォルトの名無しさん
2011/02/23(水) 15:47:16.08Windows8以降でいいのでその辺り何とかして欲しいです・・・
いい加減、UTF-8を扱えないシステムって旧世代ってイメージが・・・
Mercurialの開発者に問題意識が？前は問題はないんだ、
という姿勢だったところからすれば勉強したのかね。自分の視野の狭さっぷりを。
0139デフォルトの名無しさん
2011/02/23(水) 15:54:28.95対応全然早かったんだけどな。
互換性のためにMBCSのAPIを残しているだけなんだから、Windowsの視点で言えば
10年以上前から用意しているUnicode API使わないで Windows 95 互換API使ってる
アプリの方が旧世代という事になる。
0140デフォルトの名無しさん
2011/02/23(水) 15:56:36.880141デフォルトの名無しさん
2011/02/23(水) 16:04:56.510142デフォルトの名無しさん
2011/02/23(水) 16:17:51.15DBCS=MBCSだからCP932用
UTF-16とは関係ない
0143デフォルトの名無しさん
2011/02/23(水) 16:36:34.150144デフォルトの名無しさん
2011/02/23(水) 17:29:00.69あー、ごめん、Unicode策定してた連中に言ったつもりだった。
0145デフォルトの名無しさん
2011/02/23(水) 18:04:01.310146デフォルトの名無しさん
2011/02/23(水) 19:37:32.05DBCSで苦労してない言語圏の連中はわかっちゃいないからな。
Windows専用アプリならアプリ内部まで全部UTF-16で統一するのが普通。
0147デフォルトの名無しさん
2011/02/23(水) 23:20:04.23Windows対応のクロスプラットフォームアプリを作る場合は、内部の
文字コードをUTF-8に統一するケースとUTF-16に統一するケースがある。
gtkは前者だし、Python、Java、CLI、wxWidgets、Qt は後者。
0148147
2011/02/23(水) 23:21:23.77処理系の wchar_t に合わせる場合や、 Python のように UTF-16 と
UTF-32 を選べる場合もある。
0149デフォルトの名無しさん
2011/02/24(木) 23:28:17.70内部表現はUTF-32、外部表現はUTF-8ってのを標準にしてくれたら
スッキリするんだけどなぁ。
0150デフォルトの名無しさん
2011/02/24(木) 23:34:29.78UTF-32だとメモリ使用量が上がる割には、別に1文字が1コードポイントに
なるわけでもないし、あんまり嬉しくない。
CJK以外はUTF-8が、CJKも含めるとUTF-16がベストバランス。
0151デフォルトの名無しさん
2011/02/24(木) 23:36:42.45UTF-8 は1コードポイントが何バイトになるか不定だから、内部コーディングと
しては UTF-16 がベストバランス。
0152デフォルトの名無しさん
2011/02/24(木) 23:42:06.92WindowsはUTF-16固定？
0153デフォルトの名無しさん
2011/02/24(木) 23:46:12.23UTF-16 は負の遺産という認識だったけど
0154デフォルトの名無しさん
2011/02/24(木) 23:49:15.38Javaはchar型が16bitだからプリミティブ型でUnicodeの文字全部は扱えないし・・・
無理矢理過ぎるんだよ・・・ASCII圏の人間に理解してもらえる訳ないじゃないか・・・
0155デフォルトの名無しさん
2011/02/24(木) 23:49:40.000156デフォルトの名無しさん
2011/02/24(木) 23:49:54.49>>147 も書いてるように、現役バリバリ。
UCS4にしたら、容量はほとんど倍になるのに、利点はサロゲートペアの
処理が不要になることくらいで、1文字が1コードポイントになるわけじゃない。
0157デフォルトの名無しさん
2011/02/24(木) 23:52:04.46UTF-8にしたら結合文字やサロゲートペアの処理どころか
マルチバイトの処理まで必要になる。
内部コードをUTF-8の方針をとっているフレームワークも
あるけど少数派。
0158デフォルトの名無しさん
2011/02/24(木) 23:52:24.00内をUTF-8にしたら処理が重くなると思うよ。
内部形式としては、固定長が幸せになれると思う。
0159デフォルトの名無しさん
2011/02/24(木) 23:52:55.00いい加減スレ違いだからUnicodeスレに行け。
0160デフォルトの名無しさん
2011/02/24(木) 23:53:13.040161デフォルトの名無しさん
2011/02/24(木) 23:54:28.69内部コードを何にするかとファイル名をどう扱うかは全く関係ないが。。。
0162デフォルトの名無しさん
2011/02/24(木) 23:57:10.63現役なんじゃなくて歴史を引き摺ってるだけでしょ
日本人以外にとっては UTF-16 が救世主に見えた時があったからね
0163デフォルトの名無しさん
2011/02/25(金) 00:13:29.48UTF-8 でも重くなりようが無い。UTF-16 はハナから無いでしょ。
0164デフォルトの名無しさん
2011/02/25(金) 00:16:13.76今話してるのは、バージョン管理システムに限らず一般的なアプリケーションの
内部エンコーディングの話。つまりスレ違い。
0165デフォルトの名無しさん
2011/02/25(金) 00:26:42.61どうなれば最適解なんだろね、という話だから、それほど脱線でもないでしょ。
OS依存の話すんな、と言われればそれまでかも知れんが。
0166デフォルトの名無しさん
2011/02/25(金) 00:33:43.11Windows に限定した話題なら、Unicode APIを使え、でFAだろ。
内部コーディングにUTF-8を使おうがUTF-32を使おうが、Unicode APIを
呼ぶときにUTF-16に変換すれば良い。
Javaが内部ではUTF-16でファイル名を扱ってても、Linuxでファイル名を
指定するときはUTF-8にエンコードしてシステムコール呼ぶのと一緒。
0167デフォルトの名無しさん
2011/02/25(金) 07:25:35.98Windows以外ではファイル名に'\0'が入るのがアウトだから変換が必要。
JavaのShift_JIS、ms932のカオスをVCSがやる必要があるのか。
0168デフォルトの名無しさん
2011/02/25(金) 07:56:03.02内部エンコーディングの意味わかってる？
API呼び出すときには、内部エンコーディングをそのプラットフォームの
APIに合わせるんだよ。
QtだってJavaだって、内部ではUTF-16を使って、Linuxでシステムコールを
呼ぶときにはバイト列に変換して呼び出してる。
0169デフォルトの名無しさん
2011/02/25(金) 08:05:16.70分かっているよ。
VCSはファイルのバージョン管理をするソフトだよね？
git/mecurialはLinux生まれなんだから、内部をUnicodeにする必要は無いよね？
そんなことをしたらLatin-1の人にとってはパフォーマンス劣化して使いづらいものになるよね？
0170デフォルトの名無しさん
2011/02/25(金) 08:11:27.04そこがパフォーマンス上ボトルネックになるとでも思っているのか…
0171デフォルトの名無しさん
2011/02/25(金) 08:18:17.40Mercurialのコンソールのutf-8の日本語メッセージ(usageなど)の対応でも、
パフォーマンス劣化したって文句が上がってるんだよ？
Bazaarはいつになったらコンソールの日本語メッセージが出るようになるの？
0172デフォルトの名無しさん
2011/02/25(金) 08:33:17.66i18n でパフォーマンスが劣化するとしたら、コールドスタート時に
メッセージカタログがディスクキャッシュに載ってない場合くらい。
メッセージのルックアップを繰り返しも少しオーバーヘッドになるから
繰り返して呼ばないようにする必要があるけど、Unicodeからlocale
への変換はさらに低コスト。
実使用には全く問題ないオーバーヘッド。そんなの気にする奴は
ベンチマーク厨だけ。
0173デフォルトの名無しさん
2011/02/25(金) 08:39:29.22だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
Linuxカーネルのようにギガを超えているものだと、statusチェックだけでも、
３２ビットOSでは動かなくなるよ？
0174デフォルトの名無しさん
2011/02/25(金) 08:45:24.40>だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
意味がわかんない。今までの内部エンコーディングの話とどう関係するの？
>gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
ファイル名のところだけな。
gitのメモリ消費はファイル名が大きな部分を占めてるん？
0175デフォルトの名無しさん
2011/02/25(金) 08:50:59.41checkoutしたときのロケールとコミットするときのロケールが違うことはありえる
git/hg statusコマンドを叩く度に内部でファイル名をUnicodeに変換するとしたら使いものにならない
0176デフォルトの名無しさん
2011/02/25(金) 09:03:22.14なるほど、バイナリ透過派だったのね。話が噛み合わないわけだ。
内部エンコーディングが UTF-8 vs UTF-16 の話からいつの間に話題が
変わってたんだろ。
バイト透過はLinuxの世界に引きこもる場合はロケール無視できて幸せだけど、
ファイルシステムがUnicodeなMacやWindowsと共同作業するのにはあまり
向かない。
俺は別に非ASCIIファイル名を使わないから気にしないけど。
0177デフォルトの名無しさん
2011/02/25(金) 09:39:03.80Merurialはファイル名以外は内部UTF-8
Gitはログもバイト列でエンコード情報を付加している
どっちも正しい多言語化
0178デフォルトの名無しさん
2011/02/25(金) 10:03:21.47あー、内部エンコーディングの話を無理やりbzrをディスる方向に
持って行きたかったのね。はいはい。
ファイル名に関しては、「たったひとつの正しい多言語対応」なんてものは存在しない。
ファイル名の扱いがOS毎に異なるんだから。
0179デフォルトの名無しさん
2011/02/25(金) 10:23:05.55うん、bzrの設計はおかしい。
2005年だとJavaの文字２バイトのおかしさは認識されていたはずだし、
Linuxのutf-8ロケールも実用的になっていた。
Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
知らなかったとしか思えない。
0180デフォルトの名無しさん
2011/02/25(金) 10:35:36.51> 2005年だとJavaの文字２バイトのおかしさは認識されていたはずだし、
> Linuxのutf-8ロケールも実用的になっていた。
意味不明。UTF-16 は Unicode のほとんどの文字集合を表現可能で、
UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
さらに言うと、bzrはPythonの unicode 型を使っているだけで、Pythonは
UTF-16とUTF-32を切り替え可能。bzrはPythonの内部エンコーディングに
依存してないし、リポジトリフォーマットではUTF-8を使ってる。
Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。
> Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
> 知らなかったとしか思えない。
bzr 開発してるのは Ubuntu Linux の開発してる Canonical で、
少なくともお前よりは Linux の多言語対応について判ってると思うぞ。
0181180
2011/02/25(金) 10:37:41.52>UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
の部分の日本語がおかしかった。
Unicode の（まだ文字が割り当てられていないコードを含む）ほとんどのコードを
表現可能で、UTF-16で表現できないコードに対して文字が割り当てられることは
永遠にないだろう。
0182デフォルトの名無しさん
2011/02/25(金) 10:38:27.52>意味不明。
>別にEUCでもバイト透過にしたっていいじゃない。
本当は意味が分かってるんじゃないの?
本当は EUC にして良いとは思ってないんじゃないの?
0183デフォルトの名無しさん
2011/02/25(金) 10:38:56.90これが全て
他のは日本語環境だと使い物にならない
0184デフォルトの名無しさん
2011/02/25(金) 10:40:51.980185デフォルトの名無しさん
2011/02/25(金) 10:41:55.69WindowsではUTF-16に変換してUnicode APIを呼ぶ（リポジトリ内部はUTF-8？）
Unix系ではその時のロケールに変換して出力、
って感じで、プラットフォーム毎に対応してるのかな？
単に表示上の問題だけならUIで吸収できると思うんだけど、ファイル名となると
ファイルシステムが対応してないとダメじゃない？
Linuxのファイルシステムって、内部表現とかあるんだろうか。
ファイル名のバイト表現が不定になると動かなくなるアプリとか、けっこうありそうな…
0186180
2011/02/25(金) 10:49:26.64subversion に関しては yes
ファイルシステムに関しては、Linuxの場合は標準的に使われている
ファイルシステム(ext, btrfs, xfs, reiserfs)はバイト透過型。
Unicode型のHFS+を使ったりもできるけどね。
ファイル名のバイト表現が不定だと動かないのは、まさにMakefile
クロスプラットフォームではASCII文字以外使いものにならないけど、
Makefileに非ASCII文字書きたい人があまりいないから問題ない。
antとかはsvnと同じ方式だから、逆にロケールや環境が変わってるのに
バイト列が保存されてると動かない。
0188デフォルトの名無しさん
2011/02/25(金) 11:34:29.81フランス人、ドイツ人にコミットユーザ名に非ASCIIを使うな、って言えない。
git、hgは入力・出力どっちもきちんと対応している。
bzrはファイル名もロケール依存になっている不思議な設計。
0189デフォルトの名無しさん
2011/02/25(金) 11:50:50.34なるほど。ファイルシステムはパフォーマンス出したいところだから、
内部はバイト透過にしておきたいだろうなぁ。
>>188
Subversionもファイル名ロケール依存では？
現状を考えると、フランス人ドイツ人もユーザ名はASCIIでは困るけど、
ファイル名はASCIIでいいよ、って感じなのかね。
それかどうしてもファイル名に非ASCII使いたい場合はUTF-8決めうちにしておいて、
UI側でそう見做せばいいでしょ、っていうのがLinux方面のスタンスかな？
0190デフォルトの名無しさん
2011/02/25(金) 12:20:48.99全部大事
全部満たしてるのがbzrだけ
0191デフォルトの名無しさん
2011/02/25(金) 12:27:11.43日本人の人名で普通に使われている文字がbzrでは使えないよね？
0192methane
2011/02/25(金) 12:40:06.97一応言っておくけど、bzrがNFCで正規化するのはファイル名だけで、
コミッターやコミットログには示申を書いても神になったりしないよ。
hg, git と同じレベルで問題ない。
ファイル名をUnicodeで扱うのが正しいのかどうかは、>>178の言うとおり
正解はない。どのポリシーを選択するかだけ。
0193デフォルトの名無しさん
2011/02/25(金) 13:25:59.990194デフォルトの名無しさん
2011/02/25(金) 13:43:27.410195デフォルトの名無しさん
2011/02/25(金) 14:51:51.55比較や他プラットフォームに展開するときのみコード変換、正規化。
このやり方ならUnicode決め打ちよりはずっと多くの文字を正確に扱える。
こんなめんどくさいことをしてるアプリは見たことないが。
0196デフォルトの名無しさん
2011/02/25(金) 14:54:01.19よう、いいだしっぺ
0197デフォルトの名無しさん
2011/02/25(金) 15:17:44.230198デフォルトの名無しさん
2011/02/25(金) 15:17:45.41そのアプローチだと、ひとつのファイル名に
互換性のない複数のエンコーディングが混じった場合どうすんの？
0199デフォルトの名無しさん
2011/02/25(金) 15:21:00.63例えばLinuxでLANGをSJISにして「あ.txt」を追加、次はEUCにして「あ.txt」を追加、とかか？
それでも同じLinux上でチェックアウトするなら片方文字化けするだけで問題ない。
他のOSに持って行こうとすればエラーにでもすればいいと思う。
(理屈としてはWindowsでA.txtとa.txtが同時に存在できないのと同じ)
0200デフォルトの名無しさん
2011/02/25(金) 16:29:57.73Mercurialのリポジトリファイル名はそんな感じ。
だから、UTF-8だろうがコロンが入ろうが、リポジトリはFATに置ける
0201デフォルトの名無しさん
2011/02/25(金) 16:33:31.64cygwinがそれをやっているので、git/hg本体がやる必要性が無くなった
0202デフォルトの名無しさん
2011/02/25(金) 16:38:53.66Eclipseで使えないと困っちゃうんだよねぇ・・・
0203デフォルトの名無しさん
2011/02/25(金) 16:50:04.22それってUTF-8対応したCygwinってやつ？
てことは、WindowsでもCygwinなら化けない？
0204デフォルトの名無しさん
2011/02/25(金) 17:15:40.44そうだよ、EUC-JPのファイル名もチェックアウトできるよ
0205デフォルトの名無しさん
2011/02/25(金) 18:45:30.52> Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
> するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。
ということで、Git/Mercurialは、Linuxではバイト透過で、
cygwinでは、LANG=ja_JP.EUC-JPでEUC-JPファイル名を使えますが？
0206デフォルトの名無しさん
2011/02/25(金) 19:21:43.99NTFSがUTF-16なのにどこで保存してるんだ？
セカンドストリーム？
0207デフォルトの名無しさん
2011/02/25(金) 22:31:47.81- Cygwin は 1.7 から UTF-8 Cygwin と同じような対応が入ってロケール設定がファイル名(の変換)に効くようになった。
- LANG=ja_JP.EUC-JP するとプログラムから見た場合にファイル名が EUC-JP になってるように見える。
プログラム内で EUC-JP のファイル名渡すと Cygwin API layer で UTF-16 に変換されて Wide API 経由でアクセスされる。
- Windows のファイルシステムで許可されない文字(例えば : とか)は Unicode のプライベートエリアの文字に変換される。
Cygwin 上で見る場合は逆変換されるので普通に見える。
0208デフォルトの名無しさん
2011/02/25(金) 23:10:55.47非ASCIIファイル名を感情的に嫌ってるやつが居ることだから、
技術的にあれこれ言っても無意味。
0209デフォルトの名無しさん
2011/02/25(金) 23:34:44.37まっとうな対応とは思うが、>>201の言ってることは何なんだ(苦笑
0210デフォルトの名無しさん
2011/02/26(土) 00:32:46.22Unicode と言ったら、今は UTF-8 か UTF-32
0211デフォルトの名無しさん
2011/02/26(土) 00:39:59.28お前の頭の中だけな。
0212デフォルトの名無しさん
2011/02/26(土) 00:41:32.04でも、お前さんらも使っていーよ。UTF-8 と UTF-32 ね。
0213デフォルトの名無しさん
2011/02/26(土) 00:49:19.48WindowsでもJavaでも.NETでも頑張ってUTF-8かUTF-32使ってろ。
アホくさ。
0214デフォルトの名無しさん
2011/02/26(土) 00:50:59.24Servlet ではもっぱら UTF-8 で入出力してるよ
過去のしがらみを引き摺ってる方がアホくさ
0215デフォルトの名無しさん
2011/02/26(土) 00:55:30.810216デフォルトの名無しさん
2011/02/26(土) 01:04:09.03Servlet って Java か？
おもいっきり UTF-16 使ってるだろ。
クラス名だってUTF-16だぞ。文字列全部UTF-16だぞ。
っていうか、入出力って、外部エンコーディングの話してたの？
頑張ってUTF-16をdisってるみたいだけど、どこにファイルフォーマットや
ネットワーク転送時にUTF-16を使ってるバージョン管理システムがあるの？
それとも内部エンコーディングっていう単語の意味がわからなかったの？
0217デフォルトの名無しさん
2011/02/26(土) 01:07:07.26Java の内部エンコーディングを俺が決められるなら UTF-16 なんて使わねえよ・・・
過去に遡って Java のエンコーディングを変える事が出来たとして UTF-16 を選ぶ人間は独りだけだろ
もっと足元の現実を見ようぜ
0218デフォルトの名無しさん
2011/02/26(土) 01:10:43.62なんで？UTF-16って固定符号長だしUnicodeで定義されている文字を
全部表現できるし、どうせUTF-32にしたってメモリ使用量がほぼ倍になるのに
1文字1コードポイントにならないし、UTF-32に拘る理由なんてないでしょ。
0219デフォルトの名無しさん
2011/02/26(土) 01:15:24.95何でって固定長の振りして実際は固定長じゃないからだよ。
プログラムで扱う文字列の殆どは数字とアルファベットだから UTF-16 にしたら
メモリ使用量が倍以上になるし、出力する際も UTF-8 が殆どなんだから、
変換するだけ処理時間の無駄。
今更、こんなどうでも良い事で抵抗しても何の意味も無いじゃん・・・
0220デフォルトの名無しさん
2011/02/26(土) 01:40:59.65文字の符号数が固定でなくても、符号が固定長なのは処理の楽さに影響するよ。
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を
選んでいるのは、それなりにメリットがあるから。
0221デフォルトの名無しさん
2011/02/26(土) 01:49:29.33それは今更 UTF-16 を使う理由にはならないよね
何でサロゲートペアやバイトオーダーを無視するの?
何で UTF-8 がデファクトとなっている世の中でわざわざ UTF-16 に変換するコストを無視するの?
何で CJK の文字列の中でも数字やアルファベットが多数含まれている事を無視するの?
何でそんな過去の技術に拘りたいの?
0222デフォルトの名無しさん
2011/02/26(土) 02:01:08.43文字列が可変長なんだから、文字も可変長になっててどこがいけないのか？
UTF-8マンセー！
0223デフォルトの名無しさん
2011/02/26(土) 02:01:33.18サロゲートペアを考慮する必要があるケースって、文字単位で処理をしたい
場合だろうけど、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るべき。
0224デフォルトの名無しさん
2011/02/26(土) 02:03:50.56「え、UTF-8 の方が良い部分がある? いやいや UTF-16 だって UTF-32 に比べたらマシですよ」
「UTF-16 は UTF-32 に比べたらここが良いんですよ！」
「え、UTF-32 の方が良い部分がある? いやいや UTF-16 だって UTF-8 に比べたらマシですよ」
0225デフォルトの名無しさん
2011/02/26(土) 02:07:14.760226デフォルトの名無しさん
2011/02/26(土) 02:12:39.15俺もそう思うわ。
↓こんな感じで、内部コードに UTF-8 を使用するのは十分リーズナブル。
http://practical-scheme.net/gauche/memo-str-j.html
0227デフォルトの名無しさん
2011/02/26(土) 02:20:15.47俺は別にUTF-16最強と言いたいわけじゃなくて、UTF-16をレガシー扱い
するのは気が早いと言いたいだけだ。
>>225
中途半端とも言えるし、バランスがいいとも言える。
>>226
内部エンコーディングにUTF-8を使うのも十分ありだね。
Python も実装の内部でUTF-8を使えるようにしようという話は開発者の
間で議論されている。
0228デフォルトの名無しさん
2011/02/26(土) 02:22:47.15CJKの当事者としてもうちょっと勉強しようぜ。
0229デフォルトの名無しさん
2011/02/26(土) 02:22:50.71拘ってないでレガシーだって認めちゃえよ
CJK の話だって無理があり過ぎなのは薄々感づいてるんだろ
0230デフォルトの名無しさん
2011/02/26(土) 02:26:01.13『1コードポイントは固定長』という便利な表現をこのスレで学んだからな
0231デフォルトの名無しさん
2011/02/26(土) 02:45:02.44hgやGitをWindowsで使いたい人はCygwin使おうね、でFAということは分かった。
よく分からないけど、どうせIDEから使うんでしょ？ そうでもない？
IDEからCygwinのコマンド使ってもらえばオールオッケー？
0232デフォルトの名無しさん
2011/02/26(土) 02:46:54.040233デフォルトの名無しさん
2011/02/26(土) 02:49:11.61UTF-16 だと 129222 bytes で、UTF-16 の方がファイルサイズが大きくなるよ。
日本語の掲示板でこれなんだから、英語のテキストや数値データファイル、地図データ、
ログファイル等々、CJK 文字が殆ど入らないデータを UTF-16 で扱えばどれだけ
無駄が発生する事か・・・
0234デフォルトの名無しさん
2011/02/26(土) 02:58:37.03文字列操作のコストがイメージできないからUTF-8とかUTF-32とか言えちゃうんだろ。
C, C++ とかで文字列処理のアルゴリズム組むとか、O記法の概念が分かれば、
「大抵のケースについてO(1)時間で処理できる」ということの重要性は分かるよ。
ついでに、メモリは増えたけど、アクセスはやたら遅いんだよ。昔から。
そんなにUTF-32使いたいならCPUが10GHzになってバス幅が1024bitになるまで寝てろ
>>233
それは外部エンコードディングの話じゃん
AAだらけのとことかでも比較してみろよｗｗ
しかもメモリをけちりたいくせに数値データを数値に変換する手間は惜しむのかよｗｗｗ
0235デフォルトの名無しさん
2011/02/26(土) 03:06:04.80何でこんな簡単な話を理解出来ない振りをするのか分からんけど、
1. dat ファイルは SJIS
2. それを内部エンコーディングが UTF-8 の処理系で読み込んだら 113564 bytes になる
3. UTF-16 の処理系で読み込んだら 129222 bytes になる
4. 非効率なのはどっち?
それ以外の下らない突っ込みにも返事して欲しい?
君の永遠に納得しないゲームに付き合う理由も無いけどね・・・
0236デフォルトの名無しさん
2011/02/26(土) 03:08:47.020237デフォルトの名無しさん
2011/02/26(土) 03:13:01.59話だったと思うんだが。
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はもっと
使いものにならない。
0238デフォルトの名無しさん
2011/02/26(土) 03:16:53.52>>224
ダブスタ乙
それは都合の悪い時にもっと都合の悪い方を dis って誤摩化してるだけだろ
0239デフォルトの名無しさん
2011/02/26(土) 03:18:52.01utf-16の非効率を指摘しながらutf-32はOKという自分のほうがダブスタ
だっていう認識はないんだな。。。
0240デフォルトの名無しさん
2011/02/26(土) 03:20:38.04よく分からんが、ここで争ってる文字コードは、どこで使う文字コード？
バージョン管理システム内だけで使う文字コードじゃないの？
それとも、各開発環境で使用してる文字コードを、
バージョン管理システムでは、わざわざ変換して保存するとかの話？
0241デフォルトの名無しさん
2011/02/26(土) 03:21:53.26なんか内部エンコーディングと外部エンコーディングの区別もつかない奴が
暴れてるだけ。どの部分の文字コードの話とか全然話題になってない。
0242デフォルトの名無しさん
2011/02/26(土) 03:23:17.21俺は UTF-8 の方が効率的だという話しかしていない。
君が勝手に UTF-32 と比較して UTF-16 を擁護しようとしているだけ。
当然 UTF-8 に対しては何の反論にもなっていない。
UTF-32 を採用する事があるとすれば、それは効率ではなく別の理由。
0243デフォルトの名無しさん
2011/02/26(土) 03:25:05.29>バージョン管理システム内だけで使う文字コードじゃないの？
つ >>164
0244デフォルトの名無しさん
2011/02/26(土) 03:25:40.70この議論はそもそも >>210 から始まったんだが。。。
UTF-16 を採用することがあるとすれば、それは効率と扱いやすさのバランス。
0245デフォルトの名無しさん
2011/02/26(土) 03:25:56.41ふーん
バージョン管理システム内で使う文字コード(ログとか)なら、
開発環境に合わせて、好きな文字コード選べた方が良いし、
開発環境で使用してる文字コードを、変換して保存するとか
トラブルの元にしかならないからやめて欲しいのは俺だけか？
0246デフォルトの名無しさん
2011/02/26(土) 03:28:47.22効率も悪いし、サロゲートペアが必須で扱い辛い文字コード乙
0247デフォルトの名無しさん
2011/02/26(土) 03:29:23.71あーなるほどね。
そう言う話なら、ぶっちゃけどうでも良いや。
0248デフォルトの名無しさん
2011/02/26(土) 03:30:07.68そう、ぶっちゃけどうでも良いのです。
0249デフォルトの名無しさん
2011/02/26(土) 03:30:08.18何故か今までWindows APIがUTF-16という点でしか登場する機会のなかった
UTF-16をdisり始めた >>210 が現れて、スルーできずにUTF-16の利点を
説明しだす奴が現れて、さらに何故かUTF-16がUTF-8より優れているという
議論をしていると勘違いしてる奴が現れた。
0250デフォルトの名無しさん
2011/02/26(土) 03:32:09.41そして今、君が颯爽と現れてこれからこのスレを有意義な話題で盛り上げてくれる訳だ。
0251デフォルトの名無しさん
2011/02/26(土) 03:32:49.71効率: UTF-8 < UTF-16 << UTF-32
処理しやすさ: UTF-32 < UTF-16 << UTF-8
効率と処理しやすさのどっちか片方しか必要ない場合は君の言うとおり。
どっちも必要な場合はバランスが良いフォーマット。
0252デフォルトの名無しさん
2011/02/26(土) 03:36:34.42文字コードを考えたって意味ないじゃん
むしろ、そのシステムで使えないファイル名を付ける奴が悪いってことじゃなくて？
0253デフォルトの名無しさん
2011/02/26(土) 03:39:34.62結局、固定長を前提に出来ない時点で UTF-16 に処理し易さなんて無いよ
UTF-8 が ascii の範囲では固定長だから処理がし易いと言ってるのと同じ
0254デフォルトの名無しさん
2011/02/26(土) 04:02:39.82基本的に処理なんて、変換位しかないし、一回書けば終わりなんだから
処理のしやすさなんて考えても意味ないじゃんって、突っ込んだら負けなの？
あと、変換とかで考えるとコードセパレート問題とか考える方が余程頭痛いけど…？
あぁ、結合文字とかも考えると、もっとめんどくさいのか…
0255デフォルトの名無しさん
2011/02/26(土) 06:50:22.820256デフォルトの名無しさん
2011/02/26(土) 06:58:56.83utf16じゃなくてutf-16とでも言いたいの？
それともucs-2はunicodeじゃないと言いたいの？
0257デフォルトの名無しさん
2011/02/26(土) 07:28:10.17http://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
0258デフォルトの名無しさん
2011/02/26(土) 07:30:25.22http://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も入るかも。
0259デフォルトの名無しさん
2011/02/26(土) 07:31:18.33つ UTF-16 == UCS/Unicode Transformation Format 16
0260デフォルトの名無しさん
2011/02/26(土) 10:19:28.28外から見て差が出るところを話そうぜ……。
0261デフォルトの名無しさん
2011/02/26(土) 10:30:56.66うん。
bzrはいつになったら、コンソールでのエラーメッセージなどが日本語になるの？
0262デフォルトの名無しさん
2011/02/26(土) 10:34:13.890263デフォルトの名無しさん
2011/02/26(土) 10:37:46.68svn/hgはメッセージ日本語化されているよ
0264デフォルトの名無しさん
2011/02/26(土) 10:41:05.75日本語化されていると嬉しいかもしれんなぁ。
0265デフォルトの名無しさん
2011/02/26(土) 10:55:44.74素人がコンソールで使うわけ無いだろ。GUI必須。
0266デフォルトの名無しさん
2011/02/26(土) 10:55:58.34気に入らない物が残っちゃてご愁傷さまとしか言いようがない。
次の十年に向けての啓蒙活動を頑張ってください。
>>264
素人ならGUI使わせるんじゃないかな。
0267デフォルトの名無しさん
2011/02/26(土) 11:13:32.83そして、素人のwindiff、kdiffが化けますというクレームに、玄人が対応できていません、と答えるのですね
0268methane
2011/02/26(土) 12:12:01.68そろそろi18nしたいな。bzr-2.4までにできればやるよ。
>>267
bzr qdiff は、ファイルのエンコーディングをGUI上で選択できる
ようにはしておいた。玄人は素人にエンコーディングを教えて
あげてください。
0269デフォルトの名無しさん
2011/02/26(土) 12:42:29.67WindowsでCP932で表すことができないファイル名のファイルはwindiff、kdiff3立ち上げられないよね？
cmd.exeでdiffしたとき、ファイルの中身がutf-8だった場合、激しく化け化けになるよね？
0270methane
2011/02/26(土) 15:15:05.28前者は何とかする予定。
後者はさすがに無理ゲー（勝手にdiffの出力を変えたらpatchが動かない）なので
プラグイン作ってオプションで回避するかな。
俺は | gvim - で見てる。
0271デフォルトの名無しさん
2011/02/26(土) 15:23:25.20ということは、bzrのパッチもLinuxではロケール依存なのですね？
Windowsで作成されたパッチをLinuxであてるには、ja_JP.SJISでチェックアウトしないといけないのですね？
0272methane
2011/02/26(土) 15:37:40.65何処をどう読めばそうなるんだろう…？
ファイル名をロケール関係なく出力するからwindowsのコマンドプロンプトに
utf-8のファイルの内容を出力すると化けるんであって、それをリダイレクトで
patchファイルにしてLinuxに持って行ってpatchできるよ。
ただし、ファイル名はロケール依存になっちゃってるから、日本語ファイル名の
patchを作るときにはdiffは使えなくて、代わりにbundleという形式を使う。
0273methane
2011/02/26(土) 15:38:21.18s/ファイル名をロケール関係なく/ファイルの内容をロケール関係なく/
0274デフォルトの名無しさん
2011/02/26(土) 15:42:10.39ファイル名がCP932でファイルの中身がUTF-8の場合。
これを化けずにどうやって読むのでしょうか？
0275methane
2011/02/26(土) 15:46:43.42そのケースではファイル全体を化けないように観るのは無理。
GUI使うかコマンドラインでも変換するプラグインを使って。
0276デフォルトの名無しさん
2011/02/26(土) 15:50:34.51そのプラグインとは？
0277methane
2011/02/26(土) 16:18:29.23http://gigo-ice.org/scm/bazaar/plugins/encdiff.html
0278デフォルトの名無しさん
2011/02/26(土) 16:49:58.730279デフォルトの名無しさん
2011/02/26(土) 16:52:14.55スレ違い
http://hibari.2ch.net/test/read.cgi/tech/1278923059/781
0280デフォルトの名無しさん
2011/02/26(土) 18:07:45.87増えたら、増えたで、また、やっかいな問題が出てくるもんだ
0281デフォルトの名無しさん
2011/02/26(土) 19:49:35.74IDEを使うなら、utf-8ロケールのLinuxデスクトップで、
EclipseならGit、NetbeansならMercurialを使うことでオールオッケー
0282デフォルトの名無しさん
2011/02/26(土) 20:26:39.66ファイル名の銘々規則が
<module-name>:<function>.<ext>
な, VCS に MS Windows でつないでファイル名が
読めないって騒ぐのはよしてほしい
はなっから命名規則がやばいんで Windows からみると,
まともなファイル名は見えないって言ってるのにw
0283デフォルトの名無しさん
2011/02/27(日) 00:59:26.450284デフォルトの名無しさん
2011/02/27(日) 01:03:08.98最近の本で言えばプログラマが覚えるべき○○の事とかも最初にbzrの名前が挙がってた
だから他の分散管理はもっとがんばれ
勢いがいないぞ
0285デフォルトの名無しさん
2011/02/27(日) 01:23:27.31うん、いいと思うよ。俺も一人だけ作業ならそうしてる
0286デフォルトの名無しさん
2011/02/27(日) 05:42:50.73git, hgの本は売っているけど、bzrの本は売ってる？
0287デフォルトの名無しさん
2011/02/27(日) 05:47:23.01bzrはアジャイル設計とかそういうプロジェクト管理系の本でよく見かけるようになったね
0288デフォルトの名無しさん
2011/02/27(日) 06:23:31.25git, hg本体は枯れていて安定期に入ってるから勢いが無いようにみえるかもしれない
TortoiseHg 2.0 が３月１日に出る予定なので、hgは勢いつくかもしれない
いろいろ目玉はあるけど、このスレ的には、MacOSX対応かな？
0289デフォルトの名無しさん
2011/02/28(月) 01:10:26.03Debian 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
0290デフォルトの名無しさん
2011/02/28(月) 17:37:23.77全然見ないよ。
最近は、本そのものをね。
bzrは、btrfsと同じで名前が途轍もなく格好悪いので
geek心をくすぐらないと思う
>>288
OSX対応って・・・MacHgで十分だったんだけど・・・
Finderに統合って、結構鬱陶しいってことがSubversionの時に分かったし・・・
0291デフォルトの名無しさん
2011/04/01(金) 03:23:44.79期待してもいいんだろうか。
0292デフォルトの名無しさん
2011/04/02(土) 20:39:47.880293デフォルトの名無しさん
2011/04/02(土) 20:48:33.91>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++ の抽象化」も
> 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
> これらすべての設計上の決定のために、できてきた結果はゲロゲロで
> 保守不可能なカオスだ。
0294デフォルトの名無しさん
2011/04/02(土) 20:49:36.36ｹﾁｮﾝｹﾁｮﾝだなｗ
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 は思ったのだろう。
0295デフォルトの名無しさん
2011/04/02(土) 23:53:55.070296デフォルトの名無しさん
2011/04/03(日) 01:08:09.170297デフォルトの名無しさん
2011/04/03(日) 02:51:43.75まあでもCVSの代替としては長く使わせてもらったし、あの時点では最良だったと思う。
0298デフォルトの名無しさん
2011/04/03(日) 03:14:47.450299デフォルトの名無しさん
2011/04/03(日) 21:22:38.970300デフォルトの名無しさん
2011/04/03(日) 21:26:45.16帯としても使える襷は無い、ということか。
0301デフォルトの名無しさん
2011/04/06(水) 22:47:50.27> 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.
0302デフォルトの名無しさん
2011/04/08(金) 10:18:19.21遅くてもこんな物なんだろうと思っているからきっと幸せ。
つーか、俺、最初に手をつけた物が良いという思い込みが強くて
なかなか移行できない性格で難儀。
0303デフォルトの名無しさん
2011/04/08(金) 11:24:36.98VSSに触らなくて良かったな
0304デフォルトの名無しさん
2011/04/08(金) 14:53:29.00オープンなリポジトリにそのままコミットするわけにはいかないと思うので。
0305デフォルトの名無しさん
2011/04/08(金) 14:56:19.22* sensibleなデータだけ別ファイルになるような構成にして、リポジトリに入れないようにする。
* 暗号化したものを入れておいてデコード手段はリポジトリに入れないようにする。
など。
0306デフォルトの名無しさん
2011/04/08(金) 15:38:36.190307デフォルトの名無しさん
2011/04/08(金) 17:35:21.28ありがとうございます。
0308デフォルトの名無しさん
2011/04/13(水) 14:20:21.44有名どころだけでも結構あるんだね。
数人で1プロジェクトのソースが100ファイルで合計1MBに満たない
ようなレベルならTortoiseSVNあたりで十分かな？
ネット上の情報も一番多い感じなので、取っつきやすいと感じた。
それとも、今から覚えるなら、こっちにしておけっていうのあります？
0309デフォルトの名無しさん
2011/04/13(水) 14:33:52.97TortoiseSVNってことはWin環境なんだろうけど、サーバー側はVisualSVN Serverを勧めておく。
さらにVisual Studio使ってて金が出せるなら、AnkhSVNよりVisualSVNがお勧め。
何だかんだ言って、インテグレーションの出来が違いすぎる。
0310デフォルトの名無しさん
2011/04/13(水) 15:48:40.56ありがとう。
ちょっとVisualSVN Server、VisualSVNこの辺を調べてくる。
名前が似てるけど、全然別物なのか。
0311デフォルトの名無しさん
2011/04/13(水) 19:54:25.29AnkhSVNもまあまあ悪くはないかと思ったけど
0312デフォルトの名無しさん
2011/04/13(水) 23:17:07.73今やってるプロジェクトはそれすら使っていないから
VS上でファイル名変更されると履歴が参照できずバージョン管理の意味が無くなってる。
0313デフォルトの名無しさん
2011/04/14(木) 02:06:48.180314デフォルトの名無しさん
2011/04/14(木) 02:18:52.780315デフォルトの名無しさん
2011/04/14(木) 05:50:39.51hg addremoveコマンドが推定。"--similarity 類似度"でパーセントを指定できる。
ファイルの移動はリポジトリに記録される。
0316デフォルトの名無しさん
2011/04/14(木) 14:42:44.77え、移動はリポジトリに記録される、けどリネームは推定なの？
リネームと移動は同じじゃないか…？
0317デフォルトの名無しさん
2011/04/14(木) 14:57:42.25hgのファイルの移動はコピーして削除。これはリポジトリ（マニフェスト）に記録される。
コピーしたものもマージ時に反映される。
ファイルの移動はhg renameコマンドを使うのが一般的。
hg addとhg removeコマンドがあって、それぞれ、ファイルを追加したとき、削除したとき、
パラメータ無しで追加、削除を自動的に認識するコマンド。
hg addremoveはそれを合体させたもので、--similarity 100がデフォルトの値で、
ファイルが改変されていないものは移動と認識されて、commit時にそれが反映される。
0318デフォルトの名無しさん
2011/04/14(木) 15:11:44.05＞これはリポジトリ（マニフェスト）に記録される
「コピーして削除」のみならず「移動」としての情報が記録されるということ？
つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな？
それとも--similarity 100の時だけ「移動」として特別に記録？
0319デフォルトの名無しさん
2011/04/14(木) 15:46:11.01> ＞これはリポジトリ（マニフェスト）に記録される
> 「コピーして削除」のみならず「移動」としての情報が記録されるということ？
リポジトリ（マニフェスト）には、コピーしたというのと削除したというのが別々に記録される。
aaa -> bbb
・bbbはaaaのコピー
・aaaは削除
> つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな？
> それとも--similarity 100の時だけ「移動」として特別に記録？
hg addremoveがファイルの移動をコピーと削除として判断する。
hg status のオプション"--copies"で確認可能。
この結果をcommitで確定させる。
0320デフォルトの名無しさん
2011/04/14(木) 17:17:45.25なるほど、そうなるとsvnと似たやり方かな。
Gitはそういうの一切記録しなくて、履歴を表示する時に動的に分析してる。
全く同時期に同じ目的で開発されたものだけど、けっこう違うんだねえ。
0321デフォルトの名無しさん
2011/04/15(金) 06:18:40.99http://blogs.atlassian.com/developer/2011/03/goodbye_subversion_hello_mercurial.html
0322デフォルトの名無しさん
2011/04/25(月) 09:25:35.79チャンクごとのコミットが面倒なことになってないかい
なんだよこれ
0323デフォルトの名無しさん
2011/04/25(月) 10:18:19.53TortoiseHg 2.0の大幅なユーザインターフェースの更新に抵抗がある方は、
1.1.xの最新版を使うことをお勧めします。
https://bitbucket.org/tortoisehg/stable/downloads
0324デフォルトの名無しさん
2011/04/25(月) 10:37:51.10よくみたらメジャーアップデートしてたんだ
日本語の方マニュアルやリリースノートも更新してくれればなあ！
0325デフォルトの名無しさん
2011/04/25(月) 20:04:58.45http://www.atmarkit.co.jp/news/201104/25/git.html
0326デフォルトの名無しさん
2011/04/25(月) 21:03:39.770327デフォルトの名無しさん
2011/04/25(月) 21:06:26.08使えるよ
0328デフォルトの名無しさん
2011/04/25(月) 21:09:21.90Win、Mac、Linuxの環境でsvnのように何の問題もなくなったの？
0329デフォルトの名無しさん
2011/04/25(月) 21:11:41.67さて、svnのどこが何の問題が無いのでしょうか？
0330デフォルトの名無しさん
2011/04/25(月) 21:37:51.11今、MercrialとBazaarを試用しているけれど、Gitも試してみるか。
0331デフォルトの名無しさん
2011/04/25(月) 23:10:29.20日本語のファイルの取り扱いが問題ありません
他はすべて日本語の扱いに問題有り
0332デフォルトの名無しさん
2011/04/25(月) 23:28:01.24つ>>8
svnも問題あり、というよりマルチプラットフォームで問題ないものは無い。
0333デフォルトの名無しさん
2011/04/25(月) 23:28:50.00それは既にパッチあるだろ
0334デフォルトの名無しさん
2011/04/25(月) 23:30:51.91何年前の話だよ…
0335デフォルトの名無しさん
2011/04/25(月) 23:51:51.890336デフォルトの名無しさん
2011/04/25(月) 23:53:23.910337デフォルトの名無しさん
2011/04/26(火) 00:20:04.65http://subversion.tigris.org/issues/show_bug.cgi?id=2464
bzrもだめです。
https://bugs.launchpad.net/bzr/+bug/172383
0338デフォルトの名無しさん
2011/04/26(火) 00:26:22.540339デフォルトの名無しさん
2011/04/26(火) 00:28:10.540340デフォルトの名無しさん
2011/04/26(火) 01:10:25.900341デフォルトの名無しさん
2011/04/26(火) 08:48:59.320342デフォルトの名無しさん
2011/04/26(火) 09:05:53.42Mac ports の svn は対応パッチ済みです。
bzr も完全に解決したかの確認がまだだけど、2.3で現在までに報告されている
ケースは解決されています。
Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の
扱いには満足していたんだし、Mac OS X の問題もとりあえず対応策が広まったし、
Unicodeでファイル名を扱うことを危険だと叫んでるのはただのFUD
Unicodeはすべての問題を解決してくれるわけではないが、文字コード周りの問題に
対するコストパフォーマンスの高い対応策。
0343デフォルトの名無しさん
2011/04/26(火) 09:15:25.50GitとMercurialでファイル名に「ユニコード」が使えないという誤解を相変わらずバラ撒いている方がFUD
0344341
2011/04/26(火) 09:21:33.190345デフォルトの名無しさん
2011/04/26(火) 09:22:06.40このスレでだれがそんなFUDを言ってる？
それとも、Mac OS X のNFD(モドキ)正規化問題に対応できてないというのがFUD？
0346デフォルトの名無しさん
2011/04/26(火) 09:22:54.02> Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の
> 扱いには満足していたんだし、
満足なんかしてないよ。
波ダッシュとかの問題とか考えれば、永続的にメンテが必要なシステムに
ファイル名変換が行われるものなんか使わないよ。
0347デフォルトの名無しさん
2011/04/26(火) 09:23:56.85Windowsでばーかというファイルを作成してMacでチェックアウトして
編集せずに git diff したら、何もしてないのにファイル名が変更されたって
報告されない？
0348デフォルトの名無しさん
2011/04/26(火) 09:26:52.41つ>>208
0349デフォルトの名無しさん
2011/04/26(火) 09:27:11.56GitHubにでもレポ作ってくれれば試すよ
興味あるし
0350デフォルトの名無しさん
2011/04/26(火) 09:30:01.93たしかに、みんなは言い過ぎだな。
でも、波ダッシュ問題もWindowsだったらUTF-16で、LinuxやMacではUTF-8で扱えば
一切Shift-JISとの変換なんて起こらないし、多くの人は一部の文字が使えない
ことよりもリポジトリ内に複数の文字エンコーディングのファイル名が混ざる事や
たくさんの独自パッチ済みクライアントが乱立する方が管理が面倒だと感じて
CVSからSubversionへの変化を喜んでいた。
WinCVS日本語版でみんなこのオプション使いましょーねというルール決めても時々
設定間違ってコミットする人がいてリポジトリの内容が文字化けしていた時代に
戻りたいという人がどれくらいいるか。
0351デフォルトの名無しさん
2011/04/26(火) 09:30:43.31gitは知らんが、hgはMacユーザがaddremoveすればWin/Linux/Macユーザみんなハッピー
0352デフォルトの名無しさん
2011/04/26(火) 09:34:07.00https://gist.github.com/941544/
git clone git://gist.github.com/941544.git
0353デフォルトの名無しさん
2011/04/26(火) 09:35:06.00Windows の hg って utf-8 ファイル名まともに使えるようになったんだっけ？
0354デフォルトの名無しさん
2011/04/26(火) 09:36:39.26cygwin、fixutf8
0355デフォルトの名無しさん
2011/04/26(火) 09:37:13.47あと、その方法だとLinux/Winユーザーがpullしてファイル名がNFDになると、
コマンドラインからファイル名指定するときに普通に日本語入力システムで
変換するとNFCになっちゃうからファイル名指定できなくて全然ハッピーじゃない。
0356デフォルトの名無しさん
2011/04/26(火) 09:39:58.20fixutf8 ってもう安定して使えるのかな。TortoiseHGとの連携大丈夫？
cygwinを使う方法については、cygwinが必要だというのを明示せずに
「utf-8使えるよ」というのは、まどかシステム以前のQBのような気がするので、
ちゃんと「cygwin使えばutf-8使えるよ」と言って欲しい。
0357デフォルトの名無しさん
2011/04/26(火) 09:40:24.04hgでコマンドラインでファイル名指定するのはhg log FILEぐらい。
hg add/remove/addremoveは自動認識するし。
0358デフォルトの名無しさん
2011/04/26(火) 09:43:16.46チェックアウトしたファイルを開こうとして
$ vim ばーか.txt
ってやる場合を考えると、hgで直接ファイル名指定する機会が少ないというのは
リポジトリ内にNFDを突っ込む問題の一部しかカバーできてないと思う。
0359デフォルトの名無しさん
2011/04/26(火) 09:47:23.72日本語を使うのなら、、
集中型ならsvn
分散型ならbzr
日本語は使わないのなら、、
速いのが好きならgit
googleが好きならhg
0360デフォルトの名無しさん
2011/04/26(火) 09:49:21.95たしかに「ば」が先頭だとシェル補完が厳しいなぁ・・・
0361デフォルトの名無しさん
2011/04/26(火) 09:49:36.10git diffだと何も表示されないがgit statusだとUntracked fileとして表示されるね
WindowsのMsysGitを使った場合だとLinuxやMacではこういうことが起きるのか
勉強にはなったが、どうしようかなあ
0362デフォルトの名無しさん
2011/04/26(火) 10:40:10.090363デフォルトの名無しさん
2011/04/26(火) 11:18:24.430364デフォルトの名無しさん
2011/04/26(火) 11:23:43.490365デフォルトの名無しさん
2011/04/26(火) 11:29:07.240366デフォルトの名無しさん
2011/04/26(火) 13:08:35.45英語にしてもそこそこ把握できる場合（予想）
『ワルプルギスの淫夢.txt』
『奴隷少佐ルクレツィア.txt』
英語にしたら把握に時間がかかるか訳がわからない場合（予想）
『目覚めると従姉妹を護る美少女剣士になっていた.txt』
『俺のフラグはよりどりみデレ.txt』
というような場合もあるんじゃないかな？
仮定、想像の話だけど。
0367デフォルトの名無しさん
2011/04/26(火) 13:36:52.35それはそれとして、そのtxtの中身について話をしたいのだが。
0368デフォルトの名無しさん
2011/04/26(火) 13:45:20.85何分、仮定、想像の話なので。
0369デフォルトの名無しさん
2011/04/26(火) 14:22:22.90Windowsはutf-16 のAPIを提供しているのでそれを使えば問題ない。
どっちかっつーと、Mac OS X の方が、バージョン管理システムに限らず
ファイルをアップロードするときとか、zipファイルの中身とかいろんな
場面に影響するので凶悪。
0370デフォルトの名無しさん
2011/04/26(火) 14:49:34.62ファイル名の話してんのに何言ってんの？
論点のすり替え乙
0371デフォルトの名無しさん
2011/04/26(火) 16:19:32.78ファイル名の話だよ？
Windowsは10年以上昔(NT 4.0)からファイル名はUnicodeで扱っている。
Shift-JISなどでアクセスするAPIはレガシー用の互換APIで、基本的に使うべきではない。
0372デフォルトの名無しさん
2011/04/26(火) 16:23:47.02のぞいたらWinXP (01年) だから、10年以上ではないな。
0373デフォルトの名無しさん
2011/04/26(火) 16:24:17.13話だろ？
0374デフォルトの名無しさん
2011/04/26(火) 16:24:26.870375デフォルトの名無しさん
2011/04/26(火) 16:25:13.49最新レス見ずに書いちゃった
0376デフォルトの名無しさん
2011/04/26(火) 16:27:30.17Python はどちらでも扱えるようにしている。
open(u"ほげ") ならUnicode APIで、open("ほげ") ならASCII APIを使う。
bzrは前者、mercurialは後者を使ってる。
cygwin は、 fopen("ほげ"); すると、 "ほげ" を utf-8 でデコードして、
UTF-16にエンコードして、 CreateFileW に渡している。
0377デフォルトの名無しさん
2011/04/26(火) 16:31:31.57それがクソって言ってんの
0378デフォルトの名無しさん
2011/04/26(火) 16:34:02.13えー、これがクソならどうしろと、、、
C#やJavaみたいにバイト列でファイルパスを指定するの禁止したらUnix系で
すごく使いにくくなるんだけど。
Python の仕様は超現実的で、RubyやPerlよりもずっとWindowsで使いやすいと
思ってる。
0379デフォルトの名無しさん
2011/04/26(火) 17:11:59.630380デフォルトの名無しさん
2011/04/26(火) 18:26:12.29http://mercurial.selenic.com/wiki/EncodingStrategy
0381デフォルトの名無しさん
2011/04/26(火) 18:29:23.48英語のwikiにはNTFSはUTF-16となっているが、実際は２バイトのバイト列。
UTF-16としては不正な値も格納される。
0382デフォルトの名無しさん
2011/04/26(火) 18:33:09.11> kernel has a mix of byte-width and wide character APIs
0383デフォルトの名無しさん
2011/04/28(木) 10:45:25.11Git、Mercurial、Bazaarから、上記の条件で考えた場合、分散型初心者が取っつき
やすいのは日本語対応が進んでいるBazaarでしょうか？
0384デフォルトの名無しさん
2011/04/28(木) 11:04:37.410385デフォルトの名無しさん
2011/04/28(木) 11:10:24.250386デフォルトの名無しさん
2011/04/28(木) 11:15:43.07でかいファイルを扱うならhgかな
0387デフォルトの名無しさん
2011/04/28(木) 11:16:05.67Mercurialが一歩抜き出ていて、CUI/GUIのメニューは >>325 でGitも対応する方向だと言う認識だが。
0388デフォルトの名無しさん
2011/04/28(木) 11:18:50.31githubの方がもっといいけど
0389デフォルトの名無しさん
2011/04/28(木) 11:19:07.53他は何をやってんのやら。
0390デフォルトの名無しさん
2011/04/28(木) 11:23:24.89> 分散だと日本語環境はbzrが独占状態なのよねぇ。
> 他は何をやってんのやら。
「Windowsのファイルシステムの」日本語環境でしょ。
Windows上で日本語ファイル名を使わなければ、Git、Mercurialでは何も不自由しないけど。
0391デフォルトの名無しさん
2011/04/28(木) 11:27:13.00○○支社向け.docとか
○○部長月間予定.xlsとか
いう日本語ファイル名って結構使うからねぇ
0392デフォルトの名無しさん
2011/04/28(木) 11:31:50.17リポジトリを分ければ良い。
そういうファイルがあるところだけsvnにすれば良い。
svnはリポジトリを一ヶ所にするというのが一般的のようだが、
別に一ヶ所にする必要もない。
0393デフォルトの名無しさん
2011/04/28(木) 11:35:09.66後々の事を考えてシンプルにしないとさ
0394デフォルトの名無しさん
2011/04/28(木) 11:46:48.220395デフォルトの名無しさん
2011/04/28(木) 11:48:38.19CP932に無いUnicodeの文字も増えてきているからねえ・・・
0396デフォルトの名無しさん
2011/04/28(木) 14:21:26.83どうせマージ出来ないだろうから、むしろ分散してたら不都合な気がする。
そういうのはsvnでいいんじゃね。
0397デフォルトの名無しさん
2011/04/28(木) 14:50:19.02Mercurialはロックを実装する気でいるぞ。
http://mercurial.selenic.com/wiki/LockExtension/NewDesign
0398デフォルトの名無しさん
2011/04/28(木) 15:39:09.50分散型でlockとかｗｗｗ
というのは釣りですが、それでワークフローがうまく回るなら良いですね。
特に仕事でアジャイル（）とかだと分単位で作業が入り乱れるだろうから、
バグトラッカとかでやりとりするよりもスムーズかも知れない。
0399デフォルトの名無しさん
2011/04/28(木) 15:39:15.31結局のところ、運用でごまかせって感じになっているのがなぁ。
誰だよ1バイト圏意外に住んでいるやつは。
0400デフォルトの名無しさん
2011/04/28(木) 16:10:18.30中央リポジトリ関係無く好きに各ローカルリポジトリにプッシュ/プル出来るから分散のメリットは大ありだよ
人間の相関と分散管理はすごく相性がいいから無駄なんていっちゃいかん
0401デフォルトの名無しさん
2011/04/28(木) 16:13:02.54○不都合だなんて
失敬
0402デフォルトの名無しさん
2011/04/28(木) 16:41:36.52ワードとかエクセルのマージ作業はどうするの？
0403デフォルトの名無しさん
2011/04/28(木) 16:43:59.180404デフォルトの名無しさん
2011/04/28(木) 16:49:45.42マスターリポジトリにプッシュするまでもない物をとりあえず確認するために
個人のローカルリポジトリにアクセスしたりとか
個別相談受けて訂正する時にその人のローカル除いたりとか色々ある
メッシュ網じゃないsvnなんかじゃこういうのは出来ないのさ
0405デフォルトの名無しさん
2011/05/01(日) 14:39:55.41バイト列なら>>376の言うようにPythonが対応しようが解決できないよね、これ
BazaarのようにUnicodeと決めているならUnicode APIに渡すときに変換なりするわけでしょ
でもバイト列で扱う方針なら変換できないよね
localeに応じて変換するのだろうか
マルチバイトのファイル名のマルチプラットフォームの問題はそもそも解決できない問題なの？
0406デフォルトの名無しさん
2011/05/01(日) 15:02:14.19やろうと思えば主要ファイルシステムの動作をエミュレートできるようにしたうえで、addした時のファイルシステムを覚えておくことになるだろうし。
それとは別に、必要な変換をしてくれないのは単なる無理解と手抜き。
gitについてはLinux上で最高のパフォーマンスが出せれば後はどうでもいいという大義名分があるけど、hgは単に開発者が無理解なだけだろ。
(bzrの互換漢字を正規化してしまう問題も、そんなことをするファイルシステムが現存しない以上やり過ぎと言える)
0407デフォルトの名無しさん
2011/05/01(日) 15:18:23.72・欧米人はファイル名にCP1252(ISO-8859-1)が使えれば満足
・欧米人はLinuxでもファイル名はISO-8859-1を使っている
・Linux/UnixでロケールをUTF-8にしているのは日本人が主
・日本人はLinuxでEUC-JP/Shift_JIS/UTF-8の混在に慣れているが、これは日本の特殊事情
0408デフォルトの名無しさん
2011/05/01(日) 15:23:53.14> hgは単に開発者が無理解なだけだろ。
無理解とは思えないが。
http://mercurial.selenic.com/wiki/EncodingStrategy
cmd.exeとGUIアプリの扱いが違うというのは、このスレでは話題になっていなかったが。
bzrがcmd.exeでCP932の方が無理解だと思うが。
0409デフォルトの名無しさん
2011/05/01(日) 15:29:36.71cmd.exeでもW版APIを使えばokというのが周知されてないのも無理解の象徴だな
0410デフォルトの名無しさん
2011/05/01(日) 15:33:04.46cmd.exeでwは使えない。
wprintf()がcp932とかcp1252の時にデータが欠損する。
0411デフォルトの名無しさん
2011/05/01(日) 15:35:38.99bzrでお馴染みのpythonのコーデックエラーは、cmd.exeのことを考慮していない証拠。
0412デフォルトの名無しさん
2011/05/01(日) 15:37:30.80libcではなく自分でAPI呼べよ
0413デフォルトの名無しさん
2011/05/01(日) 15:45:46.84chcp 1252 して日本語混じりのをwprintfしたら何が出力される？
だったら、printfでバイト列で出力した方がマルチプラットフォームアプリとしては
正しいと思うが。
0414デフォルトの名無しさん
2011/05/01(日) 16:09:39.19cmdでUnicode使わない背景には、cmdのフォントの設定によっては表示されない
恐れがあるからという理由があったはず。
まぁ、一番は単に他の部分のファイルのインタフェースと整合性を取るのが大変
だからだろうけど。
CLIでunicode使いたかったら cygwin + minitty が最強。
0416デフォルトの名無しさん
2011/05/01(日) 16:14:13.63得体の知れないバイト列をANSI版APIに流し込む矛盾。
0417デフォルトの名無しさん
2011/05/01(日) 16:15:14.84出力って何のこと？diffとか？
0418デフォルトの名無しさん
2011/05/01(日) 16:18:07.25CP932と繁体字がASCIIと互換が無いから問題なのであって、
それ以外のコードページとLinuxでは、シングルバイト用のAPIで何ら問題が無い。
0419デフォルトの名無しさん
2011/05/01(日) 19:18:31.36さすがPowerShell ISEさんに隙はなかった・・・
0420デフォルトの名無しさん
2011/05/01(日) 19:21:34.79Mercurialは--encodeオプションかHGENCODING環境変数で、UTF-8が指定できるから、
PowerShellでも問題ない。これが正しい多言語化。
0421デフォルトの名無しさん
2011/05/01(日) 19:23:30.72--encodingmodeってのもある。
0422デフォルトの名無しさん
2011/05/01(日) 19:40:05.99や、俺が言ってるのはコンソールとしてのpowershell_ise.exeのことね
chcpコマンドがまともに機能するWin7標準のアプリ
従来の対話型コマンドが動作しないのが玉に瑕
0423デフォルトの名無しさん
2011/05/01(日) 20:00:58.60PowerShell ISEってフルで言わないとだめなのか。
PowerShell ISEでMercurialでchcp 65001が最強。
0424デフォルトの名無しさん
2011/05/01(日) 20:09:01.55うん、同意
0425デフォルトの名無しさん
2011/05/01(日) 20:26:56.000426デフォルトの名無しさん
2011/05/02(月) 12:10:01.43そのwprintfはwcstombsしてるんだろ。
まずWriteConsoleWでUTF-16のまま無変換出力を試みる
→エラーになったらコンソール以外にリダイレクトされてるから
保存用コード(ロケール使うのが正しいがオプションでUTF-8を提供してもいい)に変換して改めてWriteFile
がWindowsでの正しいUnicode対応コンソールアプリの作り方。
0427デフォルトの名無しさん
2011/05/02(月) 12:10:24.540428デフォルトの名無しさん
2011/05/02(月) 12:29:52.71Mercurialはファイル名とファイルの中身以外は内部UTF-8なんだからwcstombsを使う理由が無い。
http://mercurial.selenic.com/wiki/EncodingStrategy#Functions
にある通り、fromlocal()、tolocal()、colwidth()という関数が用意されている。
0429デフォルトの名無しさん
2011/05/02(月) 12:35:44.01すまん、アンカーミスなんだ。
元はcmd.exeでWが使える使えないの話の流れなんだ。hgの実際の実装は関係ないんだ。
0430デフォルトの名無しさん
2011/05/02(月) 12:50:32.48バージョン管理と何の関係があるの？
0431デフォルトの名無しさん
2011/05/04(水) 12:27:28.61シェルとして使いにくいのが悲しい点
0432デフォルトの名無しさん
2011/05/17(火) 18:26:14.74gitスレで聞いたんだが基本的に存在しないらしい。
svnから物凄い機能後退だと思うのだけど、
bzrとかhgとか或いは、darcsとかmonotoneでも
出来ないのが通常なのだろうか？svnでは
svn diff -r 123:456 svn://server/repo/trunk
とかで出来たと思うんだけど。
0433デフォルトの名無しさん
2011/05/17(火) 18:30:32.510434デフォルトの名無しさん
2011/05/17(火) 19:17:16.190435デフォルトの名無しさん
2011/05/17(火) 19:31:10.280436デフォルトの名無しさん
2011/05/17(火) 19:38:27.23集中型じゃなくて分散型の思想について勉強してこいよ
0437デフォルトの名無しさん
2011/05/17(火) 19:39:28.240438デフォルトの名無しさん
2011/05/17(火) 20:03:09.130439デフォルトの名無しさん
2011/05/17(火) 20:05:44.300440デフォルトの名無しさん
2011/05/18(水) 00:19:30.76全部できないのか。酷い有様だな。
0441デフォルトの名無しさん
2011/05/18(水) 00:40:23.29ssh gesonari@kimoi /usr/bin/git --git-dir=/svn/nou diff v0.1 v0.2
0442デフォルトの名無しさん
2011/05/18(水) 01:42:52.29bzrはできる。
0443デフォルトの名無しさん
2011/05/18(水) 02:05:27.82タダの基地外なんだから。
0444デフォルトの名無しさん
2011/05/18(水) 02:07:36.820445デフォルトの名無しさん
2011/05/18(水) 02:50:35.02最近はそうでもないぞ。
といっても、Windows以外のユーザーが最新のbzrを使うにはソースから
インストールするかFedoraかUbuntuの最新版を使わなきゃいけないけど。
0446デフォルトの名無しさん
2011/05/18(水) 08:46:27.06＞変わってしまってかなり機能後退と分かりゲンナリです。
このソフトって何だろうね。
意図せずGitHubに移行しなきゃいけなくなってゲソナリってことみたいだけど、
そこまでイライラするぐらいなら古いバージョンでsvn+trac使うことは出来ないのかな？
0447デフォルトの名無しさん
2011/05/18(水) 08:50:26.59おまえの頭がな
0448デフォルトの名無しさん
2011/05/18(水) 09:23:18.91svnがキモくて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 も結構追いつきつつある(と思う)。
> あんまり日本語ファイル管理することもないんだけどね。
0449デフォルトの名無しさん
2011/05/18(水) 11:36:09.86svnはリモート見に行く必要は無いんだが何いってんの?
0450デフォルトの名無しさん
2011/05/18(水) 11:47:33.18それは作業領域の話。
特定のリビジョン間のdiffを見る場合、リモートを見に行く必要がある。
0451デフォルトの名無しさん
2011/05/18(水) 12:03:07.870452デフォルトの名無しさん
2011/05/18(水) 12:22:45.760453デフォルトの名無しさん
2011/05/18(水) 17:26:11.890454デフォルトの名無しさん
2011/05/18(水) 18:58:53.50いや、最近久し振りに使ったら遅くて泣けた・・・
0455デフォルトの名無しさん
2011/05/18(水) 19:33:53.77毎日使ってるけど、遅くて泣きたくなるのは、画像ファイルとかバイナリファイルを
たくさんリポジトリに突っ込んじゃった場合だけ。
どんな状況で遅かった？手元のバージョンが良くてもサーバー側のバージョンが
悪かったりしない？
0456デフォルトの名無しさん
2011/05/18(水) 19:35:04.65launchpadの遅さは異常
0457デフォルトの名無しさん
2011/05/18(水) 21:00:36.69試しにやってみたら、 bzr branch lp:mysql-server が 73771 リビジョンの
ブランチに 16m37sec かかった。
速いとは言わないけど、別に1日たっても終わらないとかじゃないし、最初の
1回だけだし、十分実用的な速度だと思う。
github や bitbucket に mysql のミラーないかな？
0458デフォルトの名無しさん
2011/05/18(水) 21:08:09.6116分とか一瞬だった
0459デフォルトの名無しさん
2011/05/18(水) 21:08:55.410460デフォルトの名無しさん
2011/05/18(水) 21:14:56.64Linuxカーネルは？
bitbucketじゃないところにhgのミラーはあるよ。
確かhgのポリシーにのっとって、バージョン毎にリポジトリが分かれていたから、
単純比較できないかもしれないけど。
0461デフォルトの名無しさん
2011/05/18(水) 21:16:19.31real 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 の方が速いんだろうけど、別に泣きたくなるほど遅くはないな。
0462デフォルトの名無しさん
2011/05/18(水) 21:21:40.340463デフォルトの名無しさん
2011/05/18(水) 21:27:44.57初回はどー考えてもsvn有利だろw
0464デフォルトの名無しさん
2011/05/18(水) 21:43:00.220465デフォルトの名無しさん
2011/05/18(水) 21:45:41.86$ time bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk emacs-trunk
real 17m46.033s
user 7m24.300s
sys 0m15.460s
2月辺りにはなんか問題あったらしいけど、改善されたらしいね。
0466デフォルトの名無しさん
2011/05/18(水) 22:00:37.84したら5分弱だった。emacsの場合はgitの方が4倍くらい速いな。
とりあえず、一晩たっても終わってないとかそういうのはなさそうだから、
実用上問題にはならないだろ。
0467デフォルトの名無しさん
2011/05/18(水) 22:02:22.21hgから乗り換えるかな
0468デフォルトの名無しさん
2011/05/18(水) 22:39:21.80インターネット越しじゃなくて、イントラネットでも。
0469デフォルトの名無しさん
2011/05/18(水) 22:47:37.120470デフォルトの名無しさん
2011/05/18(水) 23:47:49.940471デフォルトの名無しさん
2011/05/18(水) 23:53:10.750472デフォルトの名無しさん
2011/05/19(木) 00:29:13.450473デフォルトの名無しさん
2011/05/19(木) 00:32:44.030474デフォルトの名無しさん
2011/05/19(木) 00:35:21.890475デフォルトの名無しさん
2011/05/19(木) 00:37:37.150476デフォルトの名無しさん
2011/05/19(木) 00:49:17.800477デフォルトの名無しさん
2011/05/19(木) 00:53:13.72GitHub vs Google Codeか。Launchpadはいまいち人気無いよね。
0478デフォルトの名無しさん
2011/05/19(木) 00:54:05.800479デフォルトの名無しさん
2011/05/19(木) 01:05:32.02必要な情報が無駄無く配置されていて使い勝手がとても良い
0480デフォルトの名無しさん
2011/05/19(木) 02:24:14.680481デフォルトの名無しさん
2011/05/19(木) 08:05:41.81githubのruby、trunk以外のブランチも入っているじゃん
0482デフォルトの名無しさん
2011/05/19(木) 08:10:45.02http://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.
0483デフォルトの名無しさん
2011/05/19(木) 08:17:10.66まともに使えないってことだ。
0484デフォルトの名無しさん
2011/05/19(木) 11:17:07.01うん、完全に同じ条件ではないとあとで気づいた。
だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
してはあながち的外れな比較でもないと思う。
まぁ、やりたかったことは、bzrとgitのどっちが速いかを調べることではなくて、
一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
一晩経って終わらないとかそういう事が無いことが確認できただけで満足。
本気で比較したかったらLAN上で帯域やレイテンシやパケロス率を制御した環境を
作れるはずだけど面倒なのでパス。
0485デフォルトの名無しさん
2011/05/19(木) 18:55:21.88> 一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
> 遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
> 一晩経って終わらないとかそういう事が無いことが確認できただけで満足。
launchpadにアカウントを持っている人が一部の人では？
Emacsはlaunchpadではないけど、github・bitbucketに比べてcloneが目に見えて遅いのは
普通の感覚だと思うが。
0486デフォルトの名無しさん
2011/05/19(木) 19:06:38.32> だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
> ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
> してはあながち的外れな比較でもないと思う。
git・hgはリポジトリに全部のブランチを入れるかブランチ毎にリポジトリを分けるか、
柔軟性があるけど、bzrはブランチ単位でしかcloneできないんじゃないの？
githubのrubyはgit-svnを叩いているから、ブランチだらけの状態だと思うけど。
0487デフォルトの名無しさん
2011/05/19(木) 19:31:26.640488484
2011/05/19(木) 19:43:50.43いやだから厳密な比較をしたいとかじゃなくて単に使い物にならないくらい遅いか
どうか調べたかっただけなんだって。
誰も 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に敵わないけど、遅いという印象を払拭するには
インタフェース面でもできることがありそう。
0489デフォルトの名無しさん
2011/05/19(木) 20:05:06.73git cvsimportやらgit-svnやらhgsubversionやらhg convertの最初の一回目が遅いのは当たり前。
だから、rubyのgithubみたいにミラーがあるんじゃない？
一回cloneすれば、その後のpullは差分だけど、そのpullもbzrは重いって指摘は
ぐぐればいっぱい出てくるけど？
0490デフォルトの名無しさん
2011/05/19(木) 20:55:28.09これよそでは言うなよ恥ずかしいから
0491484
2011/05/19(木) 20:56:45.77厳密な比較は面倒だからしないけど、きっとgitやhgよりも遅いんだろうな。
でも、俺は実用的な速度だと思ってるから使い続けてる。MySQLだって
あれだけ大きいプロジェクトで本当に使い物にならないほど遅かったら
とっくに乗り換えてるだろ。
bzrが実用にならないほど遅いという結論がでないとなにか困るの？
0492デフォルトの名無しさん
2011/05/19(木) 21:06:22.87常識で考えてGitが速すぎるんだよ。
clone中のあのいかにも速そうなインジケータとか、最初に何となくやるであろう
Linuxカーネルのcloneの速度とか、最初から狙ってると思う。
0493デフォルトの名無しさん
2011/05/19(木) 21:06:25.30今使ってる人は使い続ける理由が欲しいだろうけど、今使ってなければ
別に思い入れもないし、遅いのが嫌なら bzr は選ばないでしょ
0494デフォルトの名無しさん
2011/05/19(木) 21:08:39.82MySQLは万人がハックしてパッチを送るタイプのプロジェクトでないでしょ。
Emacsのビルドにbzrに接続することを要求されて、それで、bzrの重さの認識が一気に浸透したと思うけど。
cvs、svnもゼロから始めるソースはそんなに重くないけど、
だんだん重くなるよね。
bzr信者は感覚が麻痺しているんじゃないの？
cvsがデファクトスタンダードでsvnがそれに置き換わるかと思われたけど、
svn離れが加速しているよね？
遅いものは主流になり得ないというのは歴史が証明していると思うけど。
0495484
2011/05/19(木) 21:28:36.76別に bzr が今後も主流になりえないかもしれないけど、Canonicalが潰れる
までは衰退することもないし、その時に考えるからいいよ。
俺は単に使い物にならないほど遅いとdisられがちだから本当にそんなに
遅いのか実験してみて、俺に取っては許容範囲だと判断しただけ。
Emacsの件はいろいろ不幸だった。savannahのサーバーのセットアップが
悪かったり、タイミング的に bzr 2.1 以前を使ってるユーザーがまだ
多かったり (lennyのデフォルトのbzrなんて1.5とかいう使い物にならない古さ)
したからな。
0496デフォルトの名無しさん
2011/05/19(木) 21:58:52.05> だんだん重くなるよね。
svn の場合、ファイルシステム(リポジトリのフォーマットのこと)によって違うよね。
以前の bdb の場合はリビジョンが増えてもチェックアウトは速かったけど、
今のデフォの fsfs の場合はリビジョンが増えるとチェックアウトが遅くなる。
その半面、 fsfs ではホットコピーが簡単になり、壊れなくなったけど。
0497デフォルトの名無しさん
2011/05/19(木) 22:46:24.95他にもキーボード配列とか文字エンコーディングとかあるけどね。
0498デフォルトの名無しさん
2011/05/19(木) 22:48:09.06Lisperの一人として胸厚だわ
0499デフォルトの名無しさん
2011/05/19(木) 23:22:30.260500デフォルトの名無しさん
2011/05/19(木) 23:23:19.530501デフォルトの名無しさん
2011/05/20(金) 02:31:50.69今はこんな感じか。
hgの一時の勢いはどこへやら。
0502デフォルトの名無しさん
2011/05/20(金) 10:02:32.19git、hg、bzrからhgを選んで導入も終えてそこそこ使えるようになってきたのに、
だれだよオワコンとか言うのは！
0504デフォルトの名無しさん
2011/05/20(金) 10:26:12.382chのスレの勢いだとそうかもね。
hgの場合、日本語で語れる場所が他にもあるから。
そこで取り上げられていた、このスレに絶好のネタが2chでは取り上げられていないし、
住み分けができてるんじゃない？
0506デフォルトの名無しさん
2011/05/22(日) 15:25:09.20それもひっくるめてgitが糞という評価になるんだが。
0507デフォルトの名無しさん
2011/05/22(日) 15:34:57.360508デフォルトの名無しさん
2011/05/22(日) 15:36:55.32UTF-8ではなくUTF-16になるから、#ifdefが必要になるだけで。
0509デフォルトの名無しさん
2011/05/22(日) 15:54:48.60Linux使ってる人が「VSSはLinuxで使えないから糞」なんて言わないからな。
別の意味では言ってるかも知れないが。
0510デフォルトの名無しさん
2011/05/22(日) 20:06:41.36svnのmac portsのような対応をgitに望んでいるのか？
0511デフォルトの名無しさん
2011/05/22(日) 22:17:58.55TortoiseGIT(笑)はそうじゃないんだよな
それを導入することによりよっぽど捗るとか利点がない限り
そんなまんどくせーものわざわざ手間かけてまでつかわねえよ
0512デフォルトの名無しさん
2011/05/22(日) 22:34:06.03CVSとSVNのパフォーマンスとマージに満足なのですね？
CVSとSVNのマージはまんどくさくないのですね？
0513デフォルトの名無しさん
2011/05/22(日) 22:36:49.97VSSがいいといっても見向きもしないでしょ、その人達は
文句を言うときは実装と一緒
gitがいいという話を聞いてうっかり使ってしまい文句のみを垂れ流す、それがWindowsユーザー
と、こんな風なレスを期待しているのか？
不毛じゃね？
0514デフォルトの名無しさん
2011/05/22(日) 22:46:18.29> VSSがいいといっても見向きもしないでしょ、その人達は
VSSが糞なのは周知
0515デフォルトの名無しさん
2011/05/23(月) 02:37:25.78自分の使わない機能がいくら速かろうが関係ないの
おわかり?
0516デフォルトの名無しさん
2011/05/23(月) 03:47:00.340517デフォルトの名無しさん
2011/05/23(月) 07:24:45.37TortoiseCVS(笑) TortoiseSVN(笑)
0518デフォルトの名無しさん
2011/05/23(月) 11:12:04.02使わないんじゃなくて使い方がわからないんだろ
おわかり?
0519デフォルトの名無しさん
2011/05/23(月) 15:38:59.330520デフォルトの名無しさん
2011/05/23(月) 16:34:02.130521デフォルトの名無しさん
2011/05/23(月) 18:52:26.430522デフォルトの名無しさん
2011/05/23(月) 19:42:43.91おかわり?
0523デフォルトの名無しさん
2011/05/23(月) 19:46:03.610524デフォルトの名無しさん
2011/05/23(月) 23:22:47.090525デフォルトの名無しさん
2011/05/23(月) 23:33:47.28もっと良い奴あるの?
0526デフォルトの名無しさん
2011/05/24(火) 02:08:17.45？
0527デフォルトの名無しさん
2011/05/25(水) 00:03:05.80SugarSync
0528デフォルトの名無しさん
2011/05/25(水) 00:15:54.04どこら辺がいいの?
0529デフォルトの名無しさん
2011/05/25(水) 13:11:25.380530デフォルトの名無しさん
2011/05/25(水) 19:27:34.810531デフォルトの名無しさん
2011/06/24(金) 22:06:52.17https://github.com/blog/878-announcing-github-for-mac
0532デフォルトの名無しさん
2011/07/16(土) 22:33:02.35http://code.google.com/p/support/issues/detail?id=2454#c43
0533デフォルトの名無しさん
2011/07/17(日) 06:34:06.08http://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.
0534デフォルトの名無しさん
2011/07/17(日) 06:35:50.300535デフォルトの名無しさん
2011/07/25(月) 19:55:07.99まるっとバージョン管理するには何使ったらいいの
0536デフォルトの名無しさん
2011/07/25(月) 20:10:57.220537デフォルトの名無しさん
2011/07/25(月) 20:23:18.860538デフォルトの名無しさん
2011/07/25(月) 20:35:40.84え？dropboxってバージョン管理できたの？別スレで
ttp://d.hatena.ne.jp/shibamu/20101014/p1
見て阿呆かと思ったけど意味があったのか…
>>537
同期して管理する必要が無いんだったら分けた方が良い、かも。
無関係なもの一緒くたにすると重くなりがちなので。
0539デフォルトの名無しさん
2011/07/25(月) 20:37:19.91サーバのオプションどうなってるんだろうね。
sf.jpはrebaseできないの知らなくてすげー困ったんだけど。
0540デフォルトの名無しさん
2011/07/25(月) 20:45:00.76俺もソースツリーのバックアップを dropbox に置いてるけど、何か問題あるのか?
バージョン管理は別途ツールを使ってるよ
0541デフォルトの名無しさん
2011/07/25(月) 20:51:32.69>>538はバックアップじゃねーぞ
0542デフォルトの名無しさん
2011/07/25(月) 20:59:01.78dropbox のディレクトリは単なるローカルのディレクトリでしょ
ビルドしてオブジェクトファイルが更新されたらバックグラウンドで
アップロードが走るのが嫌とか、そういう話?
0543デフォルトの名無しさん
2011/07/25(月) 21:15:46.510545デフォルトの名無しさん
2011/07/25(月) 21:50:02.80で、どんな得ろ画像だ? JSと熟女と太めは歓迎なので俺とトモダチになれ。
0546前スレ989
2011/07/25(月) 22:03:47.450547デフォルトの名無しさん
2011/07/26(火) 00:04:51.49ソースの管理には向かないが、画像の管理にはそこそこ便利。
で、ソースのバックアップをdropboxに置くくらいなら、リポジトリを置いてしまうのも手。
0548デフォルトの名無しさん
2011/08/19(金) 23:24:45.47ブランチを渡り歩くことってできる？
イメージとしてはbazaarで複数ブランチを同時にいじってて放置したまま
ブランチ間をcdで移動するみたいな。
diffとかはファイルとしての実体は不要でいいんだけど
gitは未コミット分をかかえたままになるのがちょっと困ってる。
いちいちstashとか嘘commitとかするのは
その判別含めて自動化できないと面倒で…。
0549デフォルトの名無しさん
2011/08/19(金) 23:28:19.520550548
2011/08/19(金) 23:40:47.88Mercurial の Shelve って git の stash と完全に同等に見えるけれど、そうでもないの？
0551デフォルトの名無しさん
2011/08/19(金) 23:45:29.57ファイルごとに退避ができてstashより便利だなーって思った覚えが。
0552デフォルトの名無しさん
2011/08/19(金) 23:50:55.94ブランチの数だけcloneしたら？
0553548
2011/08/19(金) 23:57:29.95自分も一旦はそう考えたんだけど、それだと結局bazaarと同じ運用になって、共有リポジトリ使えない分だけ損してるような…。
ツリーは1つ、というのが気に入ってbazaarからgitに移行しようかと試してるんだけど
標準ではサポートされない（というか人気のない？）使い方なのかな。
0554548
2011/08/20(土) 02:26:16.94あとから追いやすくなるのでコミットは意味ごとに独立させるべき、
意味（意図）が同じコミットはあとからまとめるのもよい、
ローカルリポジトリは意味ごとにrebaseなどで改竄もむしろ推奨。
ということは、ブランチも意味ごとに直交させて切るべきだと思うんだけど
そーするとなぜ未コミット分がブランチをまたいで受け継がれるんだろう。
ブランチをまたぐ際にstashとか破棄前提の嘘commitが必要ってのは
単に実装が思想に（まだ）合致できてないってことなんだろうか。
日常的に使ってるとブランチは常に2～3個必要になるし、
瞬間的には 4個とかにもなるんだけど、みんな困ってないのかな。
0555デフォルトの名無しさん
2011/08/20(土) 04:18:26.06いやShelve Changesがどんなものか知らんけど。
0556デフォルトの名無しさん
2011/08/24(水) 15:54:04.86NILFS
0557デフォルトの名無しさん
2011/08/24(水) 21:49:54.87GitやHgのリポジトリ一つずつ更新していくの面倒
いや、サブディレクトリにあるリポジトリでfetchをする
スクリプト書けばいいのかもしれないけれども、GUIの方が良いし
0558デフォルトの名無しさん
2011/08/25(木) 01:08:57.32俺はそんなのシェル一行ですませるけど、GUIのツールがほしいなら作れよ
0559デフォルトの名無しさん
2011/08/25(木) 15:02:17.640560デフォルトの名無しさん
2011/08/26(金) 11:34:02.440561デフォルトの名無しさん
2011/08/27(土) 19:55:47.01GUIの既定値が自分の使い方とあっていなかった。
コマンド入力で補助しないと行けない。
Mercurialは自分と合っていそう。
rebase, transplant, splitを使って少しだけ内容の違うブランチを
双方で変更する場合に対応できる。
今までsubversionでリビジョンの範囲をマージする方法でやってきたが
履歴改変にはまりそうだ。
0562デフォルトの名無しさん
2011/08/30(火) 18:05:51.79条件は以下の通り
・NASでソースは管理する。（購入済み）
・サーバーレスで動くもの
調べた感じでSubVersionしか無いんじゃないかと思ったんだけど、他におすすめありますか？
上の条件に合致すれば 分散だろうが集中だろうが関係無いらしい。
0563デフォルトの名無しさん
2011/08/30(火) 18:14:12.96いろいろ無茶じゃないか……？
そのNASで複数の接続先から同時に同じファイルに排他ロックをかけようとして
ちゃんと動くか程度は確認したほうがいい。
ネットワークファイルシステム越しのロックがかからないようなら
サーバー建てるなり個人リポジトリとマージ用を分けるなり考えたほうがいい。
0564デフォルトの名無しさん
2011/08/30(火) 18:17:49.45誰かのマシンでサーバを動かしてリポジトリはNASに置けばいい
0565デフォルトの名無しさん
2011/08/30(火) 18:26:32.700566デフォルトの名無しさん
2011/08/30(火) 18:33:06.19だから一台のマシン上で複数プロセスから同時にコミットしても壊れない。
問題はネットワーク越しにそれをやると、ロックファイルを作ったつもりになって相手への反映が遅れるとか
NFSの制限でロック取れなくてもエラーが帰ってこないとか、なんか起きそうなことだ。
0567デフォルトの名無しさん
2011/08/30(火) 21:38:17.300568デフォルトの名無しさん
2011/08/30(火) 22:00:58.980569デフォルトの名無しさん
2011/08/30(火) 22:33:14.620570デフォルトの名無しさん
2011/08/30(火) 23:54:03.63SCMが全くわかってないなぁ、お前んとこの上司わ。
多分その上司は、そのNASがエクスプローラのWindowsネットワークに見えてないと
怒り出すんだろうな、きっと。
0571デフォルトの名無しさん
2011/08/30(火) 23:58:32.02そこでapache+subversionを動かしてるから、
・NASでソースは管理する。（購入済み）
という条件は満たしてるし、ソースの管理に必要なのはそのNASだけだから
・サーバーレスで動くもの
という条件も確かに満たしてはいる。
しかし当たり前のことだが、エクスプローラでは見えない。
つか、わかってないやつには見えないように設置する。これ、重要じゃね?
0572デフォルトの名無しさん
2011/08/31(水) 01:28:58.70リポジトリを直接覗いて何が入ってるかわからん！なんて言われるレベルだとどうしようもないな
0573デフォルトの名無しさん
2011/08/31(水) 09:45:03.18どうしようもないレベルという条件は既に満たしてしまっている気がするが...。
0574562
2011/09/01(木) 17:08:25.56SCMについては俺もしっかり理解できてなくて勉強しながらやってるから勘弁してくれ
NASへのファイルの同時書き込みとかの問題は言ったんだけど
「今時のNASでそんなのあるわけないだろ、自宅で使ってるがそんな事起きたことが無い」
とか言われてナシのつぶてだった ('A｀)
んで、別のサーバ動かしてリポジトリをNASに置く件については
「サーバーとNASが同時稼動前提とか何考えてるんだ」らしい。
0575562
2011/09/01(木) 17:15:34.40エクスプローラで見えてないとキチンと運用されているか俺がわからんとか言うタイプ
>>571
NAS(LS-WVL) を殻割りしてサーバー入れる手を考えてたんだけど、
「保証受けれなくなるし、もう半分ぐらい移行したから無理」とか言われるし
0576562
2011/09/01(木) 17:17:03.76VSSは使いにくいって上司がいってｒ
>>569
分散型ってマスターの場所にサーバー入れて管理みたいな図を見たんだけど必要無い？
必要無いなら保存先がNASってだけでいけそうかなぁと
もう文句言いまくるくせに自分では絶対しない人なんで
ﾏﾝﾄﾞｸｾ('A｀) ｳﾞｧｰ
0577デフォルトの名無しさん
2011/09/01(木) 17:34:23.24いざとなったら日付フォルダで…
0578デフォルトの名無しさん
2011/09/01(木) 17:57:08.96自宅用途でそもそも同時書き込みが発生するかよ。
本当にファイルに排他制御がかかるかテストさせてくれないのであれば
個人リポジトリを分けて、マージ担当を置いたほうがいいな。
0579デフォルトの名無しさん
2011/09/01(木) 18:22:06.68保存先がNFSならいけたんだが、単なるNASだと無理。
あきらめろ。
0580デフォルトの名無しさん
2011/09/01(木) 18:26:56.25業務でそんなの使うの？
サーバアプリ動かせるちゃんとしたの導入すれば？
0581デフォルトの名無しさん
2011/09/01(木) 20:18:22.500582デフォルトの名無しさん
2011/09/01(木) 20:26:10.000583デフォルトの名無しさん
2011/09/02(金) 02:05:35.26なんとかなっちゃいそうだよな
0584デフォルトの名無しさん
2011/09/02(金) 05:57:20.39声かけしてコミットしなよ
0585デフォルトの名無しさん
2011/09/02(金) 06:51:53.180586デフォルトの名無しさん
2011/09/02(金) 08:30:15.160587デフォルトの名無しさん
2011/09/02(金) 08:37:09.090588デフォルトの名無しさん
2011/09/02(金) 08:52:00.660589デフォルトの名無しさん
2011/09/02(金) 20:20:34.83Subversion が動くようだ。(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
0590589
2011/09/02(金) 20:26:47.830591デフォルトの名無しさん
2011/09/02(金) 22:28:53.51gccのクロスコンパイラなんて簡単にできるんだしw
0592デフォルトの名無しさん
2011/09/04(日) 21:57:37.98そんなときこそ Bazaar ですよ。
分散型が理解できないアホには集中型として、理解できる人には分散型として使える。
0593デフォルトの名無しさん
2011/09/04(日) 22:10:42.07うちは Bazaar で共有リポジトリを共有フォルダ上において
push/pull あるいはmergeしてるから、NASを使っているのと
ほぼ同じ構成だな。
0594562
2011/09/05(月) 13:51:32.54のやり方が一番幸せになれるんじゃないかと思った。
まだ自分がバージョン管理システムについて勉強中なんで
具体的な実現方法は見えてないんだけど、基礎的なものを勉強できる資料でおすすめって何かある？
リポジトリとかブランチとかさっぱりな初心者でも分かる資料・・・ orz
0595562
2011/09/05(月) 13:54:16.56今までは自分が全部のソース管理をしてたんだよね。
でも今年の中頃から打ち合わせだとかで不在が多くなって
例の上司が「俺がソース管理をしてやろう」ってなってからデグレが８回。
全部自分が対応してなんとか復旧 orz
0596デフォルトの名無しさん
2011/09/05(月) 14:26:55.34書籍・ドキュメント・実績豊富なGit・Mercurialを素直に使いましょう
まず近場の本屋に行きましょう
Bazaarが選択肢に入らないことは明かです
0597デフォルトの名無しさん
2011/09/05(月) 15:17:27.870598562
2011/09/05(月) 15:21:47.380599デフォルトの名無しさん
2011/09/05(月) 15:59:53.41>今までは自分が全部のソース管理をしてたんだよね。
どうやってたのよ？
で、上司が管理したらなぜデグるのか、原因はわかってる？
バージョン管理システムは管理を楽にしてくれるし、 変なことできにくくしたり、
変なことしても復旧が容易だったりするけど、それでも変なソースをコミットして
混乱に陥るってことが皆無というわけじゃないよ。
0600デフォルトの名無しさん
2011/09/05(月) 17:44:12.82ttp://progit.org/book/ja/ch5-1.html#id103
どう運用するかが肝でどのツールを選ぶかはたいした問題じゃないと思う
0601デフォルトの名無しさん
2011/09/05(月) 17:56:40.555～20万出して(まともなサーバ or プログラムが実行できるNAS)(+UPS)を買った方が断然良くないか
0602デフォルトの名無しさん
2011/09/05(月) 18:18:38.930603562
2011/09/05(月) 19:02:18.38今まではPG一覧の資料作って、修正する際は申請してもらって修正中フォルダへ移動
PG一覧へ修正者の記載。
修正が終わった段階で修正中フォルダからメインフォルダへ移動→PG一覧に更新日を修正状況を更新
上司がデグらせたのはこの辺の管理を全くせずに勝手にフォルダ移動OKにしたところ。
あとPG一覧も修正せずにいたからこうなった感じ
0604デフォルトの名無しさん
2011/09/05(月) 20:05:34.11その運用がちゃんとできているなら、ツール入れればだいぶ省力化できると思う。
その上司じゃどうしようもないから、早めに管理システム入れたほうがいい。
0605デフォルトの名無しさん
2011/09/05(月) 20:11:31.83Tracとかredmineを検討したほうがいいんじゃない？鯖いるけどｗ
0606デフォルトの名無しさん
2011/09/05(月) 23:17:15.66そんな夢のようなツールないですかね
0607デフォルトの名無しさん
2011/09/05(月) 23:55:40.10うげぇ。そのPG一覧はExcelってオチか。
それはマズイ。
0608デフォルトの名無しさん
2011/09/06(火) 11:04:59.100609デフォルトの名無しさん
2011/09/06(火) 12:10:54.34…とか茶々入れてもしょうがないな。DVCSにして、マネージャ級だけがプッシュできるリポジトリを作るに一票。
>>600
0610デフォルトの名無しさん
2011/09/06(火) 17:12:20.61変更を認識してくれなくて酷い目にあった。
試してみたら
bzr : NG
git : NG
hg : OK
svn : OK
って感じだった。
これって常識？
0611デフォルトの名無しさん
2011/09/06(火) 17:13:31.88タイムスタンプ見るかどうか？
0612デフォルトの名無しさん
2011/09/06(火) 17:38:44.83ありえんなあ。
0613デフォルトの名無しさん
2011/09/06(火) 18:04:07.75VCSによっては、タイムスタンプもサイズも同じなら中身まではチェックしないってのはある。
タイムスタンプが変わってるのにサイズが同じってだけで変更無し扱いになるってのはちょっと考えにくい。
0614562
2011/09/06(火) 18:10:44.18上司がやってなかったところがシステム化されるので大丈夫かなと思います。
>>605
まだどのバージョン管理システムを使うか検討段階なんで
どういうものがあるかも含めて教えてもらえると助かります。
鯖は無しでいいやつがいいです・・・・orz
0615デフォルトの名無しさん
2011/09/06(火) 19:30:58.94各ホストファイル共有ベースでやってるならなおのことDVCSがいいね。
0616デフォルトの名無しさん
2011/09/07(水) 00:08:14.87聞いてる感じだとMercurialが無難そう。GUIクライアントもこなれてるし。
日本語ファイル名をつかうなら、個人的にはBazaarを推したいけど。
とりあえず、HgInitでぐぐって出てきたページを読んでみるといいよ。
オリジナルは英文だけど和訳もあるはず。
0617デフォルトの名無しさん
2011/09/07(水) 00:32:56.06＞git : NG
これは信じ難いなぁ
0618デフォルトの名無しさん
2011/09/07(水) 11:29:43.76同じサイズのバイナリファイルということで
dd if=/dev/urandom of=file count=1
で試してみたけど再現しないな。何かやり方を間違っているだけでは。
0619デフォルトの名無しさん
2011/09/07(水) 12:15:08.63(一部だけ比較してるとか)
0620デフォルトの名無しさん
2011/09/07(水) 13:46:36.72gitとbzrとsvnで確認してみた。
同サイズでタイムスタンプが同じだと、確かにgitとbzrはNGだった。svnはOK。
同サイズでタイムスタンプが異なるとgit、bzr、svnの全部がOKだった。
0621デフォルトの名無しさん
2011/09/07(水) 13:50:30.820622デフォルトの名無しさん
2011/09/07(水) 13:55:41.410623デフォルトの名無しさん
2011/09/07(水) 16:18:44.38それは、バイナリファイルの場合は特別にタイムスタンプによって何か処理するということ？
0624デフォルトの名無しさん
2011/09/07(水) 16:37:24.240625デフォルトの名無しさん
2011/09/07(水) 16:47:33.27そのVCSでテキストレベルのdiffが取れないのがバイナリの定義じゃね？
0626デフォルトの名無しさん
2011/09/07(水) 16:52:46.13gitとかsvnはバイナリファイルかどうかを判断してんだけど、知らないの？
0627デフォルトの名無しさん
2011/09/07(水) 17:29:05.52mercurialだとNULバイト(0x00)が存在するものをバイナリファイルとして扱っているよ
0628デフォルトの名無しさん
2011/09/07(水) 17:30:24.65とかいうことかも。
ファイルそのものの属性としてのタイムスタンプを見てるとは信じがたい。
0629デフォルトの名無しさん
2011/09/07(水) 17:35:55.51それが専用プラグインなんかを突っ込む(Excelなんかはそうやるだろ？)
この手の質疑応答は10年ぐらいから嫌という程みてきたわｗ
0630629
2011/09/07(水) 17:40:21.02○この手の質疑応答は10年以上前から嫌という程みてきたわｗ
要は該当するファイル群に対して強制的にハッシュを取るようにすればいいだけの事
0631620
2011/09/07(水) 17:45:28.75テキスト・バイナリ同じ結果となりました。
Linuxでは、ctimeを任意に変更することができなかったので
同じタイムスタンプのデータは作成できませんでした。
gitでは、chmod(ctime更新)したらそのテキストはmodifiedに
なりadd&commitできましたので、ctimeで判断しているように思えます。
0632デフォルトの名無しさん
2011/09/07(水) 17:48:52.87何いってんの
0633デフォルトの名無しさん
2011/09/07(水) 18:03:41.17ファイルサイズの大小ならともかく、テキストかバイナリかでその辺の挙動を変える意味はないし。
毎回全ファイルのハッシュ計算するわけにもいかないし、タイムスタンプとサイズが一致してたらとりあえず
未変更とみなすっていうのはそれなりに妥当な落としどころだと思う。
0634デフォルトの名無しさん
2011/09/07(水) 18:09:47.260635デフォルトの名無しさん
2011/09/07(水) 18:17:45.900636デフォルトの名無しさん
2011/09/07(水) 18:17:49.92何いってんの
どのSCMのコード見ての発言なの
0637デフォルトの名無しさん
2011/09/07(水) 18:21:51.640638デフォルトの名無しさん
2011/09/07(水) 18:23:46.11毎回全ファイルのタイムスタンプとサイズをやりとりするの？
0639デフォルトの名無しさん
2011/09/07(水) 18:26:01.40svnは内部的にはバイナリファイルも差分で持ってるぜ
0640デフォルトの名無しさん
2011/09/07(水) 18:34:11.97gitとbzrは怖くて使えんわ
0641デフォルトの名無しさん
2011/09/07(水) 18:49:21.28取らない物が殆ど
仕様をちゃんと読め
0642デフォルトの名無しさん
2011/09/07(水) 18:52:36.710643デフォルトの名無しさん
2011/09/07(水) 19:03:14.53こういう人達はDBに沢山の画像をつっこむ以上に愚かだわ。
0644デフォルトの名無しさん
2011/09/07(水) 19:04:40.83古い常識に囚われてはいかん
0645デフォルトの名無しさん
2011/09/07(水) 19:09:17.24リポが肥大して後で消そうにも消せない問題は未だ健在(出来る物も有るけどね)。
そんな拡張によるニッチな要求を満たした例を上げて「今はバイナリも突っ込むのが常識」なんて言われても説得力がないわい。
0646デフォルトの名無しさん
2011/09/07(水) 19:46:50.490647デフォルトの名無しさん
2011/09/07(水) 19:49:21.440648デフォルトの名無しさん
2011/09/07(水) 19:52:05.38定期的にスナップショットをとるだけだろ…
あぁ同人か…
0649デフォルトの名無しさん
2011/09/07(水) 19:57:00.500650633
2011/09/07(水) 20:01:27.36マジで？これは恥ずかしい。
でもGitとBazaarはハッシュ取ってるよね？
>>642
そうは言っても、>>620 に書いてないMercurialも含めて、そういう挙動をしてるからなあ。
ちなみにタイムスタンプって言ってるのは、最後にコミットした時点のタイムスタンプじゃなくて、
ローカルで最初に変更チェックした時のタイムスタンプね。
BazaarとMercurialについては、一回ファイルの変更チェックしたら、サイズかタイムスタンプが変わらない限り再チェックされないようになってるように見える。
Gitは今手元にないから分からん。
0651デフォルトの名無しさん
2011/09/07(水) 20:08:37.600652620
2011/09/07(水) 20:19:42.68私の環境(Win7pro 32bit、bzr2.4.0、git 1.7.6 mysgit)だと、
ファイル名を指定してcommit(gitの場合はaddでファイル名指定後)も、
できないのが困る。
この現象が、私だけなのか、誰かWindowsでの動作を試してみてくれませんか？
0653デフォルトの名無しさん
2011/09/07(水) 20:27:04.66というのが必須なら、やはりVCSに突っ込むのがベターな選択だと思うよ。
ただその場合は、プログラムコードの管理をメインに開発されたVCSよりは、
Adobe Version Cueのような画像・映像データのアセット管理をメインに据えた
製品を選定するのが良いと思う。……というかそれは板違いの話になるな。
ちなみにウチは帳票定義用のバイナリーファイルをSVNに突っ込んでる。
Excelとか、Wordとか、PDFとか。
0654デフォルトの名無しさん
2011/09/07(水) 21:22:09.87のを入れないっていう意味だろ女子高生
0655デフォルトの名無しさん
2011/09/07(水) 21:31:19.43画像データの内容とプログラムの仕様が一致していないとマズいから、
コードとデータを一緒くたにSubversionで管理してるよ。
以前までコードとデータを別々に管理してたけど、
コードだけ更新してデータを更新しないとか、逆のこととかが頻発するんだよね。
特に納期直前にそんな事あったら目も当てられん。
0656デフォルトの名無しさん
2011/09/07(水) 21:48:56.84ディレクトリ、ファイル単位で別々のリビジョンをチェックアウトできるSubversionでは、
その要件は満たさない
0657デフォルトの名無しさん
2011/09/08(木) 00:24:05.54そうなのかな。よく理解できてないけど。
0658デフォルトの名無しさん
2011/09/08(木) 00:38:53.93管理できる
0659デフォルトの名無しさん
2011/09/08(木) 11:28:05.50うむ。一番楽だ。重いけどな。
>>656
わかりやすく説明してちょ。
0660デフォルトの名無しさん
2011/09/08(木) 12:45:06.800661デフォルトの名無しさん
2011/09/08(木) 14:01:54.84> この手の質疑応答は10年ぐらいから嫌という程みてきたわ
そうなの？何か別の物と勘違いしてない？
今回の問題は「（フォーマット不明の）画像ファイルをSCMで扱うとき、ファイルの日付と
サイズが同じ場合、内容が異なっていてもSCMによっては同一のものと認識する」だよ？
GitやMercurialのFAQに書いてたりするのかな？
0662デフォルトの名無しさん
2011/09/08(木) 14:06:41.17bzrで--unchangedつけてもダメ？
0663デフォルトの名無しさん
2011/09/08(木) 14:40:48.36画像はexifを見てるんだろうが、気に入らなきゃ自分で設定出来る
0664デフォルトの名無しさん
2011/09/08(木) 15:36:12.910665620
2011/09/08(木) 16:46:29.90bzrで--unchangedをつけて、試しましたがコミットは増えましたが、
変更が取り込まれませんでした。
再度Linux(Debian etch on VMware Player)とgit(1.5.6.5)で実験しました。
VMware Playerのフォルダ共有の機能でWindows上のフォルダを共有。
そこにディレクトリを作成してgitレポジトリを作成。
ファイルを追加してコミットした後、ファイルのサイズが変わらないようにファイルの内容を変更。
touchでファイルの存在するディレクトリとファイルのタイムスタンプを変更前のタイムスタンプに戻す。
VMwareのファイル共有ディレクトリだと、touchでctimeも変更できました。
この状態でgit statusをしても、変更がないと認識されました。add&commitもできませんでした。
0666デフォルトの名無しさん
2011/09/08(木) 17:03:17.59gitの場合、.gitattributes ファイルに
*.foo binary
と書いとけば、拡張子.fooファイルはバイナリだと扱われる
これで試すとどうなる？
0667デフォルトの名無しさん
2011/09/08(木) 17:42:49.51OKってどういうこと？
svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
「変更なし」になるんだけど。
変更を検知できないんならNGじゃね？
>>631
gitはパーミッションも管理対象だからじゃね？
0668デフォルトの名無しさん
2011/09/08(木) 17:53:14.49> svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
> 「変更なし」になるんだけど。
まじか
svn使えねー
0669デフォルトの名無しさん
2011/09/08(木) 18:17:29.09サイズとctimeが同じでも、中身が違えば変更検知されたのだが
0670デフォルトの名無しさん
2011/09/08(木) 18:28:23.18タイムスタンプを変えないなんてわざとそうているのなら
運用する側が工夫すればよい
0671620
2011/09/08(木) 18:37:47.23私の環境のTortoiseSVNだと、変更したファイルをクリックして状態を
観ると変更ありになり、コミット可能でした。
>>669
ファイルのみのctimeが同じな場合は、変更が検知されましたが、
その親ディレクトリのctimeを一致させた場合は、だめでしたので、
665ではそのように記述しました。
0672デフォルトの名無しさん
2011/09/08(木) 18:50:46.18.git/ がある親ディレクトリまで含めて、全てのディレクトリとファイルの
ctimeを同じにしたけど、中身が違えば変更が検出されたぞ
どうなってんだ
0673デフォルトの名無しさん
2011/09/08(木) 18:53:09.320674デフォルトの名無しさん
2011/09/08(木) 19:25:21.570675デフォルトの名無しさん
2011/09/08(木) 21:37:47.880676デフォルトの名無しさん
2011/09/09(金) 18:59:34.46http://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でも試したがタイムスタンプ一緒だと変更検知できないよ。
0677デフォルトの名無しさん
2011/09/09(金) 19:11:14.55こんな感じのシェルスクリプトを書いて実行してみた
---------------------------------------------
#!/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 してみたら変更が検知されたよ
0678676
2011/09/09(金) 19:13:22.93svn NG
bzr NG
hg NG
git OK
0679デフォルトの名無しさん
2011/09/10(土) 08:47:32.420680デフォルトの名無しさん
2011/09/11(日) 04:38:09.42変更したファイルはtouchすればいい。
0681デフォルトの名無しさん
2011/09/11(日) 13:38:57.77だなー。内容変えたらタイムスタンプも変えておけってこった
0682デフォルトの名無しさん
2011/09/11(日) 20:53:04.25ttp://news.php.net/php.internals/55293
0683デフォルトの名無しさん
2011/09/12(月) 11:18:01.38ぐだぐだと粘着してた奴が
svnも検知できないと分かったとたんパッタリ消えたのが笑えるwww
0684デフォルトの名無しさん
2011/09/12(月) 11:46:04.680685デフォルトの名無しさん
2011/09/13(火) 23:23:49.080686デフォルトの名無しさん
2011/09/30(金) 22:49:56.450687デフォルトの名無しさん
2011/10/01(土) 10:17:37.48sf.netだと古くて動かないこと多いし
でも日本語ファイル名あったらsvnの方がいいのになんでgitなんだろ
0688デフォルトの名無しさん
2011/10/01(土) 10:27:38.330689デフォルトの名無しさん
2011/10/01(土) 11:31:56.07用途によってはsvnのほうが良いとしても、githubとSourceForgeには超えられない壁がある
0690デフォルトの名無しさん
2011/10/01(土) 11:56:33.55VSSのどこが気に食わないんだ？
0691デフォルトの名無しさん
2011/10/01(土) 12:11:45.070692デフォルトの名無しさん
2011/10/01(土) 15:37:43.920693デフォルトの名無しさん
2011/10/01(土) 18:32:06.160694デフォルトの名無しさん
2011/10/01(土) 21:23:49.83CVSよりイケてるのがほぼsvnだけだった、て時代が長かったてのもあるけど
まあ、より使いやすい(と誰かが考える)ものに変わってくのはなんでも同じ
svnがそこにあって、それが気に入らなかったからLinusもgitつくったわけだし
よくもわるくも、svnがなければhgもbzrも育ってないと思う
だからsvnはよくやった、いままでごくろうさん、て感じかね
俺としては、ファイルシステムレベルでVCSをブチこんでくれないかな、
と前から思ってるんだけど。そういう構想とかないのかなあ
0695デフォルトの名無しさん
2011/10/01(土) 21:33:32.16振り回され過ぎ。ほぼ完璧にUnicode対応
出来てるのは今でもsvnだけだし、
業務に使うのにこれほど信頼できるものも他にない。
リポジトリがネットワーク的に近ければ十分現役。
OSSのリポジトリは遠いからDVCSの速度が必須というだけ。1コミットに数分とかありえないだろ
0696デフォルトの名無しさん
2011/10/01(土) 21:57:58.42Lionだと、全てのドキュメントが自動セーブ＆自動バージョニングされるらしいぞ、知らんけど
0697デフォルトの名無しさん
2011/10/01(土) 22:44:13.89ローカルで履歴弄り放題のgitもいいもんだぞ
Windowsだと未だにsvn一択なのが悲しいが・・・
0698デフォルトの名無しさん
2011/10/02(日) 08:15:31.39> 振り回され過ぎ。ほぼ完璧にUnicode対応
> 出来てるのは今でもsvnだけだし、
> 業務に使うのにこれほど信頼できるものも他にない。
バックアップが無くて全てパー
サーバがクラックされて全てパー
0699デフォルトの名無しさん
2011/10/02(日) 09:58:33.94そう煽るなら上2行は引用しないのが適切
0700デフォルトの名無しさん
2011/10/02(日) 11:06:15.540701デフォルトの名無しさん
2011/10/02(日) 12:42:12.53Windowsにはシャドウコピーがあるね
0702デフォルトの名無しさん
2011/10/02(日) 21:00:37.28バージョン管理システムと関係ないような気が
0703デフォルトの名無しさん
2011/10/02(日) 21:01:41.57TRON
0704デフォルトの名無しさん
2011/10/02(日) 23:47:13.33Gitならサーバークラックされて顧客情報流出しても平気と聞いて
0705デフォルトの名無しさん
2011/10/03(月) 00:38:14.240706デフォルトの名無しさん
2011/10/03(月) 00:49:36.390707デフォルトの名無しさん
2011/10/03(月) 07:47:55.75VMSかな。
0708デフォルトの名無しさん
2011/10/03(月) 18:40:54.480709デフォルトの名無しさん
2011/10/05(水) 19:57:49.200710デフォルトの名無しさん
2011/10/05(水) 20:06:54.070711デフォルトの名無しさん
2011/10/28(金) 19:50:58.830712デフォルトの名無しさん
2011/10/28(金) 20:09:47.780713デフォルトの名無しさん
2011/10/28(金) 20:24:03.650714デフォルトの名無しさん
2011/11/07(月) 23:32:11.25Q:タイムスタンプが同じだと～
A:touchする運用でよくね？
で済む話が
信奉者が信じたくない(>>617)とか言い出したり。
そんな使い方が悪い(>>643)とか言い出したり。
使用上正しいと(>>641)とか言い出したり。
その言い争いで何か得るものがあるわけ？
アホ過ぎて分からんわ。
0715デフォルトの名無しさん
2011/11/07(月) 23:35:46.050716デフォルトの名無しさん
2011/11/08(火) 20:04:44.100717デフォルトの名無しさん
2011/11/08(火) 22:28:31.53どういう計算だよ。2ヶ月なら1/6年だろ。
0718デフォルトの名無しさん
2011/11/08(火) 23:05:32.391光年みたく1光月という距離の単位があるとして
『1光月の彼方で、1ヶ月後に読み取ってその時書き込んだものがさらに1ヶ月後に我々の目に届く』
のか
『2光月の彼方で、2ヶ月後に読み取ってその時書き込んだものが瞬時に我々の目に届く』
のか、どっちでもないのか
0719デフォルトの名無しさん
2011/11/09(水) 00:00:43.38企業内で自分の担当のソースをいくつか修正してcommitする開発モデルではかなり違うキガス
0720デフォルトの名無しさん
2011/11/09(水) 11:18:08.640721デフォルトの名無しさん
2011/11/09(水) 12:00:51.46距離だよ。そんなことは常識だ。
光速より速い伝達手段がないから、仮に0.08光年離れたところからレスするなら
往復で0.16光年。即ち58日掛かるだろってこった。
因みに、0.025光年なら高々9日ほどだから往復でも18日。
二ヶ月前の話を穿るにしては中途半端すぎる。
0722デフォルトの名無しさん
2011/11/09(水) 12:24:31.180723デフォルトの名無しさん
2011/11/09(水) 21:24:08.380724デフォルトの名無しさん
2011/11/09(水) 23:37:38.83>>721
「光速より速い伝達手段がない」っていうのは
『とても軽い1光年の長さの棒があったとして、棒の端を押すかひねるかすると
その反対側が動き出すのはどんなに早くても1年後』
になるの？
せーの、で動き始める事にならないから音が水や金属を伝わる速さに差が出るのと
似た話になるんだろうか？？？
0725デフォルトの名無しさん
2011/11/09(水) 23:41:55.54http://kamome.2ch.net/sci/
0726デフォルトの名無しさん
2011/11/10(木) 00:08:07.39スレ汚しすまんかった
0727デフォルトの名無しさん
2011/11/10(木) 02:42:10.27subversion使ってる人多いみたいだけど。
0728デフォルトの名無しさん
2011/11/10(木) 16:53:16.30不要なら鉄板。
0729デフォルトの名無しさん
2011/11/10(木) 22:18:29.30集中型だとsubversionが鉄板なのか。どうりで名前をよく聞くわけだ。
どうも有り難う。
0730デフォルトの名無しさん
2011/11/11(金) 02:24:44.84TortoiseSVNなどクライアントの成熟や日本語環境の安心度、集中型であるがゆえのシンプルさなどがSubversionの利点。
0731デフォルトの名無しさん
2011/11/12(土) 09:25:18.730732デフォルトの名無しさん
2011/11/12(土) 22:34:58.67Bazaarは前からUnicode使える
GitはCygwin版とかUTF-8対応msysgitにすればいいがTortoiseGitで文字化けする
Cygwin版GitとCygwin版GitGUIならいいのか？でもあれはTortoiseより使いづらい
だからこの3者で日本語の扱いに問題ありそうなのはGitだけということになった
0733デフォルトの名無しさん
2011/11/12(土) 23:11:54.74> Mercurialは最近ファイル名にUnicodeが使えるようになったらしい
まだなっていない。
Windowsのネイティブ環境(cygwinじゃない環境)でUTF-16が扱えないということで、
それ以外の環境であれば、Unicodeのエンコードの一つUTF-8を扱うのに
MercurialもGitも制約は無い。
0734デフォルトの名無しさん
2011/11/15(火) 16:47:52.610735デフォルトの名無しさん
2011/11/15(火) 21:19:20.38「日本語の扱いに問題がある」ってんだからWindowsのことだよ。
頭悪いな
0736デフォルトの名無しさん
2011/11/15(火) 21:36:30.420737デフォルトの名無しさん
2011/11/15(火) 22:00:43.83日本語嫌いな人？？国に帰れば
0738デフォルトの名無しさん
2011/11/16(水) 10:29:21.370739デフォルトの名無しさん
2011/11/16(水) 13:34:58.800740デフォルトの名無しさん
2011/11/18(金) 18:52:16.11http://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をパワーアップ……岡本 隆史
0741デフォルトの名無しさん
2011/11/18(金) 23:29:17.44説明文と表と説明文の３つをdivで囲って、表の部分をtable{position:relative;left:20px}とかしたら
理想の通りになったんですけど、考え方としてこれでいいのでしょうか？
┏━━┓説明文
┃ 図 ┃表
┃ ┃説明文
┗━━┛
0742デフォルトの名無しさん
2011/11/18(金) 23:34:49.930743デフォルトの名無しさん
2011/11/18(金) 23:45:50.650744デフォルトの名無しさん
2011/11/19(土) 16:29:42.100745デフォルトの名無しさん
2011/11/19(土) 18:35:58.41http://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
0746デフォルトの名無しさん
2011/11/20(日) 04:59:47.490747デフォルトの名無しさん
2011/11/20(日) 13:30:28.15645 名前：デフォルトの名無しさん [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
0748デフォルトの名無しさん
2011/11/20(日) 17:10:36.620749デフォルトの名無しさん
2011/11/21(月) 09:14:35.580750デフォルトの名無しさん
2011/12/02(金) 16:17:39.36バージョン管理ツール総合スレらしきここを覗きにきた。
一言も登場しとらんのな。
0751デフォルトの名無しさん
2011/12/02(金) 19:59:03.840752デフォルトの名無しさん
2011/12/04(日) 01:42:40.77あんな感じでWindowsにインストールしたらいきなりファイル交換を自動的にし合うような
そんなバージョン管理ソフトはまだ出現しませんかね？
0753デフォルトの名無しさん
2011/12/04(日) 02:07:15.590754デフォルトの名無しさん
2011/12/04(日) 03:27:28.520755デフォルトの名無しさん
2011/12/04(日) 21:25:54.920756デフォルトの名無しさん
2011/12/04(日) 22:25:32.760757デフォルトの名無しさん
2011/12/04(日) 22:32:47.85GNUだから
0758デフォルトの名無しさん
2011/12/04(日) 23:20:45.18bzr-explorer が中途半端に使いにくい
0759デフォルトの名無しさん
2011/12/04(日) 23:21:40.660760756
2011/12/04(日) 23:28:52.04subversionから移行して便利だなあって思ってるんだけど。
gitとかhg使ったことないから、そっちのほうがいいのかもしれないけど。
>>757
どうしてGNUだと人気ないの？
>>758
なんか良いGUIクライアントありませんかね。
0761デフォルトの名無しさん
2011/12/05(月) 00:06:34.92あなたがWindowsを使っているのか、Linuxを使っているのかわからないけど
俺はwindows から使っている感想を書く。
SVNの場合TortoiseSVNを使う限り、SVNのコマンドを意識する必要は全く無い。
ところがBazaarの場合、TortoiseBZRにしろBzr-Explorerにしろ、BZRコマンドが
動いているのが見えるし、エラーが起きるとBZRコマンドを実際に打たないと復旧出来ない
場合がたまにある。GUIツールはGUIだけで完結してほしい。
特にWindowsの場合はそうでないと、グループで使うのはちょっと無理。
0762756
2011/12/05(月) 00:14:09.66たしかに。TortoiseSVNは優れていますね。
hgやgitはWindowsでGUIツールで完結できるものはあるのでしょうか。
0763デフォルトの名無しさん
2011/12/05(月) 00:20:14.41> SVNの場合TortoiseSVNを使う限り、SVNのコマンドを意識する必要は全く無い。
だって、svn.exeが付いてないんだもん。
0764デフォルトの名無しさん
2011/12/05(月) 01:58:42.83最近のTortoiseSVNには付いてるよ。
0765デフォルトの名無しさん
2011/12/05(月) 03:16:56.63Subversionっていうか、TortoiseSVNが優れてるっていう話だね。
うちの会社もSubversion使ってる。
Linuxでコマンドラインだけど。
ファイル数がめちゃめちゃ多いとcoするにもupdateするにも時間もメモリも食い過ぎていい方法か、いいソリューションが無いかと検討中。
0766デフォルトの名無しさん
2011/12/05(月) 03:36:06.74開発途中で乗り換えるのは危なすぎるが、次のやつで試してみたいところではある
0767デフォルトの名無しさん
2011/12/05(月) 03:43:25.35そういう場合は本格的にgitを考えたほうがいいかも
0768デフォルトの名無しさん
2011/12/05(月) 07:30:18.52他のものと比較してとりたてて優れているところはないが。
0769デフォルトの名無しさん
2011/12/05(月) 17:12:12.220770デフォルトの名無しさん
2011/12/05(月) 20:42:12.30他の物って何？具体的なソフト名を挙げてくれ
0771デフォルトの名無しさん
2011/12/05(月) 21:11:43.17TortoiseCVS
0772デフォルトの名無しさん
2011/12/05(月) 21:47:53.52・Windows上の
・フリーで使える
・GUIの
・バージョン管理ソフト
の中では、やっぱ一番順当に使える完成度じゃなかろかね。
CVSよりはSubversionのが良いし、
かといって、Gitやらhgやらござーるやらにおいては、
今度はtortoiseの完成度が…だし。
0773デフォルトの名無しさん
2011/12/06(火) 01:20:45.510774755
2011/12/06(火) 02:11:34.330775デフォルトの名無しさん
2011/12/06(火) 07:36:04.07CVSとSVNでは出来ることが違うのだからTortoiseCVSとTortoiseSVNを比較しても無意味
TortoiseHgとbzr-explorerはWindowsだけが動作環境では無いので、TortoiseSVNと比較しても無意味
TortoiseGitはgit extensionsという代替がある
TortoiseBzrは世界的に使われているのか疑問
0776デフォルトの名無しさん
2011/12/06(火) 12:56:30.07時点でEclipse。
0777デフォルトの名無しさん
2011/12/06(火) 21:04:55.95RCSではないが、似たようなことをする Visual SouceSafe というものがある。ディスコンに向かってるけど。
GUI で RCS って面倒なだけだよ?
0778デフォルトの名無しさん
2011/12/06(火) 21:12:05.430780デフォルトの名無しさん
2011/12/07(水) 00:23:13.910781デフォルトの名無しさん
2011/12/07(水) 00:30:10.630782デフォルトの名無しさん
2011/12/07(水) 22:06:27.690783デフォルトの名無しさん
2011/12/08(木) 11:52:36.030784デフォルトの名無しさん
2011/12/09(金) 21:21:56.20簡単に言えばファイル交換ソフトにバージョン管理を組み合わせただけでしょ
Winny にバージョン管理とssh通信付ければ、
最強の分散型バージョン管理ソフトが出来たのに、
↓仁義なきなんとかネタの突っ込み禁止
0785デフォルトの名無しさん
2011/12/09(金) 22:13:00.71マージできんモン送られても困るがな。
0786デフォルトの名無しさん
2011/12/09(金) 22:54:52.340787デフォルトの名無しさん
2011/12/09(金) 23:47:18.480788デフォルトの名無しさん
2011/12/09(金) 23:47:27.970789デフォルトの名無しさん
2011/12/09(金) 23:51:15.600791デフォルトの名無しさん
2011/12/09(金) 23:52:42.310792デフォルトの名無しさん
2011/12/09(金) 23:57:19.160795デフォルトの名無しさん
2011/12/10(土) 12:49:29.27git を本質的に超える バージョン管理はもう現れないのかな？
0796デフォルトの名無しさん
2011/12/10(土) 13:15:24.550797デフォルトの名無しさん
2011/12/10(土) 14:23:58.07HGが、”本質的”にgitを超えているとは思えないな
多少の機能の違いがあるだけで似たり寄ったりですな
0798デフォルトの名無しさん
2011/12/10(土) 14:27:45.52ファイル名の扱いが構想通りに実現すれば、他のVCSを超越すると思う
0799デフォルトの名無しさん
2011/12/10(土) 17:40:14.09望みが低すぎる
0800デフォルトの名無しさん
2011/12/10(土) 20:29:18.18どれも思想が異なるわけだが
0801デフォルトの名無しさん
2011/12/10(土) 20:32:39.04gitとhgは思想は一緒。リポジトリへの保存方法とコマンド体系が違うから別物に見えるけど。
0802デフォルトの名無しさん
2011/12/10(土) 21:14:57.010803デフォルトの名無しさん
2011/12/10(土) 21:15:34.91思想がちがうのはdarcsだけ
0804デフォルトの名無しさん
2011/12/11(日) 03:11:29.28gitが優れてる部分が多いことは間違いないんだけど、
バイナリを頻繁に扱わなくちゃならない環境にとってはgitじゃ駄目なんだよなぁ
0805デフォルトの名無しさん
2011/12/11(日) 15:31:56.85バイナリが得意なVCSってなに？
0806デフォルトの名無しさん
2011/12/11(日) 15:58:35.45Mercurial 2.0リリース、バックポートに有用な「graft」コマンドや
サイズの大きいバイナリファイルを効率よく扱う拡張などが導入される
http://sourceforge.jp/magazine/11/11/04/0354255
0807デフォルトの名無しさん
2011/12/11(日) 16:18:33.61それは単に実体を共有したりするだけだろ。そんなもんgitならデフォだ。
そして頻繁にバイナリの変更があるようなのはどっちもダメだ。
svnならバイナリも差分で格納してくれる。
0808デフォルトの名無しさん
2011/12/11(日) 16:32:10.84> 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
0809デフォルトの名無しさん
2011/12/11(日) 16:33:57.520810デフォルトの名無しさん
2011/12/11(日) 16:44:05.76バイナリに限らず差分形式になる
0811デフォルトの名無しさん
2011/12/11(日) 17:18:49.81この点はsvnが優れている。hgは試してない。
0812デフォルトの名無しさん
2011/12/11(日) 17:25:35.96・OSは？
・メモリのキャッシュに残ってただけでは？
0813デフォルトの名無しさん
2011/12/11(日) 17:27:15.850814811
2011/12/11(日) 17:34:26.83で見た。
1.7GBくらいのファイル1個をコミットしてみた。
hgはファイルサイズくらいのメモリーを消費した。
bzrはファイルサイズの倍(もっとかも)のメモリーを消費した。
svnは数百メガバイトくらい。
svnはサーバーを使わずローカルのファイルシステム上にSVNROOTを設定した。
ただしbzrをテストしたのはだいぶ前なので改良されてるかも。
0815デフォルトの名無しさん
2011/12/11(日) 17:36:29.61仮想メモリ量じゃなかったかも。手元にXPがないんですまん。
0816デフォルトの名無しさん
2011/12/11(日) 17:46:23.180817デフォルトの名無しさん
2011/12/11(日) 17:49:39.45前に自分でやってみればいいのに。
0818デフォルトの名無しさん
2011/12/11(日) 17:50:52.67gitとhgのどっちを試したのか分からん
0819デフォルトの名無しさん
2011/12/11(日) 17:55:07.49すまん。gitとbzrとsvnだった。
0820デフォルトの名無しさん
2011/12/11(日) 18:13:30.24テスト内容が非現実的。svnでサーバーを使わない目的が不明。
0821デフォルトの名無しさん
2011/12/11(日) 18:18:33.97だから誰でも簡単にできるテストなんだから、好きにテストすればいい。
0822デフォルトの名無しさん
2011/12/11(日) 18:21:26.09svnが優位というのは根拠が無いでOK？
0823デフォルトの名無しさん
2011/12/11(日) 18:44:30.16好きにしたら?
誰かの参考になるかと思って単にテスト結果を並べただけだよ。
svnを応援する気なんてない。実際svn使ってないし。
0824デフォルトの名無しさん
2011/12/11(日) 21:24:02.28理論的な上限じゃ無くて、実運用的な作業フォルダのサイズってどの程度にしている？
なんか、直ぐにファイル無くしたとか、上書きしたとか削除したとか言い出す人がいて、
管理フォルダまとめて管理してしまおうかと。でも、6.5GBで、ファイル数38,000くらいあるんだ。
さすがにこれをひとまとめは無茶だよね。Windows環境でファイルサーバー的にしか使ってない。
バージョン管理ソフト使うよりはファイルの書き換え毎にバックアップで戻るソフトさがした方が良いか。
そんなのあるのか知らないけど。
0825デフォルトの名無しさん
2011/12/11(日) 21:29:18.940826デフォルトの名無しさん
2011/12/11(日) 21:32:24.34Subversionはディレクトリ（フォルダ）単位でチェックアウトできる。
Mercurialはサブリポジトリという機能がある。
0827デフォルトの名無しさん
2011/12/11(日) 21:36:35.06使い方を理解している人が明示的に使わない限りは
全く機能しないってところだな
0828デフォルトの名無しさん
2011/12/11(日) 21:43:25.58WindowsのMercurialで、ファイル数2万ぐらいの画像ファイルの管理をした時の不満点は、
・TortoiseHGのパフォーマンス劣化が酷い
・上位のディレクトリ名を変更したら、ファイル追加と同じぐらい激しくリポジトリ肥大
・addのcommit中に共有違反で読めないファイルがあった時、リポジトリがぶっ壊れた
特に最後の奴が痛かった。常識的に考えて、エラーならアトミックにロールバックしろよ。
0829デフォルトの名無しさん
2011/12/11(日) 21:44:47.600830デフォルトの名無しさん
2011/12/11(日) 22:23:38.150831デフォルトの名無しさん
2011/12/11(日) 22:27:19.660832デフォルトの名無しさん
2011/12/11(日) 22:37:10.72Mercurialって最近largefile拡張とかサポートしてたキガス
0833デフォルトの名無しさん
2011/12/12(月) 00:34:37.98そのくらいなら実際に開発してた。
ディレクトリの切り方がまともなら十分可能。
常にその数を相手にするのはきついなあ。
0834デフォルトの名無しさん
2011/12/12(月) 00:48:50.75ケチつけられるのが嫌ならいい加減なこと書かなきゃいいのに。
0835デフォルトの名無しさん
2011/12/12(月) 01:11:47.52いい加減だったのは謝る。でも誰もsvnサーバーで巨大ファイルのテストを
してないのにケチだけつけるのは驚きだ。
0836デフォルトの名無しさん
2011/12/12(月) 09:53:03.48「ぼく悪くないもん！」
0837デフォルトの名無しさん
2011/12/12(月) 10:50:40.410838デフォルトの名無しさん
2011/12/12(月) 11:23:56.12お前2chは初めてか？力抜けよ。
0839デフォルトの名無しさん
2011/12/12(月) 12:17:56.61ローカルファイルシステムを使った場合 → svn.exe が約10MB使用
svnserveを使った場合 → svnserve.exe が約10MB、svn.exe が約8MB使用
ファイルの最後にわずかな変更を加えて再コミットした場合も同様だった。
0840デフォルトの名無しさん
2011/12/12(月) 12:37:02.31svnのバージョンは？
1.6と1.7ではクライアントは全く違う。
0841デフォルトの名無しさん
2011/12/12(月) 12:45:54.17たまたまはいってた古い1.5.2でやった。何でやればいい?
0842デフォルトの名無しさん
2011/12/12(月) 12:49:33.241.7
0843デフォルトの名無しさん
2011/12/12(月) 13:35:08.79VisualSVNのコマンドラインツールでやった。サーバー、クライアントとも1.7.2。
1回めのコミット→サーバー20MB、クライアント5.5MB
2回目のコミット→サーバー20MB、クライアント5MB
使ったファイル→Jazz RationalTeamConcert3.01配布ファイルのzip 1.4GB
2回めのコミットの前に「echo a >> ファイル」でファイルに内容を追加した。
0844デフォルトの名無しさん
2011/12/12(月) 19:17:04.36http://www.infoq.com/jp/news/2011/12/eclipse-git
0845デフォルトの名無しさん
2011/12/12(月) 20:38:29.650846デフォルトの名無しさん
2011/12/12(月) 20:53:04.53778 ：デフォルトの名無しさん：2011/12/12(月) 19:41:23.29
>>777
後半のhgの所は間違っている。
bitbucketはプライベートリポジトリとして使われているケースが多い。
公開リポジトリが１つもないアカウントはいっぱいある。
hgのossプロジェクトは自前でリポジトリを立てている所が多い。
http://mercurial.selenic.com/wiki/ProjectsUsingMercurial
0847デフォルトの名無しさん
2011/12/12(月) 21:05:47.21この著者はgithubが言いたいだけなんじゃないか。
Atlassianに買収される前のbitbucketは頻繁にサーバが落ちていたけど、
最近はほとんど無くなった。
機能もどんどん多くなってきている。githubとほとんど変わらない。
容量制限無し、プライベートリポジトリ、git/hg両方対応と、bitbucketの方が利便性が高い。
個人では公開はgithub、プライベートはbitbucketと使い分けているのが多い。
今後、githubからbitbucketに移動するプロジェクトも増えるのではないか。
0848デフォルトの名無しさん
2011/12/12(月) 21:27:55.210849デフォルトの名無しさん
2011/12/12(月) 21:33:23.02Atlassianに聞いて
0850デフォルトの名無しさん
2011/12/12(月) 23:55:59.460851デフォルトの名無しさん
2011/12/13(火) 00:06:04.20投稿日 2010年2月21日
http://www.infoq.com/jp/articles/dvcs-guide
> 最初の頃パフォーマンスが悪かったため、Bazaarは周囲に影響を与える多くの
> 早期採用者(MozillaやSolaris、OpenJDK)を失いました。
Bazaarって遅いのかよｗ
0852デフォルトの名無しさん
2011/12/16(金) 01:38:32.73git選択しにくいのはパフォーマンス云々よりlock出来ないのが痛い。
そんなわけで一定以上のリソースがある場合はPerforce
そうじゃないときはsvnって選択になっちゃってる。
0853デフォルトの名無しさん
2011/12/16(金) 01:39:12.540854デフォルトの名無しさん
2011/12/16(金) 07:18:50.98その適材適所にみんな悩んでいるんだと思うが
いくら適材適所でも3も4も管理システム導入とか非現実的だし
0855デフォルトの名無しさん
2011/12/16(金) 07:26:33.87つ>>397
0856デフォルトの名無しさん
2011/12/16(金) 07:30:03.15http://mercurial.selenic.com/wiki/LockExtension
Mercurialの主要コミッタ作なんで品質は大丈夫だろう
0857デフォルトの名無しさん
2011/12/17(土) 22:18:25.370858デフォルトの名無しさん
2011/12/17(土) 22:24:21.44これまでは
> ソースコード対象にしている
だったけど、今後
> 巨大バイナリ管理を求める
ってことで、ツールも対応してくれって言うことでしょ。
0859デフォルトの名無しさん
2011/12/17(土) 22:29:14.97git/Mercurial じゃできないのプププのプー
って話にならね?
0860デフォルトの名無しさん
2011/12/17(土) 22:35:02.11Mercurialは、largefile extensionとlock extensionがあるとこのスレにあるのが見えない盲目？
0861デフォルトの名無しさん
2011/12/17(土) 22:57:34.77話の流れも見えない馬鹿?
0862デフォルトの名無しさん
2011/12/17(土) 23:08:36.86Mercurialは巨大バイナリも、ワード・エクセルなどを想定したロックも、両方対応しているってのが分からない馬鹿？
0863デフォルトの名無しさん
2011/12/18(日) 00:54:57.99たぶん859は857に対してレスしてるんじゃね？
0864デフォルトの名無しさん
2011/12/18(日) 02:14:55.00ゲームのグラフィクスなどの大型、大量バイナリを突っ込むと実用性に問題が出るほど重くなる。
Perforceはマシみたいだけど。
0865デフォルトの名無しさん
2011/12/18(日) 02:42:17.5910G 前後ならまあ、なんとかなるけど、数倍になるとアウトだよ!
Perforce だとイケる? 桁上がったくらいはどう?
0866デフォルトの名無しさん
2011/12/18(日) 10:32:16.15>Perforce だとイケる? 桁上がったくらいはどう?
評価版があるみたいだから、試してみれば？
http://www.toyo.co.jp/ss/perforce/download_soft_2010.2.html
0867デフォルトの名無しさん
2011/12/18(日) 14:14:40.340868デフォルトの名無しさん
2011/12/18(日) 16:58:55.490869デフォルトの名無しさん
2011/12/18(日) 17:16:16.57そのボディブローでVSSを抹殺してください
0870デフォルトの名無しさん
2011/12/18(日) 20:21:16.250871デフォルトの名無しさん
2011/12/18(日) 21:11:31.090872デフォルトの名無しさん
2011/12/18(日) 21:31:44.39うは～、腹いてー（笑）
0873デフォルトの名無しさん
2011/12/18(日) 22:12:30.180874デフォルトの名無しさん
2011/12/18(日) 22:22:39.370875デフォルトの名無しさん
2011/12/18(日) 22:38:46.110876デフォルトの名無しさん
2011/12/18(日) 22:39:07.29git技術者検定とかやりそうだなｗ
0877デフォルトの名無しさん
2011/12/18(日) 22:40:59.18Bazaarはマジでこのままだとジリ貧だろ
Linux関連の開発で使う限りではgitの方が使っているプロジェクトも技術者も多いし
Bazaarは今のバージョンで打ち止めして、新規に再設計した方が良いと思うわ
0878デフォルトの名無しさん
2011/12/18(日) 23:00:45.79>まだ使ってるとこあるのか
あるよ～、って言うかそこそこの規模だとなかなか入れ替えられない。
0879デフォルトの名無しさん
2011/12/18(日) 23:43:43.22http://d.hatena.ne.jp/wonderful_panda/20111212/1323643703
0880デフォルトの名無しさん
2011/12/19(月) 00:08:40.00膨大なOSSプロジェクトといっぱいありますが？
https://twitter.com/#!/methane/status/148328106841751552
> git へ移行する最大の障壁は、「gitのことならなんでも訊いて！」という人がいないこと。
> バージョン管理システムのワークフローの構築とかはこう言った先導者が必要。
> bzrは問題あったらぼくがなんでも解決できてたけど、gitはぼくが教えて欲しいくらいだしな。
0882デフォルトの名無しさん
2011/12/19(月) 01:05:07.92このスレの前半を見よう。
Bazaarの泥舟から脱出を検討している亡命予備者
0883デフォルトの名無しさん
2011/12/19(月) 01:23:13.620884デフォルトの名無しさん
2011/12/19(月) 10:40:41.15methaneさんは社内の人員のことを言ってると思うよ。
業務で使う場合、社内に強力に推進できる人がいないと結構大変だよね。
0885デフォルトの名無しさん
2011/12/19(月) 17:34:49.82今でも一応3つとも使ってますが、会社ではbzrを使うメリットがあまりないので、git, hg への移行を考え中。
0886デフォルトの名無しさん
2011/12/19(月) 19:27:10.460887デフォルトの名無しさん
2011/12/19(月) 20:23:07.500888デフォルトの名無しさん
2011/12/19(月) 20:41:56.160889デフォルトの名無しさん
2011/12/19(月) 20:44:40.110890デフォルトの名無しさん
2011/12/19(月) 21:01:21.07XMLなんか使わなくても、git-svn/hgsubversion/hg-gitで相互乗り入れできる
bazaarはクソだからbzr-svn以外ダメダメだけど
0891デフォルトの名無しさん
2011/12/20(火) 21:29:21.84その場合は専用のバージョン管理ソフト使ってるってこと？
エイリアンブレインとか？
今のプロジェクトだと画像その他のリソースが30Gくらいあるんだが、
その管理どうするかでかなり悩んでるんで、どうしてるのか聞いてみたい。
0892デフォルトの名無しさん
2011/12/21(水) 01:47:58.01うちの職場だと、独自インフラツールを作って運用している。
話としては、Perforceとかエイリアンブレインあたりを耳にするね。
0893デフォルトの名無しさん
2011/12/21(水) 19:59:49.26http://twitter.com/#!/msdnjp/status/149414774063628288
0894デフォルトの名無しさん
2011/12/22(木) 07:16:21.440895デフォルトの名無しさん
2011/12/22(木) 08:44:17.780896デフォルトの名無しさん
2011/12/22(木) 10:33:27.510897デフォルトの名無しさん
2011/12/22(木) 10:59:09.88TFSは何か操作するたびにSQLServerがもりもりメモリーを食うのが泣ける。
リソースガバナー設定するしかないのかなぁ、アレなんか面倒そうだなぁ……
TFSを入れるなら多少でもSQLServerの知識がないとダメそうなのがつらい。
今さらサーバーレスなVSSに戻るつもりはないけど、運用の難易度が高いのがネックだね。
0898デフォルトの名無しさん
2011/12/22(木) 12:11:45.53svnにしとけばあとでgitにでもhgにでも行けるのに
0899デフォルトの名無しさん
2012/01/12(木) 22:31:04.33なぜかめでたくSubversionからTFSに移行したよ
アホが発言力持つとロクなことにならん…
0900デフォルトの名無しさん
2012/01/12(木) 22:36:44.82MSが、VSS殺して作った新しい奴なのね。
見た感じ管理者がExcelで管理したいが為に作られてるのか。
使い勝手が開発者視点じゃないんだろうな……
0901デフォルトの名無しさん
2012/01/12(木) 22:56:30.96svnにしとけばあとでgitにでもhgにでも行けるのに
0902デフォルトの名無しさん
2012/01/12(木) 23:38:42.340903デフォルトの名無しさん
2012/01/13(金) 02:14:38.15Macとかlinuxとか使ってる人どうするんですか？死ぬの？
0904デフォルトの名無しさん
2012/01/13(金) 02:24:38.67MacやLinuxからでも一応利用はできるよ。
ただしプラグイン自体の出来は微妙。
ぶっちゃけ親切心じゃなくて嫌がらせで公開してるんじゃないかと思う。
0905デフォルトの名無しさん
2012/01/14(土) 11:35:56.82>ぶっちゃけ親切心じゃなくて
内容はよくわかってないけど投資を承認する、偉い人を説得するためだろ。
0906デフォルトの名無しさん
2012/01/15(日) 03:15:07.590907デフォルトの名無しさん
2012/01/15(日) 07:02:37.17MSの作るものだから、どうせダイアログ出したままフリーズするんだろうなぁ
0908デフォルトの名無しさん
2012/02/21(火) 21:06:19.45http://d.hatena.ne.jp/nitoyon/20120221/msysgit_utf8
日本語ファイル名問題が解決したから、もう高速なGitを選ばない理由はありません。
これで日本でも次期デファクトスタンダードVCSはGitに確定ですね。
0909デフォルトの名無しさん
2012/02/21(火) 23:47:52.78ようやくWindowsでも普通に日本語ファイル名が使えるようになるのか。
0910デフォルトの名無しさん
2012/02/22(水) 01:23:16.19# つか、開発部隊の半数以上が欧米の連中なのにも関わらず
# 日本語ファイル名をつけるのはやめれ >某社の某プロジェクトの下っぱ
0911デフォルトの名無しさん
2012/02/22(水) 01:36:55.850912デフォルトの名無しさん
2012/02/22(水) 01:42:59.24それらがソースと一緒に管理できるのはいいことなのかな
Gitがドキュメント管理に向いてるのかという問題は置いといて。
0913デフォルトの名無しさん
2012/02/22(水) 07:13:22.65がっかり感が半端ないとか言わないよね
0914デフォルトの名無しさん
2012/02/22(水) 10:08:16.70Mercurialはfixutf8が先にあったから、今回のmsysgitはそれに追いついた。
Mercurialもfixutf8の機能を公式にするという動きがある。
これで問題になっているのは、過去のリビジョンをcheckoutできなくなること。
fixutf8では移行時にhg addremoveを使いましょうということになっていて、
fixutf8を無効・有効を切り替えればその時点のリビジョンのチェックアウトはできる。
今回のmsysgitがそこまで考えているか疑問。
0915デフォルトの名無しさん
2012/03/01(木) 23:43:57.100916デフォルトの名無しさん
2012/03/02(金) 11:56:14.61チェックアウトなりエクスポートなりしたファイルのタイムスタンプを
コミット時のそれにしたいってこと?
なんでまたそんな不便なことを……
0917デフォルトの名無しさん
2012/03/02(金) 13:10:13.89そう思うのはGitに慣れ切った証拠だね
0918デフォルトの名無しさん
2012/03/02(金) 13:11:19.460919デフォルトの名無しさん
2012/03/02(金) 13:15:18.59タイムスタンプなど不要って思ったのはなんで？
0920デフォルトの名無しさん
2012/03/02(金) 13:41:21.51普通に考えれば、古いコミットに戻してmake、ができなくなるのは不便だろうな。
cvsでもsvnでもgitでもhgでも同じ。
0921デフォルトの名無しさん
2012/03/02(金) 13:52:20.630922デフォルトの名無しさん
2012/03/02(金) 13:58:17.83へえ。逆(co時にコミット時間をタイムスタンプに設定する)ができるのは知ってたが。
0923デフォルトの名無しさん
2012/03/02(金) 14:07:12.430924デフォルトの名無しさん
2012/03/02(金) 14:10:51.080925デフォルトの名無しさん
2012/03/02(金) 16:23:33.54へぇ、そりゃWindowsｗの人が喜びそうだ。
0926デフォルトの名無しさん
2012/03/02(金) 16:32:38.670927デフォルトの名無しさん
2012/03/02(金) 16:51:30.09・しばしばタイムスタンプありきでファイル管理を行なっている。
・タイムスタンプが変わっていると天地が引っ繰り返ったように大騒ぎをする人がいる。
こんなところか?w
0928デフォルトの名無しさん
2012/03/02(金) 17:01:53.58> ・makeみたいなツールがないからタイムスタンプが更新されている必要がない。
はぁ？どんだけ物知らないんだよ
0929デフォルトの名無しさん
2012/03/02(金) 17:03:24.440930デフォルトの名無しさん
2012/03/02(金) 19:58:58.11バッチファイルを日本語のファイル名でわけわかんない名前にしたりとか
0931デフォルトの名無しさん
2012/03/02(金) 21:48:39.95それじゃ物識りの人が教えてくれまいか。
0932915
2012/03/03(土) 00:10:06.87>>916
ファイルのタイムスタンプで管理されていて、
それを変えて出すと怒られるんです(´・ω・｀)
バージョン管理とかされてなくて、ぼくは個人的に使っていたのです。
>>927
その通りです。タイムスタンプで管理されていて、変えると偉い人が有頂天になります。
>>921-923
それができるのですね。調べてみます。
ぼくは今、分散バージョン管理に興味を持っていて、そのどれかでできればいいなあと思ってたのですが。
いまのところ、Subversionだけなんですね。
0933915
2012/03/03(土) 00:12:21.12本当はもっと便利なスクリプト言語を使いたいのですが、
どのバージョンのWindowsでも特別なインストールや設定なしに普遍的にあるのがそれそかないんです(´・ω・｀)
管理で何かちょっとしたことをやろうと思うとそれしかないんです。
ぼくは日本語のファイル名は使いません(´・ω・｀)
0934デフォルトの名無しさん
2012/03/03(土) 00:13:49.440935915
2012/03/03(土) 00:16:58.39あ、はい。
それとPowerShellも考えたのですが、比較的新しめのWindowsにしか乗ってないのと、
デフォルトで乗ってるやつでも、スクリプトの実行を許可する設定にしないと動かないんです(´・ω・｀)
バージョン管理とレス違いですいません。
0936デフォルトの名無しさん
2012/03/03(土) 00:22:24.87まとめてインストールすりゃいいだろ
0937915
2012/03/03(土) 00:32:17.38いや、すいません。バッチファイルの話は乗っかっただけで、別の仕事の話です(´・ω・｀)
バージョン管理は今の仕事のお話です。
0938デフォルトの名無しさん
2012/03/03(土) 04:22:54.43実行ポリシーについて言えば、起動オプションで
-ExcutionPolicyに好きな値設定すればどうとでもなるよ(管理者権限不要)
0939デフォルトの名無しさん
2012/03/03(土) 05:42:58.08946 名前：デフォルトの名無しさん [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
これ使ってみました。
手間いらずでバッチリ希望通りの動きをしているようです。
どうもありがとうございました。
0940デフォルトの名無しさん
2012/03/05(月) 01:23:27.11開発しているのですが、一人作業でもSubversionから分散型に移行する
利点ってあります？
一人での作業だと分散型にする意味あまりなし？
0941デフォルトの名無しさん
2012/03/05(月) 01:36:48.40一人でさらにtrunk一本（ブランチを作らない）であれば、Subversionのままでも構わないだろう
0942デフォルトの名無しさん
2012/03/05(月) 02:19:34.16複数拠点で作業するなら、分散型の方が何かと好都合だぞ。
0943940
2012/03/05(月) 02:37:31.01レスありがとうございます。
リリース用にブランチ切って、リリースするタイミングでタグ付けして、リリース後はブランチは保守用として残すという
のと、たまーに実験機能用のブランチを切るというような一般的な使い方ですが、ブランチは使用しております。
このブランチの運用方法でいくと、ブランチの考え方が違うMercurialは無しですかね。
(運用方法を変えればいいという話もあるが・・・)
どうも家で一人で作業している場合、コミットの回数が1回多くなる(マスターへの反映)という手間が増えるだけでは・・・
とか考えてしまう。
速度的には自分のPCで鯖立ててる状態なので、分散型に変えても有利になるわけでもないですよね。
でも確かに、ノートPC持って外出するときとかは、マスターからノートPCのリポジトリに落としてコーディングして、
気が向いたときにマスターに反映させるとかいうのは楽でいい気もする・・・。
0944940
2012/03/05(月) 03:22:33.73(1)「msysGitがUTF-8をサポート」という記事を見て、分散型が気になり出す。
(2)分散型について調べて、いろいろと分散型の利点を学習。
その課程でGitの管理ファイル(.git)はルートディレクトリだけに置かれることを知る。
(3)Subversionの管理ファイル(.svn)が各ディレクトリにあることに若干嫌気がさしていた
ということもあり・・・Gitおいしいです（＾ｑ＾）。
(4)Subversionも1.7から管理ファイルが一つになったことを知る(現状、Subversion1.6を使っています･･･)。
(5)あれ、一人で作業するならSubversionを1.7にアップデートでよくね？
(6)いや、でも一人で作業する場合でも分散型にする利点あるのでは・・・。 ←いまここ
というわけで、Subversionから分散型に移行しようとした動機がかなり不純であったので、
一人作業での利点を色々考えたのですがしっくりこないということもあり質問した次第です。
(いい機会なので、分散型に移行しようかなという気分にですが、どうも最後の一押しが･･･)
0945デフォルトの名無しさん
2012/03/05(月) 03:31:01.61＞(4)Subversionも1.7から管理ファイルが一つになったことを知る
それは知らなかった。今度試してみよう。(git から乗り換える気はないけどね。)
0946デフォルトの名無しさん
2012/03/05(月) 03:41:42.34> このブランチの運用方法でいくと、ブランチの考え方が違うMercurialは無しですかね。
この運用方法だとMercurialの「名前付きブランチ」の方がしっくりくる。
Gitのブランチの方が違和感が大きい。
0947デフォルトの名無しさん
2012/03/05(月) 05:56:36.760948デフォルトの名無しさん
2012/03/05(月) 06:51:09.09別にsvnでもcsvでも分散は出来るんだが。。
分散型の利点は、実は分散でなはいという実感。
0949デフォルトの名無しさん
2012/03/05(月) 07:21:30.40分散自体はsvnsyncなりsvkでもできるし、ワーキングコピーと同じディレクトリにリポジトリ本体を置く分散型よりsvnスタイルのほうが安心な気はする。
0950デフォルトの名無しさん
2012/03/05(月) 07:48:48.19軽いし、サーバー立てなくてもいいし、実験用ならブランチしなくても丸ごと
cloneしちゃえばいいし。
svn は 1.7 でけっこう良くなったんだけど、まだ周辺ツールが
ついてきてない感じ……
0951デフォルトの名無しさん
2012/03/05(月) 08:29:37.18え? お呼びでない? こりゃまた失礼いたしました。
0952デフォルトの名無しさん
2012/03/05(月) 15:08:33.31その使い方ならわざわざマスターを別に作る必要がないんじゃない？
好きに履歴を改ざんできる気持ちよさ（手軽さ・気楽さ）に慣れるとsvnには戻れないな
0953952
2012/03/05(月) 15:15:14.19Git を例にとると、ルートディレクトリにしたい場所で「git init」で .git ディレクトリができる
これが管理ディレクトリでもありリポジトリそのものでもある
ノートPC持って外出するならそこからcloneして、帰ったらpushすればいい
0954940
2012/03/05(月) 20:10:51.96>>946
以下のページを見てみると
ttp://keijinsonyaban.blogspot.com/2010/10/successful-git-branching-model.html
Subversionの「タグ・リリース用ブランチ・実験用ブランチ・トランク」が、
Gitの「master・release + hotfix・feature・develop」ブランチにそれぞれ該当するという
ことになり、運用の考え方は同じになるのかなと思いまして。
(いや、そもそも作業ごとに全部ブランチを作って不要になったらブランチを消すという
運用が「ブランチの考え方」という点においてはSubversionとは全然違うところか)
Mercurialだと無名ブランチという物が存在して、ブランチ自体の考え方が違うのかと
考えてしまったのですが、むしろ基本的にはSubversionと考え方は同じで、さらに気軽
にブランチを切れるという感じでしょうか
Mercurialのブランチやタグの運用指標が書かれているページなどあれば教えて
いただけたら幸いです(探したが見つからず・・・)。
0955940
2012/03/05(月) 20:16:45.47Bazaarは情報が少ないのが何とも。分散型で検索してみると、ほとんどGitの情報で、
たまにMercurial、さらにたまにBazaarが出てくる感じですよね・・・。
>>948-950
CVSやSubversionよりも後発ということで、分散型を導入することで分散型とは関係ない
部分の利点の恩恵も受けられると。コミットした後に修正もれに気付いて再コミットでログ
が汚れるということが日常茶飯事なのでamendやrollbackはたしかに良いと思いました。
> 軽いし、サーバー立てなくてもいいし、実験用ならブランチしなくても丸ごと
> cloneしちゃえばいいし。
サーバー立てなくてもよいってのはリポジトリにfile://を指定できるSubversionでも同じでは
ないでしょうか？(そういう意味ではない？)
実験用ならその運用というのはなるほど納得。無駄なブランチができなくて良いですね。
0956デフォルトの名無しさん
2012/03/05(月) 20:18:39.55Mercurial Advent Calendar 2011
http://partake.in/events/902cd6d9-0215-4ea3-b51f-b8ff32e56426
あるプロジェクトのMercurial導入の軌跡
http://d.hatena.ne.jp/troter/20111225/1324823716
0957デフォルトの名無しさん
2012/03/05(月) 20:19:38.330958940
2012/03/05(月) 20:21:02.15> その使い方ならわざわざマスターを別に作る必要がないんじゃない？
なるほど。あくまでも複数人で作業する場合に成果物を共有するためにマスターリポジトリを
作成する必要があるわけであって、一人作業の場合はローカルリポジトリ自体がまさにマスター
リポジトリと考えればいいわけで、そこで作業してる分にはわざわざpush/pullの必要がないと。
> Git を例にとると、ルートディレクトリにしたい場所で「git init」で .git ディレクトリができる
> これが管理ディレクトリでもありリポジトリそのものでもある
DropBoxにリポジトリを置く運用をしているので、リポジトリは作業しているディレクトリとは別に
あった方がうれしいですが、たとえばGitだと「git --bare init」で可能みたいですね。
それにしても、このスレの住人は優しいですね。
一人作業でも利点が多いということが十分理解できました。
みなさま最後の一押しありがとうございます！
GitとMercurialの両方で仮運用してみて、気に入った方を使ってみようと思います。
0960デフォルトの名無しさん
2012/03/05(月) 21:29:32.33かつての俺ガイル
USB メモリなくして涙目になって
dropbox に置くようになった
仕事関係では mercurial 使ってて、
個人では bazaar 使ってる
ブランチの使い方が両者で全然違うので
ツールが違えば運用ルールも変わる的な
面倒くささがうざい
0961デフォルトの名無しさん
2012/03/05(月) 23:41:59.50リポジトリを別に置くのは--separate-git-dirでないかな。
--bareはサーバー用にワーキングディレクトリを使わない宣言だった希ガス
0962デフォルトの名無しさん
2012/03/06(火) 00:05:47.25ttp://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を使っているほかのサイトでも同様の問題が発生する可能性があるようだ
0963デフォルトの名無しさん
2012/03/06(火) 00:15:37.17ぼくはSubversionからBazaarに乗り換えたよ。
Bazaarも試してみてね。
0964デフォルトの名無しさん
2012/03/06(火) 00:16:25.05ファイルで。
0965デフォルトの名無しさん
2012/03/06(火) 03:54:39.10あまり簡単にならないんだよね。単にプロトコルが file://
になっただけというか。
まずリポジトリを作らなければならないし、
import したあとに作業コピーを作る必要があるし、
リポジトリと作業コピーを別々に管理する必要があるし……
0966デフォルトの名無しさん
2012/03/07(水) 08:30:06.47svnのあれがgitの場合これとか、gitのあれがhgのこれとか、そういう考え方だとはまるよ。
とっかかりとしては、いいかもしれんが。。
0967デフォルトの名無しさん
2012/03/07(水) 12:05:21.38私は逆に、ネットから切り離されている(客先の)環境でも使えるようにUSBメモリを使っている。
# このUSBメモリは更にTrueCryptで暗号化されているから紛失しても大事には至らない想定。
私物は、DropBoxだけどね。
0968デフォルトの名無しさん
2012/03/14(水) 17:59:17.47ですが、スクリプト内に（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にリネームして貰わなければなりません。
このリネームの手間を無くしたいのですが、どのようにするのが一番良いでしょうか？
アドバイス頂けると嬉しいです _ _
0969デフォルトの名無しさん
2012/03/14(水) 19:09:47.620970デフォルトの名無しさん
2012/03/14(水) 20:59:59.650971デフォルトの名無しさん
2012/03/15(木) 01:22:17.77環境変数やコマンドライン引数で設定ファイルの位置を指定できるようにして、
自分の環境ではそれらを指定して、自分用の設定ファイルを使うに一票。
0972デフォルトの名無しさん
2012/03/15(木) 22:24:57.41xmlなりjsonなりの形式にしてconfig.xmlが存在しなければ
config.default.xmlをconfig.xmlにコピーしてから読むようにtool.rbを書けよ
つかバージョン管理は全く関係ねー
0973デフォルトの名無しさん
2012/03/15(木) 23:56:02.490974デフォルトの名無しさん
2012/03/16(金) 20:20:36.59設定ファイルがなければコピーするのはそれでいいと思うが、
その３つのなかじゃ、セキュリティの問題がなければ、
設定ファイルとしては、.rbファイルが一番使いやすいよ。
特にxml は、誰にもメリットがない。xmlは、早く絶滅すべきフォーマット。
0975デフォルトの名無しさん
2012/03/16(金) 23:50:35.97マークアップランゲージとしては柔軟で強力だと思う
0976デフォルトの名無しさん
2012/03/25(日) 06:12:39.040977デフォルトの名無しさん
2012/03/26(月) 20:29:08.44http://sourceforge.jp/magazine/12/03/26/0529214
米Microsoftは3月21日、オープンソースソフトウェア向けの
ホスティングサービス「CodePlex」でGitをサポートすることを発表した。
これにより開発者は、Microsoft Team Foundation Server（TFS）、Subversion、
Mercurial、Gitからバージョン管理システムを選択できるようになる
0978デフォルトの名無しさん
2012/03/28(水) 01:33:32.43Subversion、TortoseSVNつかってるなら、普通にアップデートして
作業コピーもアップデート適用すれば、すぐに変更適用できるよ。
あまりに量が多いと大変だろうけど、便利になった。
0979デフォルトの名無しさん
2012/04/18(水) 02:27:35.200980デフォルトの名無しさん
2012/04/18(水) 03:01:27.920981デフォルトの名無しさん
2012/04/18(水) 07:32:55.130982デフォルトの名無しさん
2012/04/18(水) 07:33:18.740983デフォルトの名無しさん
2012/04/19(木) 01:35:48.00バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/
レス数が950を超えています。1000を超えると書き込みができなくなります。