トップページ⇒tech
1001コメント282KB

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

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2009/10/11(日) 15:18:42
バージョン管理システムについて語りましょう。

●関連スレ
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ～ Rev.3 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1254838551/
git スレッド [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1197798039/
Bazaarでバージョン管理【bzr>git,svn,cvs】 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1218083381/

●過去スレ
バージョン管理システムについて語るスレ
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/
0002デフォルトの名無しさん2009/10/11(日) 15:19:24
●関連サイト
CVS
http://ximbiot.com/cvs/cvshome/
Subversion
http://subversion.tigris.org/
Git
http://git-scm.com/
Bazaar
http://bazaar-vcs.org/
Mercurial
http://www.selenic.com/mercurial/wiki/
Darcs
http://www.darcs.net/
GNU arch
http://www.gnu.org/software/gnu-arch/index.html
monotone
http://www.monotone.ca/
Visual SourceSafe
http://www.microsoft.com/japan/msdn/ssafe/

●チュートリアル
Subversionによるバージョン管理(日本語訳)
http://subversion.bluegate.org/
Git入門
http://www8.atwiki.jp/git_jp/
Bazaar Documentation Overview
http://bazaar-vcs.org/Documentation
Mercurial の使い方のチュートリアル
http://www.selenic.com/mercurial/wiki/JapaneseTutorial
0003デフォルトの名無しさん2009/10/11(日) 15:27:28
>>1乙
でも関連スレ抜けてるぜ

【分散型バージョン管理】 Mercurial 【hg】
http://pc12.2ch.net/test/read.cgi/tech/1251208950/
0004デフォルトの名無しさん2009/10/11(日) 15:28:36
1Z
0005デフォルトの名無しさん2009/10/11(日) 15:29:58
>>3
おお、すまん
0006デフォルトの名無しさん2009/10/11(日) 20:25:50
バックアップをとりたいんだったら
定期的にclone/pullするだけ
0007デフォルトの名無しさん2009/10/11(日) 20:32:02
svndumpだろ
0008デフォルトの名無しさん2009/10/11(日) 20:58:33
githubならぬbzrhubに期待age
0009デフォルトの名無しさん2009/10/11(日) 21:05:11
launchpadでいいじゃん
0010デフォルトの名無しさん2009/10/11(日) 21:24:01
>>9
launchpadってなんかsourceforgeみたいなんだよね。そうじゃなくて、githubやbitbucketを期待している。
ニュアンスの問題？なんだけど
0011デフォルトの名無しさん2009/10/11(日) 21:42:36
誰でもブランチをプロジェクトに紐付けられるから、githubやbitbucketの方に近い気がする>launchpad
0012デフォルトの名無しさん2009/10/12(月) 00:06:18
launchpadはかなり良くできてるよ。
sourceforgeが貧相に見える。
0013デフォルトの名無しさん2009/10/12(月) 00:16:22
Trac っていいですか？
0014デフォルトの名無しさん2009/10/12(月) 00:21:39
だんだんスレ違いになってきてね？
0015デフォルトの名無しさん2009/10/12(月) 10:01:02
会社の比較的大きな（数十人）プロジェクトで使えるものを検討しています。
無料、有料どちらでもかまわないので、皆様のお薦めのバージン管理システムを教えてください。
0016デフォルトの名無しさん2009/10/12(月) 10:09:33
・数十人なんかぜんぜんたいしたことない
・OSは？
・IDE使うなら何使ってるのか？
0017デフォルトの名無しさん2009/10/12(月) 10:11:07
svn
0018デフォルトの名無しさん2009/10/12(月) 12:12:05
>>15

>>16に追加して、
・日本語ファイル名使う？
・メンバーのクライアントOSは？
・サーバーOSは？
0019デフォルトの名無しさん2009/10/12(月) 12:22:28
>>15
gitかbzrで良いよ
コツはモジュールの開発者毎にブランチを分けることね。
0020デフォルトの名無しさん2009/10/12(月) 12:47:49
>>15
確実なのは貞操帯
0021デフォルトの名無しさん2009/10/12(月) 13:21:17
代表がそんな程度なら、使わないほうがいいよ
0022デフォルトの名無しさん2009/10/13(火) 11:24:38
>>19
ありえねーよ。
0023デフォルトの名無しさん2009/10/13(火) 13:51:47
>>15
SVN
・比較的ドキュメントがそろっている
・問題があったときも情報が検索で出てきやすい

どうも、メンバーが技術的にバージョン管理系のソフトに
慣れてなさそうなので情報の少ないソフトはやめておいた方がいいと思います。

余裕があるなら、分散管理系が開発者としては楽なんだけどね。
0024デフォルトの名無しさん2009/10/13(火) 17:51:44
>>15
perforce
個人的に頭のおかしいやつが多いbzrだけはやめとけwww
0025デフォルトの名無しさん2009/10/13(火) 18:16:35
日本でperforce使ってるやつなんて居るの? Google除いて
0026デフォルトの名無しさん2009/10/13(火) 18:54:13
>>25
集中型で一番まともなのがperforce
使ってるところも沢山ある。
0027デフォルトの名無しさん2009/10/13(火) 18:58:59
>>26
>沢山
kwsk
0028デフォルトの名無しさん2009/10/13(火) 19:04:23
>>26
>集中型で一番まともなのがperforce
kwsk
0029デフォルトの名無しさん2009/10/13(火) 19:34:12
>>26
>>>25
kwsk
0030デフォルトの名無しさん2009/10/13(火) 19:42:05
>>26
>2009/10/13(火) 18:54:13
kwsk
0031デフォルトの名無しさん2009/10/13(火) 19:53:59
ksks
0032デフォルトの名無しさん2009/10/13(火) 19:54:09
我慢していたが限界だ。
俺はココに突っ込みたくて仕方ない。

>>15
>バージン管理システム

エロい意味でなくなぜ誰も突っ込まないのかと、
皆のスルー力に脱帽した。
0033デフォルトの名無しさん2009/10/13(火) 19:59:27
素で気づかなかったわ・・・
0034デフォルトの名無しさん2009/10/13(火) 20:05:56
perforceってGoogleに使われてるってことで知ったけど、それまで名前も聞いた事無かったな。
日本で無名なだけなんだろうか。
0035デフォルトの名無しさん2009/10/13(火) 20:07:22
使われてないだけだと思う
0036デフォルトの名無しさん2009/10/13(火) 20:08:28
やっと20の意味が分かった
0037デフォルトの名無しさん2009/10/13(火) 21:41:11
AppleもPerforceじゃなかったっけ
0038デフォルトの名無しさん2009/10/13(火) 21:41:52
perforceといえばjam
0039デフォルトの名無しさん2009/10/13(火) 22:39:12
>>26
まじ？初めて聞いた。

具体的にOSSなどの採用実績を教えてください
0040デフォルトの名無しさん2009/10/14(水) 01:04:33
Perforce(p4)っつーと、FreeBSDかなぁ。
0041デフォルトの名無しさん2009/10/14(水) 01:19:37
FreeBSDはsvnに移行してなかった?
0042デフォルトの名無しさん2009/10/14(水) 01:25:52
ksk
0043デフォルトの名無しさん2009/10/14(水) 01:42:51
gitでAというタグが打たれた時のaというファイルの内容を見るのに、今は git ls-tree A a としてから git show をしてるんだけど、これを一発で直接見る方法はあますか？
0044デフォルトの名無しさん2009/10/14(水) 01:45:26
bzr-gitを入れて(ry
0045デフォルトの名無しさん2009/10/14(水) 02:20:54
>>44
へぇー bzrってそんなこともできるんだwww
0046デフォルトの名無しさん2009/10/14(水) 09:52:51
>>40
master repository的な意味合いで行くとcvsからsvnに移行してる。
p4のrepositoryがmaster repositoryだったことはない。
好き勝手に開発したいけどcvsのbranch使いにくいってことでp4使い始めた人達がいたけど、
svnに移行した以上p4使い続ける意味はないはず。
0047デフォルトの名無しさん2009/10/14(水) 10:08:26
単に「使ってる」って意味合いだけで挙げたんだが……まあいいか。
0048デフォルトの名無しさん2009/10/14(水) 10:14:19
ああ、いいならいいや。
master repositoryがp4だった時期はないってことをはっきりさせときたかったんでね。
0049デフォルトの名無しさん2009/10/14(水) 13:31:32
GitのC#実装「GitSharp」、バージョン0.1.3リリース
ttp://sourceforge.jp/magazine/09/10/14/0313228
0050デフォルトの名無しさん2009/10/15(木) 10:48:44
>>49
C#でgit？はぁ誰得だよ、と思ってたら、
Windows用gitの救世主となるのかな。これは期待。
0051デフォルトの名無しさん2009/10/16(金) 12:49:48
記事見るまで知らなかったけど java 実装の git なんてのもあるのか。
たしか ruby 実装のもあるって話が前スレであったと思うし、なんか色々乱立してかえってややこしいことになりそうだなぁ
0052デフォルトの名無しさん2009/10/16(金) 14:01:54
前スレに出てたのはgitのpython実装であるdulwichのことでしょ。bzr-gitに使われてるやつ。
0053デフォルトの名無しさん2009/10/16(金) 14:49:21
OpenOffice.org、ソースコード管理ツールを「Mercurial」に移行へ
http://sourceforge.jp/magazine/09/10/16/033250
0054デフォルトの名無しさん2009/10/16(金) 16:38:29
>>53
これでまた暴動でも起こるんですかねwww
0055デフォルトの名無しさん2009/10/16(金) 17:31:40
なんで？
0056デフォルトの名無しさん2009/10/16(金) 17:56:58
うーん やっぱりMercurialが今後主流になるのですかねえ…
どれが主流になるか判らなかったんでずっと様子見してたけど
そろそろ使い方を勉強しても、無駄にはならないか…
0057デフォルトの名無しさん2009/10/16(金) 17:58:31
OOoってCVSだったのか…未だにCVSのとこってけっこうあるんだねぇ
0058デフォルトの名無しさん2009/10/16(金) 18:22:30
この一見だけで Mercurial って思えるのが不思議。
乗り換え先が git のほうがプロジェクト的に多いだろ。
0059デフォルトの名無しさん2009/10/16(金) 18:38:04
SunがMercurial好きってだけじゃね？
0060デフォルトの名無しさん2009/10/16(金) 18:41:34
>>59が正解。
でも太陽に陰りが見えるから、メルクリウス神がろくでなしになるのも時間の問題。
0061デフォルトの名無しさん2009/10/16(金) 19:56:07
>>60
あはは。そんな馬鹿な

と言い切れないのが怖いです…
Sunって桃鉄で言うところの
0062デフォルトの名無しさん2009/10/16(金) 22:10:16
ここまで来てGitとhgのどちらかが潰れるとは思えないがねぇ
そう思える人はよほど相手を潰したい人なんでしょ
0063デフォルトの名無しさん2009/10/16(金) 22:21:35
誰もそんなこと言ってないが。
>>60はSunがOracleに買われて、hgからgitびいきに変わるだろうって予言しょ。
0064デフォルトの名無しさん2009/10/16(金) 22:25:41
太陽に陰り→日蝕→Eclipse→IBM→Clear Case
やっぱりIBMに買われてた方が自然だったな>Sun
0065デフォルトの名無しさん2009/10/16(金) 22:56:59
でも、IBM Rational ClearCaseになるのは勘弁
0066デフォルトの名無しさん2009/10/16(金) 23:13:23
もう飽きたし面倒くさいからSubversionとRCSでいいや(´・ω・｀)
0067デフォルトの名無しさん2009/10/16(金) 23:52:04
bzrにしようと思ってたんだが、人気ねー
0068デフォルトの名無しさん2009/10/17(土) 00:38:42
TortoiseRCSがあったらいいというのに(´・ω・｀)
0069デフォルトの名無しさん2009/10/17(土) 10:22:47
ローカルでしかバージョン管理しなくても、今や分散型を（限定的に）使えばいい時代だから、RCSがこれから顧みられることはないだろうなぁ
0070デフォルトの名無しさん2009/10/17(土) 11:58:09
gentooだと/etc以下、設定ファイルなんかの世代管理ツールのバックエンドにRCS使ってたと思う。
0071デフォルトの名無しさん2009/10/17(土) 14:14:38
みなさんに質問なのですが、
あるディレクトリ以下のバージョン管理を始めたあとに、
その親ディレクトリもバージョン管理しないといけなくなった場合、
どのようにしますか？

たとえば
$HOME/src/hogehoge.c を src を基点にバージョン管理を始めたあとに
$HOME/.bashrc のバージョン管理をしたくなったらどうしますか？
0072デフォルトの名無しさん2009/10/17(土) 14:22:00
>>71
./hogehoge.cを./src/hogehoge.cに移動
0073デフォルトの名無しさん2009/10/17(土) 14:22:04
できるだけ最初からディレクトリ構成を練っておく。
もしそうなった場合は移動するだけ。
CVSでもなければ移動は簡単でしょ。
0074デフォルトの名無しさん2009/10/17(土) 14:49:34
>>71
みたいな例は.bashrcがそもそも移動できない例だけど、
逆にそういう実際の例が思いつかないな…。
unixやVista以降なら、ファイル単体のシンボリックリンク張ればいいのかね。
0075デフォルトの名無しさん2009/10/17(土) 19:50:08
>>74
俺様は~/configの下に設定ファイルを集約してシンボリックリンクにしてる。
eg ln -s config/emacs .emacs
0076デフォルトの名無しさん2009/10/17(土) 19:52:27
>>70
ファイル単位の履歴で十分な用途だとRCSでもいいかもね。
RCSだと余計なライブラリとか言語処理系は不要だし
いざというときのサルベージでは安心できる。
0077デフォルトの名無しさん2009/10/18(日) 11:35:08
クリアケースの話題が定期的にあがるのでWikipedia貼っておく。

・Rational ClearCase
http://ja.wikipedia.org/wiki/Rational_ClearCase

＞欠点 [編集]
＞トランザクションがアトミックでない。
＞コードベースが古く、新規機能追加が遅い。
＞非常に複雑で、構成設定に注意を要する。
＞遅い。単純なコミットやチェックアウトが数分かかることも稀ではない。

個人的に、開発で使うには非常に致命的だと思うが。
0078デフォルトの名無しさん2009/10/18(日) 13:20:01
RCSとか言ってるやつはネタだろ。
そんなマジレスしなくても
0079デフォルトの名無しさん2009/10/18(日) 19:01:11
bzr-git用に開発されたPythonのgitライブラリdulwichを使った、
hg-gitの初期バージョンがリリースされた。
http://hg-git.github.com/
0080デフォルトの名無しさん2009/10/19(月) 14:44:24
>>77
いやだからクリアケース使ってる人の大半は
そんな欠点は百も承知の上で IBM がらみで仕方なく使ってるんだってば
0081デフォルトの名無しさん2009/10/19(月) 15:14:48
いいこと思いついた。
ClearCaseは使うふりにとどめて、実際の作業では別のVCS使えばいいんじゃね？
IBMが「ClearCaseを全ての場面で実際に動かしているか」なんて逐一チェックしているなら無意味だが。
(スパイウェアでも仕込まない限りは…ね)
0082デフォルトの名無しさん2009/10/19(月) 20:31:05
Wikipediaの記事見たけど、これが1990年代に開発されたことを考えればすごく野心的だな。
「svn? git? それは我々が20年前に通過した場所だ！」とか何かのインタビューで豪語していた
のも分からんでもない。

最大の問題は、理論だけが先行しちゃった上にコードが古すぎるって事ではあるんだろうな。
0083デフォルトの名無しさん2009/10/19(月) 22:09:49
で?
0084デフォルトの名無しさん2009/10/20(火) 11:12:58
っていう
0085デフォルトの名無しさん2009/10/20(火) 11:13:40
理論だけで役にはたたない。
それ何てタネンバウム？
0086デフォルトの名無しさん2009/10/20(火) 12:04:05
astはちゃんと実装までやったし、その実装も教育用のものとしては依然として
使いものになるからその批判はまとまずれ。
0087デフォルトの名無しさん2009/10/20(火) 12:11:04
ClearCaseと同じじゃん
0088デフォルトの名無しさん2009/10/20(火) 12:12:20
実用 git, linux
--------- 越えられない壁 ----------
教育用 ClearCase, タネンバウム
0089デフォルトの名無しさん2009/10/20(火) 12:14:16
犬のコードなんか教育用に使えたもんじゃないしな.
0090デフォルトの名無しさん2009/10/20(火) 12:33:02
BSDは教科書どおりに無駄なフィールドあるしな。
プロセス構造体とかw
教科書とおりって意味では教育的だがw
0091デフォルトの名無しさん2009/10/20(火) 13:55:13
task_structとか、mm_structとか、_struct付けるのはあたまわるいとしかおもえないんですが.
0092デフォルトの名無しさん2009/10/20(火) 15:06:49
さあ、盛り上がってまいりました。
0093デフォルトの名無しさん2009/10/20(火) 18:18:06
linuxは、頭が悪いやつがつくっても
目玉の数が多ければ大丈夫という開発モデルだからね。
0094デフォルトの名無しさん2009/10/20(火) 18:33:47
BSDは頭のいいやつが考えるんだが、時間が掛るし頑固者が多いので
なかなか進まないという
0095デフォルトの名無しさん2009/10/20(火) 19:20:22
http://www.microsoft.com/japan/msdn/vstudio/campaign/vsstotfs/
触った事がないんだけどコレって使いやすい？
てか、MSの中の人使ってんのかな。
0096デフォルトの名無しさん2009/10/20(火) 23:00:30
ひとり７万ってなめてんの？
0097デフォルトの名無しさん2009/10/20(火) 23:10:57
VSSからどの程度改善されてるんかね。
というか、どこの製品を買収したんだ。
0098デフォルトの名無しさん2009/10/20(火) 23:16:35
　　　　　　　　ヤタ！朕が９８げっとだ！！お前等朕にひれ伏せ！クソ共が！
　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　 　　 /＼ ／＼　　／神＼/../
　　　　 　　 　 /　／＼　 ＼（´∀｀　）./
　　　　　　 　（）)ノ__　○二○二⌒/../
　　　　　　 ／ ／||(二ニ) （＿＿_/../　几l
　　　γ ⌒ ／|Ⅲ||彡Ｖミ/⌒＿ノ二二ノl0
　　　l|　(◎).|l　|((||（(ﾟ )/⌒/||三三三・） ||　　(´⌒(´
＿＿ ゝ_＿ノ　 　　￣（_＿_）￣　　ゝ＿_ノ≡≡≡(´⌒;;;≡≡≡
　　　　　　　￣￣￣￣￣￣￣￣￣￣￣(´⌒(´⌒;;
朕は神なり！朕は神なり！朕は神なり！朕は神なり！朕は神なり！朕は神なり！朕は神なり！
朕　IS　GOD！朕　IS　GOD！朕　IS　GOD！朕　IS　GOD！朕　IS　GOD！
0099デフォルトの名無しさん2009/10/21(水) 01:06:21
Windowsで立ち上げてるsvnservにMax OS Xからアクセスするときに、
ホスト名ってどうやって指定したらよいんでしょう・・・。
0100デフォルトの名無しさん2009/10/21(水) 01:13:08
IPアドレスかNetBIOS名でいいんじゃないの
0101デフォルトの名無しさん2009/10/22(木) 18:56:59
>>99
ネットワーク管理人に聞け。
0102デフォルトの名無しさん2009/10/25(日) 01:30:46
現在研究室ではTortoiseSVNをローカルのリポジトリのみで使用しています。
作業コピー（orコピー）をUSBメモリに入れて自宅でもコーディングをしたいのですが
自宅PCなのでTortoiseSVNみたいにシェル統合されたくありません。
TortoiseSVNみたいにSubversion無しで（TortoiseSVN単体で）使用できるようなシステムは無いでしょうか。
欲を言えばUSBメモリでリポジトリ＋システム全部が持ち運びできるようなものがいいです。
0103デフォルトの名無しさん2009/10/25(日) 02:36:11
>>102
> 自宅PCなのでTortoiseSVNみたいにシェル統合されたくありません。
> TortoiseSVNみたいにSubversion無しで（TortoiseSVN単体で）使用できるようなシステムは無いでしょうか。
Subversion無しでどうやってTortoiseSVNを使うんだよ・・・。
クライアントだけあってもしょうがないだろうに。
0104デフォルトの名無しさん2009/10/25(日) 03:55:36
>>103
TortoiseSVNはスタンドアロンでリポジトリの作成～インポート～チェックアウト～Diff～コミットなどなどできるんよ
0105デフォルトの名無しさん2009/10/25(日) 04:24:31
>>103
すげぇ～、実はTortoiseSVNの事、これっぽっちも知らなかったのに
この上から目線の「俺は何でも知ってるんだよ！カス！」口調。

さすが2chだ、何ともないぜ。
0106デフォルトの名無しさん2009/10/25(日) 07:55:23
>>102
シェル統合が嫌なのはわかったが、CUIがいいのか、WinCvsみたいなスタンドアロンのGUIがいいのか。
01071022009/10/25(日) 10:15:50
TortoiseSVNみたいにGUIで出来たほうがいいです。
0108デフォルトの名無しさん2009/10/25(日) 10:23:53
RApidSVNとかなんとかいうのあるはずだろ。
というかなんでぐぐらんの？
0109デフォルトの名無しさん2009/10/25(日) 10:47:43
ググるのくらいお前らがやってくれよ
0110デフォルトの名無しさん2009/10/25(日) 13:04:07
そもそもググる必要なくね？
subversionのウェブサイトへ行けば、殆ど必要な物すべてにリンクが通じてるぞ。
0111デフォルトの名無しさん2009/10/25(日) 13:31:34
git svnがお勧め
GUIなし、svnが陳腐に見えて使えなくなること請け合いだが
0112デフォルトの名無しさん2009/10/25(日) 14:24:11
ClearCaseは糞
0113デフォルトの名無しさん2009/10/25(日) 14:28:40
>>102
svnやめてgitにしたらいいよ
hgでもいいけど
01141022009/10/25(日) 14:31:30
>>108
RapidSVNはGUIフロントエンドで結局Subversionも入れないとダメみたいな記事を見かけたもので、
一応ググったんですけど、TortoiseSVNみたいに単体で使えるものが見つからなかったのでここで聞いてみました。

>>110
subversion無しで使えるものが欲しいのです。

>>111-112
ありがとうございます。調べてみます。
0115デフォルトの名無しさん2009/10/25(日) 14:40:10
>>114
君の使い方ならsubversionじゃない方がいいんじゃないか？
中央集権型のリポジトリと相性が悪そう。
分散リポジトリを検討するが吉
0116デフォルトの名無しさん2009/10/25(日) 14:42:18
subversion不要ってのが意味不明だなw
リポジトリ自体が不要？
I/Fだけあってもしかたないのに

何の恩恵を受けてるか自覚が出るまで放置だな
0117デフォルトの名無しさん2009/10/25(日) 14:51:57
TortoiseSVNのシェル拡張じゃないやつが欲しいんだろ
何でそんなつまらんことにこだわってんのかわからんけどさ
0118デフォルトの名無しさん2009/10/25(日) 14:56:37
ようするにインストールの仕方がわかんないんだろJK
0119デフォルトの名無しさん2009/10/25(日) 16:16:24
TortoiseSVNにもsubversionはいってるはずだがｗ
0120デフォルトの名無しさん2009/10/25(日) 16:26:50
ようするにCUIは使えないってことか
分散は100年早いよw
0121デフォルトの名無しさん2009/10/25(日) 18:35:22
別にSubversion入れればいいじゃんって思うけど入れるのがダメな理由なんなわけ
0122デフォルトの名無しさん2009/10/25(日) 18:51:36
Rational ClearCase なんて使うならCVSの方がよっぽどまし。
つーか、Subversion使えよ。おすすめ。

ClearCaseなんぞIBM工作員しかマンセーしないから。
0123デフォルトの名無しさん2009/10/25(日) 18:53:59
tortoiseSVNをインストールせずに、リポジトリの入ったUSBをさしたところで使いたいってことだと思う。確かに、制限ユーザーだとインストールできないし。

subversionのコマンドライン版を使う。
GUIが欲しいなら、Python版のGUIクライアントがあったと思うけど。
0124デフォルトの名無しさん2009/10/25(日) 18:54:32
バージョン管理システム略してバーカン
0125デフォルトの名無しさん2009/10/25(日) 18:55:54
バカシス
0126デフォルトの名無しさん2009/10/25(日) 19:11:27
>>123
そんな時はsvnじゃなくてgitか水銀だろJK
リポジトリもワークも同じだからUSBで無問題。
しかし、GUIが欲しいＪＫには使いこなすのはムリポ
0127デフォルトの名無しさん2009/10/25(日) 19:26:02
bzrはポータブル版（nonadmin?)があったような、、
bzr-svnでいけんじゃね？
0128デフォルトの名無しさん2009/10/25(日) 19:28:31
話の限りではsvnじゃなくてbzrがベストなんじゃね
確かスタンドアロンのGUIが標準添付だったはずだし

伝聞だけで使ったことが無いもんだから、お勧めできる立場には無いけど
0129デフォルトの名無しさん2009/10/25(日) 19:29:19
その前に学校で開発してて、windows使ってるのがありえない

最近の情報学科もゆとりなわけ？
0130デフォルトの名無しさん2009/10/25(日) 19:30:49
>>129
ヒント:JK
0131デフォルトの名無しさん2009/10/25(日) 19:32:08
そういえば、M$のOS上にリポジトリ置いたことないから
お勧めできる立場にないや
0132デフォルトの名無しさん2009/10/25(日) 19:33:49
>>129
熱くなる気持ちは分からんでもないが、WindowsにVisual Studioの組み合わせが主流の学校は別に珍しくないよ
0133デフォルトの名無しさん2009/10/25(日) 19:34:20
なんか盛り上ってまいりました
0134デフォルトの名無しさん2009/10/25(日) 19:36:30
>>132
Visual Studioもいいが、そこでSVN使うの？
SourceSafeとかあったような
0135デフォルトの名無しさん2009/10/25(日) 19:42:07
>>134
お前もゆとりなわけ？
0136デフォルトの名無しさん2009/10/25(日) 19:44:55
JKがいると雰囲気変るよね

明るくなるっていうのは、おバカで明るくなる
0137デフォルトの名無しさん2009/10/25(日) 19:52:05
>>134
SourceSafeだけは あ り え な い
0138デフォルトの名無しさん2009/10/25(日) 19:52:52
>>135
俺は学生の時からlinuxばっかりだな
0139デフォルトの名無しさん2009/10/25(日) 19:55:12
>>137
Windowsで開発がありえない
0140デフォルトの名無しさん2009/10/25(日) 19:56:45
M$製品使うなら統一しなきゃ
バージョン管理だけsubversionってw
0141デフォルトの名無しさん2009/10/25(日) 19:56:57
おまえらVSSの話はかまわんがVSとWindowsの話はスレ違いだ
0142デフォルトの名無しさん2009/10/25(日) 19:59:39
わかりましたー 先生
0143デフォルトの名無しさん2009/10/25(日) 20:03:57
VSSとかMS自身からも見捨てられた骨董品じゃねえか
今さら進んで選択する人なんているの？
0144デフォルトの名無しさん2009/10/25(日) 20:09:11
教育に使うならM$と心中したらいいのにな
せめてsubversionでなくM$社内で使ってるものにしたら？
0145デフォルトの名無しさん2009/10/25(日) 20:15:12
何やら過激派が紛れ込んでいる様子
0146デフォルトの名無しさん2009/10/25(日) 20:43:43
そいでJKはまだ帰ってこないのか
0147デフォルトの名無しさん2009/10/25(日) 22:56:37
>>143
ちょっと上にレスしてるWindows(笑)って馬鹿にしてる無知な奴らだろうね。
VSにSVNアドオンとか普通にあるのにｗ
0148デフォルトの名無しさん2009/10/25(日) 23:02:29
svnも時代遅れだよ
無知なやつら
0149デフォルトの名無しさん2009/10/25(日) 23:04:34
VSにはVSSがお似合い。プップッ
0150デフォルトの名無しさん2009/10/25(日) 23:08:54
しかし、お前ら馬鹿にされ過ぎだぜ。
言い返す技量もないと見える
0151デフォルトの名無しさん2009/10/26(月) 02:51:26
>>148
え？そこ？さすが有能な方は理解しがたい所を指摘しますなぁ・・・
0152デフォルトの名無しさん2009/10/26(月) 13:27:09
bzr には bzr-explorer というシェル拡張じゃないGUIがあるよ。
標準のインストーラーでは、デフォルトでbzr explorer がインストールされて、
TortoiseBZRはデフォルトではインストールされない。
0153デフォルトの名無しさん2009/10/26(月) 13:56:24
>>151
おまえ分散使ったことないだろ
0154デフォルトの名無しさん2009/10/26(月) 14:03:38
そういう話じゃないだろうｗ
0155デフォルトの名無しさん2009/10/26(月) 15:34:54
svnが最高と思ってる奴らに何を言っても無駄なようだ
0156デフォルトの名無しさん2009/10/26(月) 15:38:02
個人なら好きなの使えるけどな
実際は他の人が変えたら無い訳で
0157デフォルトの名無しさん2009/10/26(月) 15:40:10
普段使ってるツールが対応してるとかアドインがあるかどうかでも変わってくるしな
0158デフォルトの名無しさん2009/10/26(月) 15:47:08
それは分るな。
gitにしたいけど周りのこと考えて無難にsvnをベースのリポジトリにしてる
自分だけはgit-svnで快適に暮す
0159デフォルトの名無しさん2009/10/26(月) 16:15:30
他が安定してればsvnじゃなくてもいいんだけどな
0160デフォルトの名無しさん2009/10/26(月) 16:31:31
gitやHGの使い方覚えるくらいなら他の事勉強するって10人に8人は答える
0161デフォルトの名無しさん2009/10/26(月) 16:39:58
そしてその半分以上は勉強以外にその時間を使う
0162デフォルトの名無しさん2009/10/26(月) 16:40:46
で、結局CVSやSVNで我慢する
0163デフォルトの名無しさん2009/10/26(月) 16:45:09
一方、gitを覚えた奴は賢いマージ、軽いブランチなどにより
生産性があがり、自由な時間が増える
0164デフォルトの名無しさん2009/10/26(月) 16:46:28
その自由時間で他の事も勉強できる
0165デフォルトの名無しさん2009/10/26(月) 16:46:36
生産性あげても他の人の遅れをフォローするハメにあって結局
0166デフォルトの名無しさん2009/10/26(月) 16:47:53
gitのおかげでハゲが治りました
0167デフォルトの名無しさん2009/10/26(月) 16:55:25
その時間があるからこんなスレでくだらないことも書きこめるわけだな
0168デフォルトの名無しさん2009/10/26(月) 17:28:17
そう!gitサイコー
0169デフォルトの名無しさん2009/10/26(月) 20:18:48
ワラタｗ
このスレエディタでコーディングしてる奴多そうだな
0170デフォルトの名無しさん2009/10/26(月) 20:26:36
そしてvim vs emacsまでこなせるのかこのスレは。優秀だな。
0171デフォルトの名無しさん2009/10/30(金) 09:51:27
git より hg の方が良さげだ。
0172デフォルトの名無しさん2009/10/30(金) 10:05:32
今月号 Software Design が git 特集なんだね
0173デフォルトの名無しさん2009/10/30(金) 10:44:13
Windowsでgit-svn使おうとして絶望した
0174デフォルトの名無しさん2009/10/30(金) 13:26:55
ギットギットにしーてやんよ
0175デフォルトの名無しさん2009/10/30(金) 17:26:40
なんでgitはメンテナが日本人なのにWindowsでの日本語ファイル名扱いがうんこなの？

Windowsがウンコとか言われると反撃できないのでそれはやめてね
0176デフォルトの名無しさん2009/10/30(金) 17:30:04
gitはLinuxの開発のために作られたから、Posix API にベッタリ依存しているだけ。
unicode cygwin使え。
0177デフォルトの名無しさん2009/10/30(金) 22:47:24
ファイル名のローカルなエンコーディングの話は丁度この辺で話題になっているような。
首尾よく行けば将来のリリースに反映されるかもしれんね。

http://www.spinics.net/lists/git/msg115769.html
0178デフォルトの名無しさん2009/11/03(火) 17:50:05
結局、svnの次は、hg,git,bzr 三強時代ということ？
0179デフォルトの名無しさん2009/11/03(火) 18:29:26
>>178
bzrはないwww
Ubuntuに関わると必須になるのはただの悪夢
0180デフォルトの名無しさん2009/11/03(火) 19:05:00
世界的にみると今さらbzrは無いだろうとは俺も思うが、日本じゃこれからbzrが主流になる可能性はまだある
0181デフォルトの名無しさん2009/11/03(火) 19:11:00
この三強のどれかが今更廃れるとも思えないがな
0182デフォルトの名無しさん2009/11/03(火) 22:16:37
Windowsの本命はGitSharpかもしれない…
0183デフォルトの名無しさん2009/11/03(火) 22:20:13
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
　　　　　　　　　　　 　 　 　 　 　 　 |
　　 　 　 ＿＿＿＿.＿＿＿＿ 　　 |
　　　　　|　 　 　 　 | 　 　 　 　|　　 |　 　RationalClearCaseを
　　　　　|　 　 　 　 | ∧＿∧　|　　 | 　　窓から
　　　　　|　 　 　 　 |（　´∀｀）つ ミ | 　　投げ捨てろ
　　　　　|　 　 　 　 |/ ⊃　 ﾉ　|　　 |
　 　 　 　￣￣￣￣'￣￣￣￣　 　 | 　　 ミRationalClearCase
0184デフォルトの名無しさん2009/11/04(水) 01:46:00
英語圏の(マルチバイト文字不要な)奴らが実質主導という悲しい現実。
0185デフォルトの名無しさん2009/11/04(水) 04:26:45
マックで濁音や半濁音が入ると文字化けします。
なんとかならんのでしょうか？
0186デフォルトの名無しさん2009/11/04(水) 10:00:49
>>185
ttp://d.hatena.ne.jp/fujisan3776/20081231/1230700127
ttp://blog.yakitara.com/2007/11/subversion-precomposed-utf-8-patch.html
0187デフォルトの名無しさん2009/11/05(木) 18:10:05
>>184
gitのリーダは日本人だぜ
0188デフォルトの名無しさん2009/11/05(木) 18:58:41
結局 git と hg と bzr はどれがいいんだよ
0189デフォルトの名無しさん2009/11/05(木) 20:25:04
gitが一番つぶしが効くと思う
githubとかあるし。
rubyかlinuxを良く使うなら一択じゃないかな
0190デフォルトの名無しさん2009/11/05(木) 20:34:08
hgが一番つぶしが効くと思う
bitbucketとかあるし。
PythonかJavaを良く使うなら一択じゃないかな

bzrが一番つぶしが効くと思う
Launchpadとかあるし。
MySQLかemacsを良く使うなら一択じゃないかな
0191デフォルトの名無しさん2009/11/05(木) 20:42:10
結局 git と hg と bzr はどれがいいんだよ
0192デフォルトの名無しさん2009/11/05(木) 20:47:15
>>189-190
言語処理系の名前が挙がってると強く見えるふしぎ
0193デフォルトの名無しさん2009/11/05(木) 21:03:42
自分が関わっているか関わりたいプロジェクトで使ってるやつを
選べばいいだろ
0194デフォルトの名無しさん2009/11/05(木) 21:06:06
bzr-svn が 1.0 になり、 bzr-git もだいぶ動くようになってきて、 bzr-hg も開発が活性化してきた。
どんなVCSを採用しているプロジェクトに参加するときでもクライアントはbzrだけで済むようになれば、
一番「つぶしがきく」のはbzrだな。
0195デフォルトの名無しさん2009/11/05(木) 21:15:24
バザールでござーる♪
0196デフォルトの名無しさん2009/11/05(木) 21:58:53
みなさん darcs はもう眼中になしですか？
0197デフォルトの名無しさん2009/11/05(木) 22:32:44
はい。
0198デフォルトの名無しさん2009/11/05(木) 22:45:55
あれコンパイルするの異様に難しいし
0199デフォルトの名無しさん2009/11/05(木) 23:00:23
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
　　　　　　　　　　　 　 　 　 　 　 　 |
　　 　 　 ＿＿＿＿.＿＿＿＿ 　　 |
　　　　　|　 　 　 　 | 　 　 　 　|　　 |　 　RationalClearCaseを
　　　　　|　 　 　 　 | ∧＿∧　|　　 | 　　窓から
　　　　　|　 　 　 　 |（　´∀｀）つ ミ | 　　投げ捨てろ
　　　　　|　 　 　 　 |/ ⊃　 ﾉ　|　　 |
　 　 　 　￣￣￣￣'￣￣￣￣　 　 | 　　 ミRationalClearCase
0200デフォルトの名無しさん2009/11/05(木) 23:01:11
>>196
何であんなとろくさいのを使わんといけんの？
0201デフォルトの名無しさん2009/11/05(木) 23:03:54
理論的に明らかにdarcsはとろくさいじゃん。
0202デフォルトの名無しさん2009/11/05(木) 23:57:13
darcsが一番つぶしが効くと思う
Patch-tagとかあるし。
haskellかhaskellを良く使うなら一択じゃないかな
0203デフォルトの名無しさん2009/11/06(金) 00:30:29
>>202
そんなことないよ。
hgとかgitとか最近は多いよ。
0204デフォルトの名無しさん2009/11/06(金) 10:37:22
IBM Rational ClearCaseが一番潰し甲斐があると思う。
ClearQuestとかあるし。
IBMかその下請けの仕事なら一択じゃないかな。
0205デフォルトの名無しさん2009/11/06(金) 13:47:50
hgがいいお。いいんだお!!!
0206デフォルトの名無しさん2009/11/06(金) 14:53:49
「Subversion」がApacheプロジェクトに
ttp://sourceforge.jp/magazine/09/11/06/0511211
0207デフォルトの名無しさん2009/11/06(金) 15:06:17
ApacheはGitだったっけ？
0208デフォルトの名無しさん2009/11/06(金) 15:09:08
svnをgitで管理するんですね
0209デフォルトの名無しさん2009/11/06(金) 15:54:04
>>207-208
SVNだよ
ttp://www.apache.org/dev/version-control.html
0210デフォルトの名無しさん2009/11/06(金) 19:18:30
ローカルでロールバック目当てに作業するならhgなんだけど、
会社で使うとなるとフォルダ移動が出来るsvnだな。

分散リポジかつフォルダ履歴管理が可能な国際化対応ツールがあればいうことなし。
0211デフォルトの名無しさん2009/11/06(金) 19:34:56
>>210
分散かつフォルダを管理してUnicodeファイル名に対応したbzrをどうぞ
0212デフォルトの名無しさん2009/11/06(金) 20:40:31
gitもあるじょ
0213デフォルトの名無しさん2009/11/06(金) 23:00:51
>>211
分散でもなく集中でもなく意味不明なbzrはパス
0214デフォルトの名無しさん2009/11/07(土) 00:43:57
いや、普通に分散だと思うが。


0215デフォルトの名無しさん2009/11/07(土) 02:09:59
>>214
リポジトリをコピーするコマンドもないのに分散と言えるのか？
0216デフォルトの名無しさん2009/11/07(土) 10:51:04
多少遅くてもいいんで、Javaポートしてくれと思ったり。
0217デフォルトの名無しさん2009/11/07(土) 10:53:46
レポジトリをコピーする必要があるのか？
0218デフォルトの名無しさん2009/11/07(土) 11:05:43
>>212
gitはフォルダを管理しないしUnicodeファイル名対応もまだだろ。
0219デフォルトの名無しさん2009/11/07(土) 11:06:46
>>216
bzrはJythonで動かした報告があった。
今の bzr-eclipse とかは、外部プロセスとしてbzrを起動してるけど、
将来はJythonのbzrで動くかもね。
0220デフォルトの名無しさん2009/11/09(月) 21:15:58
いい加減VSSとかやめて欲しいんだがうちの会社
0221デフォルトの名無しさん2009/11/09(月) 21:22:39
VSS6cだかは死滅して欲しいな。

てかソースコードはUTF-8に統一して欲しい。
プラットフォームコード使って誰が幸せになるんだ。
0222デフォルトの名無しさん2009/11/10(火) 02:20:11
UTF-8はダサイじゃん。
BOMの有無だの、それこそ「プラットフォーム特有」のエンディアンの違いを
サポートするだの、もうちょっと漢らしいスペックだったら、よかったのにね。
ちょいとばかり、女々し過ぎるスペックだよね＞UTF-8
0223デフォルトの名無しさん2009/11/10(火) 07:57:03
ぼくのかんがえたさいきょうの国際化エンコーディング形式
0224デフォルトの名無しさん2009/11/10(火) 08:03:48
TRONコードなんてなかった
0225デフォルトの名無しさん2009/11/10(火) 10:23:27
UTF-8はもともとBOMいらないでしょ。
誰かが勝手に付け加えただけ。
0226デフォルトの名無しさん2009/11/10(火) 11:16:09
BOMがないとシフトJISやEUCとの判別がつかないので、混在している今は必要悪でしょ。
たまに判別失敗して文字化けしてもいいなどという、いい加減なシステムはともかく。

FTPクライアントでBOMの有無を自動変換してくれると助かるんだが、俺が使っているのには
そういう機能がないな。
0227デフォルトの名無しさん2009/11/10(火) 11:46:33
>>226
> BOMがないとシフトJISやEUCとの判別がつかないので、混在している今は必要悪でしょ。

Shift_JIS と EUC-JP と２つの時点で同じ問題があるのに BOM のようなものが必要に
ならなかったのはなぜでしょうか？
0228デフォルトの名無しさん2009/11/10(火) 11:50:47
統計的判定や手動設定で妥協していただけで判別コードが必要なかったわけではない
0229デフォルトの名無しさん2009/11/10(火) 11:56:18
でも実際にUTF-8のテキストファイルでBOMのせいで誤動作起こすケースがあるし
邪魔なことは邪魔。もともとミスで入れちゃったんじゃないの？
バイトオーダー関係ないのにBOMなんて・・・
0230デフォルトの名無しさん2009/11/10(火) 11:57:39
美乳とか、な。
0231デフォルトの名無しさん2009/11/10(火) 11:57:43
Winのメモ帳は強制的に入れてくるな
0232デフォルトの名無しさん2009/11/10(火) 12:01:29
あるあるｗ
他の人がメモ帳で編集したjavaのソースがコンパイルで引っかかったっけな。
コンパイルの仕方もわからないのに編集してコミットすんなと。
0233デフォルトの名無しさん2009/11/10(火) 12:45:47
>>226
gccじゃビルドできなくなるがな
0234デフォルトの名無しさん2009/11/10(火) 13:07:39
UTF-8のBOMで酷い目にあったことは何度もあるが、BOMがあったおかげで救われたことはただの一度もないな。
必要悪ですらない。
0235デフォルトの名無しさん2009/11/10(火) 13:14:29
VisualStudioは一応聞いてきたと思う。
BOMいれちゃってもいいのかい？と
0236デフォルトの名無しさん2009/11/10(火) 13:18:15
ttp://pc12.2ch.net/test/read.cgi/tech/1236529563/359
359 名前：デフォルトの名無しさん[sage] 投稿日：2009/11/01(日) 18:37:16
EUCもSJISもJISも面倒見てくれるktermが、UTF-8以外は排除するxtermに駆逐されたのは納得いかない

↑わかるわかるｗ
0237デフォルトの名無しさん2009/11/10(火) 19:48:52
BOM入れたときは、幸せになると思ったんだよ・・・
CPUにUnicodeネイティブで扱う機能がついたら幸せになるかもな。

って・・・もしかしてあったりするの？
0238デフォルトの名無しさん2009/11/10(火) 22:03:21
JavaだとUTF-?の場合には8を除いてBOMを付ける。
BEだのLEだの付けるとBOMは付かない。合理的でいい。
0239デフォルトの名無しさん2009/11/11(水) 05:49:57
40代2児の父親です。
上の娘がもうすぐ思春期を迎えるのですが、
結婚するまで傷物にしたくありません。
どのように管理すればよいでしょうか？
0240デフォルトの名無しさん2009/11/11(水) 09:09:41
>>239
今すぐ結婚すればいいんじゃね?
0241デフォルトの名無しさん2009/11/11(水) 09:26:15
>>239
こういうのって当人は面白いと思ってやってるのか？
0242デフォルトの名無しさん2009/11/11(水) 12:23:51
場の空気を読めないやつって必ずいるよね
0243デフォルトの名無しさん2009/11/11(水) 18:55:03
200レス分くらいスレをリロードしてなかっただけだから許してやれ
0244デフォルトの名無しさん2009/11/11(水) 20:48:48
もっとファイルシステムに深くバインドされるべきだな。
ZFSだかはこの手のロールバックは得意らしいじゃん。
Windowsにシェル統合されるくらいならMSが統合しろよと。
0245デフォルトの名無しさん2009/11/15(日) 13:55:31
>>129 >>132
うちの大学は、工学科だが(情報科もある)8年ほど前にクライアントマシンは全台
UnixのワークステーションからPCのWindowsに変わっちゃったぜｗ

行儀悪い学生のマシンにtelnetしてCD開閉できなくなって悲しす(どっちにしろ今はtelnetなんてふさぐだろうが)

>>194
しかしなんで、bzrをほめる時は、～～になれば一番、的な口調になるんだｗ
未来のことばっかｗ
0246デフォルトの名無しさん2009/11/15(日) 13:58:49
実験室でWineつかってエロゲやってすみませんでした
0247デフォルトの名無しさん2009/11/15(日) 14:09:37
>>245
現時点ではbzrの利点はUnicode対応とshared repositoryくらいのもんだな。
0248デフォルトの名無しさん2009/11/15(日) 14:11:29
gitの運用上の質問があります。

例えば、下記のようなRailsアプリの雛形のようなリポジトリがあります。(リポジトリhogeとします)
psousa's baseapp-orange at master - GitHub
http://github.com/psousa/baseapp-orange


このリポジトリをforkして改変したい(例えば日本語リソースの追加など)(リポジトリmy_hogeとします)、
かつ、このmy_hogeリポジトリを雛形として新しいアプリを作りたいという場合(リポジトリmy_appとします)

もし、雛形を弄った変更をmy_appにも反映させたい場合は、
my_appをmy_hogeからcloneして、my_hogeを弄り、my_appでmy_hogeからpullすればOKですよね。

また、my_hogeの改変をぜひhogeに取り込んでほしいという場合には、
githubで言えば、pull requestして、pullしてもらえばいいわけですよね。


さて疑問があるのですが、my_appを作っているときに「あ、この機能は雛形にしておいたらいいな」と思った場合、
どうしたらいいものなんでしょうか？
つまり、my_appの機能の一部(もしくはあるコミット)をmy_hogeに適用したいという場合です。
単純に、my_appからmy_hogeにpushしてしまうと、全部適用されてしまうのですが、どうしたものでしょうか？
my_appでパッチを作って、my_hogeに適用、という原始的な形になるものでしょうか？
0249デフォルトの名無しさん2009/11/15(日) 20:17:32
>>247
shared repositoryのどこがメリットなんだよwww
0250デフォルトの名無しさん2009/11/15(日) 21:36:37
>>249
複数のブランチを分離しながら、共通するリビジョンをまとめて格納できるところ。

hgやgitは、複数のブランチがくっついた状態でリポジトリに格納されてしまっているから、
clone時に不要なブランチの分まで転送しないといけなかったり、
逆にある程度履歴が共通の別のブランチをcloneで持ってくるとすでに持っているリビジョンまで
転送したり格納したりしてしまって非効率。
0251デフォルトの名無しさん2009/11/15(日) 22:38:42
>>248
＞もし、雛形を弄った変更をmy_appにも反映させたい場合は、
＞my_appをmy_hogeからcloneして、my_hogeを弄り、my_appでmy_hogeからpullすればOKですよね。
my_appをどこにも公開していないのなら、rebaseのほうが良いよ。

＞単純に、my_appからmy_hogeにpushしてしまうと、全部適用されてしまうのですが、どうしたものでしょうか？
＞my_appでパッチを作って、my_hogeに適用、という原始的な形になるものでしょうか？
どちらのブランチも自分で管理しているのなら、cherry-pickが使えると思う。

相手にpullリクエストするのなら、貰って欲しいコミットだけをまとめ直したブランチを
cherry-pickとかで作って、そこから貰ってもらう。

相手にパッチ送るなら、git format-patchで作れる（gitはパッチでやり取りするのは得意）
02522482009/11/17(火) 08:21:21
>>251
ありがとうございます。

my_appは公開しています。
my_appとmy_hogeは両方とも自分で管理しています。
rebaseと、cherry-pickを見てみます。
0253デフォルトの名無しさん2009/11/17(火) 08:41:39
すみません
WindowsUpdate のような仕組みを
自作のプログラムにも入れたいのですが
どんなツールがありますか？
0254デフォルトの名無しさん2009/11/17(火) 09:11:54
スレ違い
0255デフォルトの名無しさん2009/11/17(火) 10:14:47
windowsとunix環境で使いたいのだけれど、コメントの文字コードは何にしたらいいですか？
0256デフォルトの名無しさん2009/11/17(火) 10:38:58
使ってるバージョン管理システムによる
0257デフォルトの名無しさん2009/11/17(火) 10:44:43
いやいやUTF-8の一択でしょ
0258デフォルトの名無しさん2009/11/17(火) 10:50:29
コメントをバイナリでなく文字列として扱うシステムなら、そもそも文字コードをどうするかという概念すらないわけだが
0259デフォルトの名無しさん2009/11/17(火) 11:34:19
bzr ってその場で古いバージョン取り出せないのか？
なんと不便な。
0260デフォルトの名無しさん2009/11/17(火) 11:42:00
そんなアホなことあるかよ
0261デフォルトの名無しさん2009/11/17(火) 11:46:52
>>253
バージョン管理以外にもCDNも必要だしね。
0262デフォルトの名無しさん2009/11/17(火) 11:57:49
安易にアップデート機能つけるとUACではまる場合もある
0263デフォルトの名無しさん2009/11/17(火) 15:09:29
>>260
bzrならあるかもねwww
0264デフォルトの名無しさん2009/11/17(火) 15:28:24
どうしようもないばかだな
0265デフォルトの名無しさん2009/11/17(火) 19:09:21
あふぃりえいとサイトでupdate配布して
そこにダウンロードしにいくプログラムを
大勢に配布するのが良いよ
0266デフォルトの名無しさん2009/11/17(火) 19:45:49
>>253
VCS関係のプログラム作ってると解釈してマジレスしとく。
全て自前で揃えるとなると、ミラー鯖増やしたり、クライアント毎に更新に時間差を付けたり、公開鍵暗号使った改竄チェック付けたり、チェックサム検証付けたりと何かと大変。差分アップデートにするならバイナリdiffも必要。
オープンソースならcygwinのリポジトリにでも突っ込んどきゃおk。自前で作るにしてもGPLのソースならごろごろ転がってるし、ミラーの仕組みも整ってるから適当にガンバレ。
クローズドソースなら確実にセキュリティーの更新できるようにしろ、ただ勝手に自動起動するな、方法は知らんガンバレでFA。
0267デフォルトの名無しさん2009/11/17(火) 22:52:17
なんだこいつ
0268デフォルトの名無しさん2009/11/18(水) 07:04:03
IBMのClearCase使えよ
使いづらくておすすめだよ
0269デフォルトの名無しさん2009/11/18(水) 08:15:06
執拗にClearCaseを攻撃してる奴は何をしたいんだ。
0270デフォルトの名無しさん2009/11/18(水) 15:29:32
>>266
ありがとうございました
0271デフォルトの名無しさん2009/11/18(水) 18:25:47
現在 svnが中心で、hgをちょっと試してみたいと思ってる身ですが
そこそこ hgで管理していった後に、やっぱり svnがいいなぁと思った場合は
hg → svn の移行をサポートしてくれるツールとかありますか？
svn → hg の移行はあるようなんですが...
0272デフォルトの名無しさん2009/11/18(水) 23:40:17
>>271
svnは分散特有の名無しブランチ・マージを表現できないからhgからの移行は
厳しいんじゃないの
0273デフォルトの名無しさん2009/11/19(木) 00:19:06
でも、bzrはsvkの形式でbzrのmergeをsvn上にpushできるぞ。
0274デフォルトの名無しさん2009/11/19(木) 01:52:02
>>272
>svnは分散特有の名無しブランチ・マージを表現できないから
bzrは分散ではないということでいいですか？
0275デフォルトの名無しさん2009/11/19(木) 01:57:14
えっ？
0276デフォルトの名無しさん2009/11/20(金) 00:26:12
Activestateがtracベースのバージョン管理サービスを始めましたね
0277デフォルトの名無しさん2009/11/20(金) 08:47:27
えっ？
0278デフォルトの名無しさん2009/11/20(金) 14:03:37
>>276
https://firefly.activestate.com/
これ？
0279デフォルトの名無しさん2009/11/20(金) 15:04:13
>>278
とりあえずプロジェクト作ってみたら、PublicになってPrivateにするやり方がわからない。
SCMはsubversionとMercurialが使える。
日本語使用が問題ないかどうかは試してない。
あと、truc糞重い。
0280デフォルトの名無しさん2009/11/20(金) 17:02:58
>>279
金払わないとPrivateに出来ないけど払ったの？
0281デフォルトの名無しさん2009/11/21(土) 06:38:45
>>280
もちろん払ってないよ。
とりあえずどんなものか見るためだけにプロジェクト作っただけだから。
あの重さじゃ、金払おうとは思わんね。
0282デフォルトの名無しさん2009/11/21(土) 14:00:44
社命で来年度からClearCaseを導入することになってしまったんだけど、
使い勝手はどんなもんでしょうか？
>>1のテンプレートにものってないということは
かなりマイナーなソフトなんでしょうか？
0283デフォルトの名無しさん2009/11/21(土) 14:10:49
>>282
ネタでないなら殺伐とするからやめれ
スレを検索しろ
ググレ
マジなら「ご愁傷様」の他にかける言葉がない
0284デフォルトの名無しさん2009/11/21(土) 14:11:50
人によっちゃ「御愁傷様」って言われかねないレベルのソフト
0285デフォルトの名無しさん2009/11/21(土) 14:13:01
あ、かぶったわ・・・
0286デフォルトの名無しさん2009/11/21(土) 14:13:47
リロードしたら俺が無意識に2度書き込んだのかと思ったｗ
0287デフォルトの名無しさん2009/11/21(土) 14:14:23
>>282
使ったことあるがウンコｗ
0288デフォルトの名無しさん2009/11/21(土) 14:24:31
ﾜﾗﾀ
0289デフォルトの名無しさん2009/11/21(土) 20:14:16
ワロタ
俺が書き込んだのかと思った
0290デフォルトの名無しさん2009/11/21(土) 20:20:08
ClearCase使わされてる会社って「それ以外を排除しているかどうか」みたいな監査でも入るんか？
毎回思うんだけど。
0291デフォルトの名無しさん2009/11/21(土) 21:53:13
IBMの営業から金を貰っているんじゃないだろうか
0292デフォルトの名無しさん2009/11/21(土) 21:59:32
IBMもClearCaseの出来が悪いと分かっていながら（Wikipediaにもはっきり書かれちゃってるし）
取引先に使わせるとは酷だな。
仕事貰ってるとこが営業ってことで進んで買っちゃうのかもしれないけど。
0293デフォルトの名無しさん2009/11/21(土) 22:09:50
仕事まわす代わりに自社のPCを買わせてるメーカもあるんだ。
それに比べりゃかわいいものさ。
0294デフォルトの名無しさん2009/11/21(土) 22:53:00
ＰＣは壊れたときだけ差がつくが
Clearcaseは日常的にクソ

結構差は大きいと思うが
0295デフォルトの名無しさん2009/11/21(土) 23:00:53
俺も毎回思うんだけど、ClearCase使わされてる会社って、普段はSVNなりなんなり
別のSCMを使っていて、たまに正式なコミットと称してClearCaseを使うっていうんじゃ
だめなのかね？
0296デフォルトの名無しさん2009/11/22(日) 00:23:53
自分はローカルでrcsを使うことはある
ちょっとスナップショットを取りたいと思ったときに気軽に取れるから
0297デフォルトの名無しさん2009/11/22(日) 05:37:52
>>292
バーターで無料にして無理やり(ry
0298デフォルトの名無しさん2009/11/22(日) 05:39:32
>>293
凍斯波
0299デフォルトの名無しさん2009/11/22(日) 18:42:22
>>296
mercurialとかの方がいいぞ。ディレクトリまるごと対象にできるし。/etc配下の管理なんかに使ってる。
0300デフォルトの名無しさん2009/11/22(日) 20:56:49
分散型だけど完全ローカルでパーソナルユースにしか使ってなくても充分便利だよね
0301デフォルトの名無しさん2009/11/23(月) 03:08:12
ClearCaseってIBMのRationalClearCaseのことで合ってるのかな？
それって評価版ってないの？
あればちょっと使ってみてレポートでもあげてみようかな。
どこまで屑なソフトなのかちょっと興味がある。
0302デフォルトの名無しさん2009/11/23(月) 15:54:15
>>299
ディレクトリ全体でなく、ファイル一個だけ管理したい場合もある。
設定変更に自信がないときの一時バックアップとして、とか。
0303デフォルトの名無しさん2009/11/23(月) 16:42:46
>>302
それだけならコピーしてリネームでいいんじゃね？ とおもた

いや、バージョン管理するからには履歴が必要なんだろうけどさ
0304デフォルトの名無しさん2009/11/24(火) 00:16:57
>>302
Mercurial はディレクトリは管理しない。強制的にすべてのサブディレクトリと
ファイルが管理対象になるわけじゃない。追加したファイルだけ。

前のデータサーバー(個人だけど)では/ etc の管理に CVS 使ってたけど、CVS は
ディレクトリ毎に管理ディレクトリができるから、apache の一部の設定など、ディレクトリを
再帰的に読んで、存在するすべてのファイルを設定ファイルとみなして処理しようとするような
ファイルの管理には不便だった。

Mercurial は、一番上に一つ管理ディレクトリができるだけだから便利。
0305デフォルトの名無しさん2009/11/24(火) 01:18:58
>>301
IBMはもうRational Team Concertを押してる。
RTCのバージョン管理ツールがClearCaseの可能性もあるが知らん。
0306デフォルトの名無しさん2009/11/24(火) 06:36:32
RationalClearCaseとRationalTeamConcerなんだけど

http://www.ibm.com/developerworks/wikis/pages/viewpage.action?pageId=106529021

よくわからんね
0307デフォルトの名無しさん2009/11/24(火) 07:18:52
>>306
そこ見る限りもうClearCaseは過去の遺産のように思える。
0308デフォルトの名無しさん2009/11/24(火) 14:11:21
amp
http://amp.carboni.ca/

これに期待
0309デフォルトの名無しさん2009/11/24(火) 14:23:57
わざわざPythonで実装済みのものをRuby再実装する意味が判らない。
Pythonで開発すればmercurialやbzrとの100%互換性が手に入るし、
dulwichという高品質なgitライブラリもあるし、生産性は同等で、
起動速度もメモリ消費もPythonの方が有利だろうに。
0310デフォルトの名無しさん2009/11/24(火) 15:59:54
Rubyで再実装することで、Rubyの他のプロダクトから使いやすくなるメリットが
ないわけではないかもね。

# dulwichがPythonで実装されてなかったら、bzr-gitはもっと大変だったはず。
0311デフォルトの名無しさん2009/11/24(火) 16:15:35
逆逆。dulwichはbzr-gitのために作られたの。
0312デフォルトの名無しさん2009/11/24(火) 17:26:29
なるほどそうなのか。Bazaar恐るべし。

0313デフォルトの名無しさん2009/11/24(火) 17:54:13
開発陣のやる気だけは一流なんだよ＞Bazaar
0314デフォルトの名無しさん2009/11/24(火) 18:57:48
>>313
だから将来に期待しとく。
いつになるかわかんないけど。ｗ
0315デフォルトの名無しさん2009/11/24(火) 22:26:09
>>313
でもやる気だけだからねえwww
0316デフォルトの名無しさん2009/11/24(火) 23:44:06
現在のBazaarには何が足りないの？
足りないのが人気だけなら、強力な機能を開発して人気Getは正しい戦略だと思うんだけど。
0317デフォルトの名無しさん2009/11/25(水) 06:44:48
>>316
使えば分かるけど癖が強すぎる。
0318デフォルトの名無しさん2009/11/25(水) 07:03:24
GoでGozaarを作ってみようと思う
03193162009/11/25(水) 07:25:34
>>317
使ってるけど癖が強いなんてこと全然無くて、何でこんなに人気無いのか不思議。
0320デフォルトの名無しさん2009/11/25(水) 09:06:53
>>316
たんに後発だからでしょ。
ライバルはけっこう強力だしね。

オレは、bzrが普及したら使おうと
考えてるチキン。
0321デフォルトの名無しさん2009/11/25(水) 13:25:50
>>316
>>213,>>263,>>274みたいなアホが多いから。
0322デフォルトの名無しさん2009/11/25(水) 14:17:33
GUI付きだし、Windowsユーザーには一番向いてるよな
Ubuntu開発チームが生み出しただけのことはある
0323デフォルトの名無しさん2009/11/25(水) 21:27:49
GUIは自分の環境だとダメダメだが、
SJISのダメ文字を扱えるだけで一択だわ

超頑張れ
0324デフォルトの名無しさん2009/11/26(木) 01:07:08
>>319
update で任意のリビジョンを取り出せないとか十分使いにくいと思うけどな。
それに Tourtoise がプロジェクトに含まれてる割には完成度低いし。
0325デフォルトの名無しさん2009/11/26(木) 01:53:23
>>324
update と完全に同じ挙動ってわけじゃないけど
任意のリビジョン取り出すだけなら revert -r revno じゃだめかな
0326デフォルトの名無しさん2009/11/26(木) 02:17:06
まあ取り出せるけど、変更したことになるし。
大抵 update で任意のリビジョンが取り出せるから、
ほかのツールから移ってくると違和感おおありだね。
なんで合わせないのか不思議だ。今後実装されるんだろうか。
0327デフォルトの名無しさん2009/11/26(木) 03:49:44
ググってみたら要望は以前からあるみたいだね。

https://bugs.launchpad.net/bzr/+bug/183559 とか見ると
pull --overwrite で代用できるのかな？
0328デフォルトの名無しさん2009/11/26(木) 09:30:57
そもそも何のために過去のバージョンを取り出すのかによるけど、現行との差分を見たいならdiffだし、
逆に本当にスナップショットがほしいなら"export -r リビジョン番号"が正解。
過去の時点から分岐するなら "branch -r リビジョン番号" が正解。

「up -rリビジョン番号」 というのは、目的に到達するために遠回りする過去の手法だと思ってる。
たいてい作業ツリーをまた最新版にもどすんでしょ？
0329デフォルトの名無しさん2009/11/26(木) 11:48:36
なるほどねえ。理屈ではそうかも知らんけど、たとえば
コンパイルや実行にちょっとした準備が必要だったりする場合とか、
文書だったら、たかだか前のバージョンを取り出すためにテンポラリなディレクトリ
作りたくないとか、まあ好みかもしれないけど、意味はあると思う。
0330デフォルトの名無しさん2009/11/26(木) 12:02:28
リモートリポジトリのブランチを指定してpullしようとすると
$ git pull origin foobar
fatal: Couldn't find remote ref foobar
というエラーがでて困ってます。
$ git branch -r | grep foobar
origin/foobar
というように、リモートリポジトリにfoobarブランチがあることは確認しています。
だれか助けて。
0331デフォルトの名無しさん2009/11/26(木) 12:16:45
>>330
自己レス。
git clone し直してみたら、foobarなんてブランチはすでに消されてた。
つまりgit branch -rでは表示されるけど実際には存在していなかった。ｼｮﾎﾞｰﾝ
お騒がせしました。
0332デフォルトの名無しさん2009/11/26(木) 13:34:21
>>329
作業ツリーの中で古いファイルを一時的に使いたい場合であれば、
bzr merge . -r-1..<戻りたいリビジョン>
で一旦古いバージョンに巻き戻して、必要な作業をした後、
bzr revert
で最新に戻すことで、一応できる。

もっと直接的な方法があるかどうかは不明。
0333デフォルトの名無しさん2009/11/26(木) 23:12:41
>>328
よく使うのはちょっと前のリビジョンに戻してmakeして確認してみるという時
かなぁ。cvs→svn→hgと乗り換えてきたのでupdateが自然に感じるん
だが、gitやbzrはちょっと違っていて使い方がよくわからん。
0334デフォルトの名無しさん2009/11/28(土) 09:30:29
何、bzrて任意のリビジョンとりだせないの？？？
マジで・・・

例えば、特定リビジョンで報告されたバグとか再現する時同じ環境用意するのどうすんだよ
片手落ちすぎる
0335デフォルトの名無しさん2009/11/28(土) 10:05:36
bzr update -r revnoが実装されるまではbzr revert -r revnoとかbzr pull -r revnoとか使っとけ
0336デフォルトの名無しさん2009/11/28(土) 15:05:29
exportでいいじゃん
0337デフォルトの名無しさん2009/11/28(土) 16:57:27
>>332が答え言ってるじゃん。
revert や pull したら、最新リビジョンが古いリビジョンに設定されてしまうから、
また最新に戻すのが面倒。
0338デフォルトの名無しさん2009/11/28(土) 19:31:29
どこかに各ツールのメリットデメリットの比較表とか機能別一覧表とかって
ありませんでしょうか？
0339デフォルトの名無しさん2009/11/28(土) 21:02:55
>>338
どこかで巨大な比較表を見たことがあるような気がする。
0340デフォルトの名無しさん2009/11/29(日) 00:05:35
これか？
ttp://www.atmarkit.co.jp/fjava/rensai4/devtool03/devtool03_5.html
0341デフォルトの名無しさん2009/11/29(日) 00:34:08
そのページもいいね
記憶に残ってたのはこっちのほう
ttp://en.wikipedia.org/wiki/Comparison_of_revision_control_software
きっと見る気になれないと思う
0342デフォルトの名無しさん2009/11/29(日) 00:50:30
>>341
MercurialのInternational Support (yes)とは何の冗談だろうか
Gitと同じくPartialが妥当だろう
0343デフォルトの名無しさん2009/11/29(日) 01:04:35
>>342
日本人はみんな英語が使えるし、英語はインターナショナル語だし、Yesでいいんだよ。
0344デフォルトの名無しさん2009/11/29(日) 06:37:49
>>340
>>341
トンクス
0345デフォルトの名無しさん2009/11/29(日) 12:59:37
>>337
revert は最新リビジョンを古いリビジョンにすることはないよ。
作業ツリーの内容を書き換えるだけだから。
一時的にバージョン戻してビルドしたいという程度なら特に何も困らないと思うけど
0346デフォルトの名無しさん2009/11/29(日) 18:37:35
>>345
うぉー、だとしたら>>332より直接的でいいな。
これあれば update -r イラネー。
0347デフォルトの名無しさん2009/11/30(月) 00:44:16
でも状態は変更したことになってる。
以前の状態を完全に再現できているのか、ちょっと触っちゃってるのかまぎらわしい。
0348デフォルトの名無しさん2009/11/30(月) 10:25:12
bzr pull -r使ったら-rで指定したリビジョンに戻ったけど指定したリビジョン以降のログが消えた。
どうやったらbzr pull -rを行う以前のリビジョンに戻せるんだ？リポジトリから消えたようにしか見えないが。
これじゃbzr pull -rがupdate -rの変わりになんてならないし、pullしてリポジトリの内容が消えるようなツールは使いたくない。
0349デフォルトの名無しさん2009/11/30(月) 11:07:32
>>348
この流れでなぜ merge や revert じゃなくて pull を使うっ！？
全裸になって駅前で逆立ちしてから bzr heads --all で目的のリビジョンを見つけて、
その revision-id をメモって bzr pull . -r リビジョンID しろ。
0350デフォルトの名無しさん2009/11/30(月) 17:45:14
bzrに手を出す奴ってどうしてバカばっかなの？
ろくにマニュアルも読まずに操作しといて「こんなツールは使いたくない」とか・・・

使わないのは勝手だが他人にまで愚痴んなよ
0351デフォルトの名無しさん2009/11/30(月) 17:51:32
愚痴読みたくなきゃ来るな
03523492009/11/30(月) 19:00:17
>>350
いや、 >>349 の手順はマニュアルには書いてないから。
>>327 のところで同じハマり方した人がこの手順で復活してた。
0353デフォルトの名無しさん2009/11/30(月) 21:52:31
gitも git checkout rev で戻すとrevの後のログが見えなくなるよね。
bzrも基本的には同じか。
hgは hg update -r rev で戻しても全部ログは残ってて、そこでcommitすると
ブランチができる。
0354デフォルトの名無しさん2009/11/30(月) 21:59:11
ほかのツールがデファクトスタンダード的に統一しているところを
わざわざ変えてりゃそりゃ戸惑う。

Bazaar の実装がまともになるのが先か、Mercurial でエクステンション
レベルででもファイル名問題が解決するのが先かってところだが、
Mercurial(の日本ユーザー)の方が期待できそうだな。
0355デフォルトの名無しさん2009/11/30(月) 22:00:47
ある程度のところで統一してくんねぇかな
0356デフォルトの名無しさん2009/11/30(月) 23:55:47
>>354
Mercurialでファイル名の問題をエクステンションレベルでは解決できないので
Bazaarのコミッタになった。
update -r はマージ待ちの実装はあるから、 2.1 までには trunk に取り込まれると思う。
0357デフォルトの名無しさん2009/12/01(火) 08:32:50
Bazaarは日本のコミッタが地道に頑張っているイメージｗ
0358デフォルトの名無しさん2009/12/01(火) 17:20:18
>>354
fix-utf8でファイル名の問題は解決したはず。
03593542009/12/01(火) 17:27:56
>>358
fix-utf8 をいろいろ弄って、もう本家からforkするかbzrに移るしかないと決断した。

bzr はコマンドライン引数を GetCommandLineW() を使って取得するからUnicodeの
ファイル名を引数に受け取れるけど、hg は プラグインをロードする前に引数を利用しちゃうから
プラグインから sys.argv を utf-8 に置き換えても手遅れとか、plugin から wrap できる
範囲が足りなかった。
03603592009/12/01(火) 17:29:50
俺 354 じゃなくて 356 でした。
0361デフォルトの名無しさん2009/12/01(火) 20:17:22
こればっかりはセンスの問題だからなあ．
主開発者が関心示さないとどうにもならん
0362デフォルトの名無しさん2009/12/01(火) 23:59:28
>>361
ファイル名の問題とかセンスは関係ないと思うが…
日本語ファイル名を使わないという運用による対処もあるけど、ドキュメントとか資料の類は
日本語ファイル名使いたいときあるんだよなぁ。
0363デフォルトの名無しさん2009/12/02(水) 00:20:23
gitのバグ報告にShift-JISのダメ文字問題がPOSTされてたが
「制御文字使う方が悪いよAhaha」みたいな返答されてたもんなあ
語学の定冠詞と同じで、ほぼ一生埋まらない認識のずれなのかもしれん
0364デフォルトの名無しさん2009/12/02(水) 00:53:11
TOMOYO Linuxの開発者みたいにあきらめずにがんばればきっと・・・
0365デフォルトの名無しさん2009/12/02(水) 01:10:07
既存のテストを全部パスするパッチを作るしかない、ぐらいの絶望感。
0366デフォルトの名無しさん2009/12/02(水) 06:31:13
リリースする時にテストはやってるでしょうから、その中にマルチバイトのテストも書いてコミットしてやれば
人外どももテストできる。
問題はそれを通すコードも俺たちがかかないといけないかｗ
0367デフォルトの名無しさん2009/12/02(水) 07:10:36
>>363
http://thread.gmane.org/gmane.comp.version-control.git/133963/
これ？
0368デフォルトの名無しさん2009/12/02(水) 14:39:35
TortoiseHg 0.9.1来てるけど、インストーラがInternal error吐く……。
(インストール自体は中断せず終了)

なんか怖くなったからアンインストールしてしばらく様子見よう……。
0369デフォルトの名無しさん2009/12/02(水) 20:16:19
>>368 と同じ症状になった。
Internal error: Expression error 'Runtime Error (at 1:229):
Internal error: Unknown constant "1"'

とりあえずインストールはできて使えてるようには見える。
0370デフォルトの名無しさん2009/12/02(水) 20:48:51
>>367 Git本体じゃなくてTortoiseGitだった
http://code.google.com/p/tortoisegit/issues/detail?id=194&can=1&q=japanese
03713682009/12/02(水) 20:53:33
様子見と思ったんだけど、やっぱりバグ報告しときました。
でたらめ英語通じるかなぁ。
03723692009/12/02(水) 21:18:06
乙です
03733682009/12/02(水) 23:07:24
バグ報告にレスがありました。

>>368で書いたバグは、known problemでリリースノートにも書いてあるそうです。
(今見たらたしかに書いてある(汗)

インストールは問題なく完了しているそうです。
03743682009/12/02(水) 23:14:05
と思ったけど、よく読んだら、kdiff3が動かなくなっている原因がこれかもしれないらしい。
みたいな。(英語の読解自信なし)

ワークアラウンドとして、mercurial.iniを修正すればいいようなことが書かれてます。
0375デフォルトの名無しさん2009/12/03(木) 00:15:44
TortoiseGit と EGit ってどこまで共存できるのかな。
EGit でコミットしても TortoiseGit からみるとまだ「変更あり」になってるし、
でもちゃんとコミットはできてるみたいだしで、よくわかんないことに。

加えて EGit だけではできないことあるから、TortoiseGit なり Git 本体なりを併用したいんだけど
TortoiseSVN と Subversive が大喧嘩して痛い目にあった経験があって、どうにも不安で併用に踏み切れない。

だれか併用したことのある人っている？
0376デフォルトの名無しさん2009/12/03(木) 05:49:19
TortoiseGitの日本語マルチバイト周りはどこまで進展しておりますか？
個人的にgit使う分にはコマンドラインでcygwinのUTF8仕様を使えばいいのですが、
cygwin、UTF8DLLの導入、cygwin git、TortoiseGitと用意するものが多くて他人に勧めにくいです。(cygwinは嫌がるひとも多い)

これってどこに文句言えばいいもんですかね。TortoiseGit？git？msysgit？

いぜんsourceforge当たりでTortoiseGitを「実用になってきた」みたいな飛ばし記事書いたアフォもいましたが・・・。

Mercurial(TotoiseHg)の方は根本解決ができないようなので、見限りました orz
0377デフォルトの名無しさん2009/12/03(木) 07:56:44
gitでこういう運用て可能ですか？

wikiみたいなアプリ(DB未使用アプリ)を共有レンタルサーバーにおいておいて、
ローカルでアプリテストを行いpushするとサーバー側に反映される、
pullして本番環境でのwikiのデータ編集などをローカルにマージ、といったような運用です。
どのようにすれば可能でしょうか？

デプロイとごっちゃになってますが、gitでできれば楽だなと思いまして
03783772009/12/03(木) 07:58:15
鯖側はsshのshellは開放されており、自前コンパイルはできる状態のようです。
.gitの隠蔽の問題は、httacessでできるか…。

ssh+gitでできそうな気がしてきた
0379デフォルトの名無しさん2009/12/03(木) 14:23:10
ttp://www.kernel.org/pub/software/scm/git/docs/githooks.html
ttp://at-aka.blogspot.com/2009/05/git-push.html

hook書けばいいんじゃ？
0380デフォルトの名無しさん2009/12/03(木) 18:19:24
>>377
その方法で出来ると思う。ネックは鯖側にもgitをインスコしないといけないこと
なんだけど、それはクリアできそうだね。

出来ればbareじゃないとこ（鯖とか）にpushするのは避けたほうが良いと思うけどね。
03813772009/12/03(木) 19:53:16
>>379
おお！こんな方法が試してみます！

>>380
bareじゃないとこにpushするのはマズイもんですかね？どこかドキュメントに記述などありますでしょうか？
0382デフォルトの名無しさん2009/12/03(木) 20:13:02
>>381
pushした先でチェックアウトしてるブランチが伸びてしまう場合、突然差分が発生することになる。
pushされたワーキングツリーで変更してなければresetすればいいけど、変更がある状態だったりすると、
突然コンフリクトしてしまう可能性がある。
http://git.or.cz/gitwiki/GitFaq#non-bare

なのでGit1.7からは現在チェックアウトしてるブランチにpushするのはデフォルトで拒否するようになる予定。
まあやってみれば分かると思うんだけど、自分で何をやってるか分かっててやるなら、
問題ないんだけどね。
0383デフォルトの名無しさん2009/12/12(土) 02:19:31
Gitのコミュニティーに参加して、国際化対応を推進できるような猛者は
いないのだろうか

やはり日本語ファイル名が扱えないのは不便すぐる
0384デフォルトの名無しさん2009/12/12(土) 02:32:19
>>383
仕事でsvnと連携して使ってるけど、日本語ファイル名で困ったこと一度も無いよ
0385デフォルトの名無しさん2009/12/12(土) 02:46:07
OSを跨ぐと化けるんだよ
0386デフォルトの名無しさん2009/12/12(土) 03:06:05
へ？　相手はWindowsでこっちMacとかLinuxだけど。
0387デフォルトの名無しさん2009/12/12(土) 09:13:29
>>383-386
環境を書こうぜ
0388デフォルトの名無しさん2009/12/12(土) 10:06:04
svnを使っている時点で、ファイル名のUnicodeへの正規化ができてるんだよ。
0389デフォルトの名無しさん2009/12/12(土) 10:24:39
>>387
環境って…これ以上何書けばいいの？
svnのバージョンは1.5とかだったような気はするけど。
たぶんWindowsの人はTortoise使ってそうかな。わかんないけど。
0390デフォルトの名無しさん2009/12/12(土) 10:55:32
MacのFinderで濁点付きのかなを含む日本語の名前のファイルを作ると
裸のかなと濁点に分解された形で正規化される。
LinuxやWindowsは合成した形のまま使われる。
0391デフォルトの名無しさん2009/12/12(土) 11:32:51
>>387
gitのバージョン、cygwin版か否か(UTF-8版かどうか)、svnのバージョン（は書いたか）、Tortoiseなんたら使っているならそのバージョン

ケチつけたいんじゃなくて参考にしたい。
git日本語どうもうまくいかん
0392デフォルトの名無しさん2009/12/12(土) 12:09:48
384 = 386 = 389はMac/Linuxのgit-svnで、相手がWindowsのSubversionなんだからそりゃ化けないだろ。
問題なのはWindowsのgitを使ってLinux/Macのgitとやりとりする場合。
0393デフォルトの名無しさん2009/12/12(土) 12:48:32
>>392
ああそういうことか。svnがリポジトリでクライアントがWindows以外なら大丈夫か。
0394デフォルトの名無しさん2009/12/12(土) 15:23:49
>>392
cygwin(UTF-8)のGitを使うならLinux/Maxのgitとやりとりしても大丈夫なのですか？
Git使うためだけにcygwin入れるのは抵抗あるけど。
0395デフォルトの名無しさん2009/12/12(土) 15:56:07
msysgitがSJISのダメ文字を扱える日をずっと待ってる
0396デフォルトの名無しさん2009/12/12(土) 16:15:30
もともとmsys入れてる俺にとって
msysgitを別個で入れさせられるってのが気に食わない
0397デフォルトの名無しさん2009/12/12(土) 18:58:51
Unicode API使ってUTF-8に変換してくれればだいたいOKなんだろうけどなぁ。
今のところ見込みありそうなのはUTF-8 cygwinしかないか。
0398デフォルトの名無しさん2009/12/12(土) 21:25:56
運用で回避なんていやすぎる
0399デフォルトの名無しさん2009/12/12(土) 22:17:43
いやだから日本語ファイル名使いたいならsvnかbzr使えばいいだろ。
0400デフォルトの名無しさん2009/12/12(土) 22:49:15
お前に言われんでもｒｙ

いや実際svnはともかく、bzrとgitの違いなんてあんまない
だが、「gitはLinuxカーネルのソースコード管理に使われてる」という殺し文句は
非常に説得力があるのよ（主に管理職相手に）
0401デフォルトの名無しさん2009/12/13(日) 00:20:41
というか、ソースコードのファイル名に日本語なんか使っているの？
0402デフォルトの名無しさん2009/12/13(日) 00:24:10
>>401
ソースコード以外にもバージョン管理するものはありますよ
0403デフォルトの名無しさん2009/12/13(日) 00:29:56
まあ、そうくるとおもったが、
2バイトコードのファイル名はなにかとトラブルのもとなので、使わないっていう運用してる。
0404デフォルトの名無しさん2009/12/13(日) 00:32:16
>>401
そもそもプログラマだけ使うもんじゃないし、ソース以外も管理するから、
プログラマでソースだけ管理なら日本語気にしないでいいと思う、習慣的に

問題はグラフィッカが日本語普通に使ったり、ドキュメントが日本語名つけるのが当たり前になってたりする場合。

バージョン管理なんてただでさえ(面倒くさがりに覚えさせるのは)面倒なんだから、
下手な制限があると導入が難しいんだよね・・・
0405デフォルトの名無しさん2009/12/13(日) 00:34:01
日本語ファイル名を当たり前に使う場に、日本語ファイル名が使えないんじゃなくて、使うとトラブル、なんてソフト導入不可能だよ、普通
0406デフォルトの名無しさん2009/12/13(日) 00:51:01
バージョン管理システムを覚えさせることができるぐらいなら、
2バイトコード禁止は簡単そうなんだけどなあ。
これ乗りきっても、またほかのところで問題出て来ると思うよ。
0407デフォルトの名無しさん2009/12/13(日) 00:53:33
日本語のファイル名付けるのなんて、どうせマージ不能のバイナリファイルだろ？
だったらそっちはそっちで別に管理すればいいんじゃね？ CVSなりSubversionなり。
プログラマは分散型使いたいだろうから、そっちもそっちで好きにやる。
ついでに言うとバカデカい本番用の動画コンテンツ郡とかも別リポジトリにしてくれれば
プログラマは嬉しいんだがなかなかそうならない。
0408デフォルトの名無しさん2009/12/13(日) 00:57:47
皆SVNの使い方とか会社で勉強させられたの？
0409デフォルトの名無しさん2009/12/13(日) 01:29:41
学生のときから知ってたよ
0410デフォルトの名無しさん2009/12/13(日) 02:14:46
>>408
普通入れさせる側。
0411デフォルトの名無しさん2009/12/13(日) 02:22:20
うちはそもそも使えるエンジニアしか採ってないな。

0412デフォルトの名無しさん2009/12/13(日) 02:24:32
そんなもん教えりゃすぐ使えるようになるだろ
0413デフォルトの名無しさん2009/12/13(日) 04:39:33
設計書とかのドキュメントや画像ファイルはsvnで管理して
ソースだけGitで管理
っていうのが現状だと一番いい選択肢かもしれない
仮にGitで日本語ファイル使えるようになっても、プログラマー以外のやつが
Gitを使いこなせるとおもえんし
へたするとプログラマーでもGitで挫折するやついるかもしらん
0414デフォルトの名無しさん2009/12/13(日) 09:09:36
そんなバカ実在するのか
0415デフォルトの名無しさん2009/12/13(日) 09:38:52
svnすら導入できないシステム開発会社もあるんだぜ
上場企業のシステム系子会社だけど
ソースはフォルダ名の変更（日付）で管理してるからしょっちゅうゴチャゴチャになる。
前の版で修正したのが、次の版では修正前に逆戻りとか。そりゃ客に怒られるわ
管理部門の人にsvnぐらい入れればって言ったら、難しくて理解できないだとさ
0416デフォルトの名無しさん2009/12/13(日) 09:44:05
>>413
確かにそうだなー
TortoiseSVNがこなれているし、その他はsvnでもいいのかも。
バイナリの扱いも枯れてきているせいかそんなに悪くないし、というかトラブった覚えない。

問題はちょっとスタバで仕事したいとか、出張先でドキュメント書きたいと言うときか。
svkて終わってるんだっけ？
それこそ、git-svnとかbzr-svnつかえばいいのかｗ この辺ってsvnリポジトリにアクセスできなくても使えるんだよな？
0417デフォルトの名無しさん2009/12/13(日) 13:43:16
>>400
bzrはGNUのプロジェクトだぜ
0418デフォルトの名無しさん2009/12/13(日) 13:51:16
>>417
え？
04194182009/12/13(日) 13:52:20
失礼、これか。
http://lists.gnu.org/archive/html/info-gnu/2008-05/msg00012.html
0420デフォルトの名無しさん2009/12/13(日) 13:54:04
>>417
スマン、真意がわからん
GNUプロジェクトだから、で話が済む管理職ならどんなに楽か
0421デフォルトの名無しさん2009/12/13(日) 14:14:53
emacsとかMySQLとかはあるけど、Linuxカーネルのgit, JavaやSolarisのhg にブランドで対抗するには
gcc くらいほしいな。
0422デフォルトの名無しさん2009/12/13(日) 14:16:36
>>417
ここ数年、GNUのプログラムの品質は決して高くないとおもうなあ。
20年前は、圧倒していたけど。
なんか、高尚な目標を立てても、中途半端で終わってる気がする。
0423デフォルトの名無しさん2009/12/13(日) 14:25:21
「Linuxカーネルの開発に使われてます」だと「それはすごそう」ってなって、
「GNUプロジェクトです」だと「ふーん」ってなるのか。

まあ確かにGNUプロジェクトよりLinuxカーネルのほうが活発度は上回ってるだろうけど
たぶん「ふーん」ってなる人は単に知名度でそう思うんだろうな。
0424デフォルトの名無しさん2009/12/13(日) 14:27:07
GNUのプロジェクトが何か分かってもらえないんじゃないの
0425デフォルトの名無しさん2009/12/13(日) 14:36:04
組込み世界だといまだに
GPLすら知らない部長・マネージャクラスがいぱい
0426デフォルトの名無しさん2009/12/13(日) 15:28:02
Linuxカーネルのソースを管理してるっていう実績の問題でしょ。
GNUプロジェクトだぞとか言われても話がかみ合ってない。
比較するなら、こういうプロダクトの管理に使われてるっていう例を持ってこないと。
0427デフォルトの名無しさん2009/12/13(日) 15:41:26
>>425
それは訴訟リスクが高すぎないか?
現場がわかってれば大丈夫かも知れんけど
若い人はこぴぺでレポート作っちゃう世代だからなぁ
0428デフォルトの名無しさん2009/12/13(日) 15:43:26
Gitなら、日本人がメンテしているという方向からもアピールできるな。
0429デフォルトの名無しさん2009/12/13(日) 16:27:21
>>427
でも、そういう知識があるやつほど毛嫌いされる
サーバ、ネットワークもまた然り

古い人にとって、得体の知れないものは怖いのはどこでもいっしょ

まぁ表現の仕方次第なのかも知れんが
0430デフォルトの名無しさん2009/12/13(日) 17:14:59
>>423
前者は使用された実績、後者は単なるブランドって事なんじゃね？
0431デフォルトの名無しさん2009/12/13(日) 17:21:51
ブランドでも、Linux > GNU だよね。
Linus 自身が Linux のために作ったというのは、ブランドとして最強じゃないか？
0432デフォルトの名無しさん2009/12/13(日) 17:45:10
まあストールマンの憤りの原因も、そういう状況に対してなんだろうな
0433デフォルトの名無しさん2009/12/13(日) 18:41:12
さっさとHurd 1.0をリリースしろよと
0434デフォルトの名無しさん2009/12/13(日) 19:10:17
誰得
0435デフォルトの名無しさん2009/12/13(日) 19:24:33
darcs
0436デフォルトの名無しさん2009/12/13(日) 21:32:03
>>431
あと、メンテナが日本人。
（もしかしたら、本人そういう持ち上げられ方嫌いかもしらんが）
0437デフォルトの名無しさん2009/12/13(日) 21:33:38
メンテナが日本人でも成果物の多言語対応がうんこだから何の意味もない
0438デフォルトの名無しさん2009/12/13(日) 22:11:02
x メンテナが日本人でも成果物の多言語対応がうんこだから何の意味もない
o メンテナが日本人でも成果物の多言語対応がうんこだったら何の意味もない
0439デフォルトの名無しさん2009/12/13(日) 22:17:22
うだうだ言ってるけど結局TortoiseSVN最強というのは動かないみたいだな
0440デフォルトの名無しさん2009/12/13(日) 22:32:46
お前にはTortoiseSVNがお似合いだ
0441デフォルトの名無しさん2009/12/14(月) 00:19:21
最強つうか、現時点で一番マシって感じだな
マルチバイト文字に対応してて、馬鹿にも安心して使わせられるツールじゃなきゃ
導入なんかできないだろ
0442デフォルトの名無しさん2009/12/14(月) 13:02:12
今更だけど…IBMさん何してはるんですかｗ
ttp://www.ibm.com/developerworks/jp/web/library/wa-git/index.html
0443デフォルトの名無しさん2009/12/14(月) 13:11:44
>>442
え。developerWorks は、いいサイトだと思うけど。
0444デフォルトの名無しさん2009/12/14(月) 13:47:09
>>442
関西人じゃないので
>何してはるんですか
のニュアンスが良くわからないのだが、いったい何を言いたいの？
0445デフォルトの名無しさん2009/12/14(月) 13:59:53
>444
「何をしていらっしゃるのですか？」という意味。
語尾のwを考慮すると本人は多少の皮肉を込めているつもりらしい。
0446デフォルトの名無しさん2009/12/14(月) 14:01:35
こういうあからさまなユーザー誘導は萎えるな。GIT陣営から一体いくらもらったんだ。
http://www.ibm.com/developerworks/jp/linux/library/l-git-subversion-1/index.html
0447デフォルトの名無しさん2009/12/14(月) 14:12:52
Subversion ユーザーのための Rational ClearCase
0448デフォルトの名無しさん2009/12/14(月) 14:31:17
>>446
http://www.ibm.com/developerworks/jp/
の左メニューにあげられてる製品・企業には言うこと無いの？
0449デフォルトの名無しさん2009/12/14(月) 14:44:42
developerWorksのこと知らなかった奴が、IBMが唐突にGit押ししてると勘違いしてるんだろう。
04504422009/12/14(月) 15:16:16
言い訳しに来ました。

>>444-445
ナイナイ矢部風に読んでくれると助かる。

>>442 >>449
IBMが以前からオープンソースに多大な貢献をしてきたことは知ってる。
でも「Clearcaseを押し付けてくる」ってイメージがあったから、Gitについての記事書いていたのが意外だったわけよ。
0451デフォルトの名無しさん2009/12/14(月) 15:50:16
ますます何を言いたいのかわからん
0452デフォルトの名無しさん2009/12/14(月) 16:05:24
なんでｗなのか理解不能。
0453デフォルトの名無しさん2009/12/14(月) 16:18:17
>>450
言い訳なんかしていい（ｒｙ
0454デフォルトの名無しさん2009/12/14(月) 17:24:42
なにしてはるんですかって、やってはいけないことをやったときに言うのかと思ってた。
高菜食べたときとか。
0455デフォルトの名無しさん2009/12/14(月) 17:48:12
この流れキモチワルイ
0456デフォルトの名無しさん2009/12/14(月) 18:35:30
岡村さん、なにしてはるんですかー！ｗ
みたいなツッコミは、めちゃイケとかで
よく見るじゃん。

実はあんまり通じないのか？
0457デフォルトの名無しさん2009/12/14(月) 18:50:59
まだテレビなんか見てるのか
0458デフォルトの名無しさん2009/12/14(月) 21:06:57
今度はテレビ見てない自慢厨か
0459デフォルトの名無しさん2009/12/15(火) 12:06:01
>>401
ソースファイル名にマルチバイト文字使ってるとこなんてないよなとか思いながら
手元のディレクトリ内を確認してたら、
「HogehogeServlet_ｲｯﾁｰが直すまで.java」なんてのがあったorz

>>415
ウチも去年までは、まさにそんな感じだった。
俺が独断で SVN（ソースコード） と VSS（ドキュメント類） 入れて全部面倒見るようにしたよ。

SVNは基本的にリソースをロックせず競合が発生しうる点を嫌がったり、
ブランチとマージの概念が馴染みにくいって人が多いような気がするなー。
0460デフォルトの名無しさん2009/12/15(火) 12:53:06
Visual Studio 2010リリースと同時期に、Team Foundation Serverも
追い銭無しで自由に使えるようになるみたいだぞ。MSDN会員向けの話だが。
0461デフォルトの名無しさん2009/12/15(火) 23:47:31
皆自分のプログラムは趣味でもsvnで管理してるの？
0462デフォルトの名無しさん2009/12/16(水) 00:04:58
プログラムじゃなくてもバージョン管理してるよ
0463デフォルトの名無しさん2009/12/16(水) 00:36:34
出退勤のエクセルファイルもバージョン管理してるぞ
0464デフォルトの名無しさん2009/12/16(水) 01:42:52
>>461
仕事で試して趣味で使う。常識じゃないか？JK
0465デフォルトの名無しさん2009/12/16(水) 03:02:01
やっぱsvnとか使うのは仕事し始めてからだよね
0466デフォルトの名無しさん2009/12/16(水) 08:55:07
オープンソース系のプロジェクトとかに触れてれば、学生時代からでも使う機会はあるはず
0467デフォルトの名無しさん2009/12/16(水) 10:07:52
バージョン管理しないと何も書けない
変更点の差分とか取れないと落ち着かない
0468デフォルトの名無しさん2009/12/16(水) 16:44:43
誰かが共有ディレクトリの.svnを全部消した
何が更新されてるかわからないので ~/foo/*/*/.svn を全部　/pub/foo/*/*/
にコピーしたいのだけど、何かいい方法ないのだろうか
0469デフォルトの名無しさん2009/12/16(水) 16:55:28
がんがれ！
がんがって、全部人間が確認し直すんだ。
そして、Subversion管理してるからって共有ディレクトリに
なくなっても構わない物「以外」を置いた自分を呪うがいい。
0470デフォルトの名無しさん2009/12/16(水) 17:01:09
>>468
別のディレクトリにチェックアウトして.svnがないディレクトリから上書きすれば
0471デフォルトの名無しさん2009/12/16(水) 17:12:11
exportしてdirectory単位でdiff取れば？
0472デフォルトの名無しさん2009/12/16(水) 17:39:26
>>468
% cd ~/foo/
% find . -type d -name .svn|xargs tar -cf - -T -|(cd /pub/foo/;tar xvf -)
(スクリプトの中身はちゃんと理解して使ってね)

>>469
パスワードとか入れたファイルもsvnで管理するのが常識なのですね。わかります。
0473デフォルトの名無しさん2009/12/16(水) 17:42:02
共有には入れないかな
0474デフォルトの名無しさん2009/12/17(木) 00:41:22
> % find . -type d -name .svn|xargs tar -cf - -T -|(cd /pub/foo/;tar xvf -)
> (スクリプトの中身はちゃんと理解して使ってね)

ヘタレなんで意味がわかりません
実行するとどうなりますか
0475デフォルトの名無しさん2009/12/17(木) 00:44:22
いくらバージョン管理してても、アフォがリポジトリのフォルダ壊したら
全部パーだからな

俺は毎日、リポジトリを丸ごとzipに圧縮してバックアップ撮ってる
0476デフォルトの名無しさん2009/12/17(木) 02:15:03
>>474

「find . -type d -name .svn」 --> .svnってディレクトリを検索
「xargs tar -cf - -T -|(cd /pub/foo/;tar xvf -)」　-->　上の結果をなんかアーカイブにまとめてる
詳しくは知らないがたぶんこんな感じだろう
0477デフォルトの名無しさん2009/12/17(木) 07:46:42
>>472
xargs 要らないんじゃない？

find . -type d -name .svn|tar -cf - -T -|(cd /pub/foo/;tar xvf -)
0478デフォルトの名無しさん2009/12/17(木) 10:46:07
>>476
xargs tar -cf - -T -|(cd /pub/foo/;tar xvf -) がさらに2つに分かれて
「xargs tar -cf - -T -」 --> findで発見したディレクトリ以下を圧縮
「(cd /pub/foo/;tar xvf -)」 --> /pub/fooの下に展開

>>477
実験してみた。確かにxargsなしでも動いた。
0479デフォルトの名無しさん2009/12/17(木) 12:25:39
tar に -C つければ cd も不要かと。

しかしよく考えれば、 rsync だけで事足りるような気がする...。
0480デフォルトの名無しさん2009/12/17(木) 12:28:15
rsync は 　. から始まるファイルをなぜか無視する
しかし _darcs はコピーする
なんで .dacrs じゃなくて _darcs　なんだろ
0481デフォルトの名無しさん2009/12/17(木) 12:59:07
そもそも >>468 が作業コピーを共有しているなどという
運用方法には誰も突っ込まないのか。
0482デフォルトの名無しさん2009/12/17(木) 13:31:16
>>481
テスト環境とかで複数用意するのが困難なのもあるので
(いまだど仮想マシンを使えるかもしれないけど)
共有することもあるかな。あとテストを複数人(チーム）で実施するときとか。
パケットをモニタしながら複数の機器を操作してとか
目玉の数と手の数が重要なテストもあるので。
0483デフォルトの名無しさん2009/12/17(木) 15:08:27
>>482
そういうとき、うちでは linux で作業コピーを作り、
smb.conf で veto files = /.??*/ してる。
0484デフォルトの名無しさん2009/12/17(木) 19:54:47
>>480
rsyncにコピーしてもらいたかったからだったりしてｗ
0485デフォルトの名無しさん2009/12/17(木) 23:02:49
>>475
gitがMercurialを使えば？
自称分散型なbazaarは駄目だぞw
0486デフォルトの名無しさん2009/12/17(木) 23:15:47
俺も Bazaar にはちょっと期待してたんだが、
未実装なのか考え方がズレてんのか、
とにかくこれは無いなと思った。
0487デフォルトの名無しさん2009/12/17(木) 23:52:27
>>485
どの辺が自称なの？

>>486
仕事で他の人間と一緒に使うなら現状 subversion以外ありえんな。
0488デフォルトの名無しさん2009/12/18(金) 01:05:39
うちの会社いまだにVSS使ってるんだが
その理由がロック方式のほうが安心だから。っていうしょうもない理由

みんな仕事でSubversionとか使ってるの？
コンフリクトの解消とか、バイナリファイルの扱いとかが
ややこしくなるのでPLがイヤがるんだが実際どうなの？
0489デフォルトの名無しさん2009/12/18(金) 01:22:27
コンフリクトが発生する原因は、単純にプロジェクトの運営がまずいだけ。
要するにPLがクソ。

バイナリファイルの扱いがややこしくなるのは、単純にプロジェクトの運営がまずいだけ。
要するにPLがクソ。

結論、そんなPLは、どんなバージョン管理システムを使っていようがプロジェクトの
邪魔になるだけなので、クビにすべき。
0490デフォルトの名無しさん2009/12/18(金) 02:37:11
真理すぎてワラタｗ
0491デフォルトの名無しさん2009/12/18(金) 03:41:17
OSSみたいに誰がコミットするかわからないとかならまだしも
会社のプロジェクトでコンフリクトが発生するってどんだけー
0492デフォルトの名無しさん2009/12/18(金) 08:01:57
⊂⌒⊃｡Д｡)⊃カジ速≡≡≡⊂⌒つﾟДﾟ)つFull Auto | セブンアンドワイ、今度はソースコードを流出させる。
http://www.kajisoku.net/1/archives/eid284.html


.svnディレクトリ大公開祭り
お前らも気をつけろよ！！
0493デフォルトの名無しさん2009/12/18(金) 08:04:12
Bazaarローカルブランチないのに絶望した！
日本語ファイル名考慮すると頼みの綱はお前だけなのに
0494デフォルトの名無しさん2009/12/18(金) 08:16:44
>>488
ロック機能も一応あるんで、
必要なら使えば。
04954592009/12/18(金) 09:32:07
>>489
>>491
うーん、ウチの会社で SVN 使ってるけど、競合起きたことあるよ……orz

こっちが業務ロジックの追加を行う案件（事前に計画済み）を実施してる途中で、
DBコネクションのリークが原因の本番系ダウンが起きて緊急にコード修正したんだけど、
計画案件ブランチのコードを trunk へマージする際に、先にコミットされた障害対応コードと
競合しちゃったんだよなー。

本来なら、いったん障害対応コードを計画案件ブランチ側へ取り込んで（マージして）から
trunk へ持って行くべきなんだろうけど……


あと、どーでもいーけど、>>492の先に置いてある魚拓見たら svn:needs-lock が入ってるね……
0496デフォルトの名無しさん2009/12/18(金) 10:44:10
それは知らなかった
0497デフォルトの名無しさん2009/12/18(金) 11:23:05
>>485
またアホが湧いてきたか
0498デフォルトの名無しさん2009/12/18(金) 11:26:04
>>493
ローカルブランチあったら便利だけど、無くても困らないよ。
んでもって、今開発進んでるから、半年後までに公式プラグイン登場、1年後には標準搭載
されてるんじゃないかな。
0499デフォルトの名無しさん2009/12/18(金) 12:26:46
>>480
>rsync は 　. から始まるファイルをなぜか無視する
>しかし _darcs はコピーする
>なんで .dacrs じゃなくて _darcs　なんだろ
FAQ Why doesn't darcs use a hidden directory like .darcs for metadata, rather than the visible _darcs?
http://wiki.darcs.net/FrequentlyAskedQuestions#why-doesnt-darcs-use-a-hidden-directory-like-darcs-for-metadata-rather-than-the-visible-darcs
Issue 129 _darcs/ to .darcsrepo
http://bugs.darcs.net/issue129
0500デフォルトの名無しさん2009/12/18(金) 12:41:09
質問なんですが、こういう時どういう運用すればいいもんでしょうか？

Subversionで特定の新機能をブランチ切ってで開発し一段落したら、
開発し終わったらtrunkに切り替えて、ブランチを指定して(もしくはブランチのリビジョン範囲指定して)マージしてます。

問題は分担作業してて、相方のブランチ作業が長い時に
こちらがtrunkで作業したりマージしたりした成果物を相方のブランチの方へも適用したいときは
どうしたもんでしょうか？
(相方のブランチの方を最新版へ追従したい)

gitとかだとmasterのリポジトリからpullったら自動でmasterでの変更の差分が
branchへ(というか手元のリポジトリの作業しているソースへ)うまいこと適用されますよね？たしか

分散とも双方とも理解が曖昧なので、間違いやこうしたらいいよというのを指摘ください。

>>498
マジカ！サンクスbzrにも期待
0501デフォルトの名無しさん2009/12/18(金) 13:17:34
よくわかんないな。
相方の branch 側が trunk を適当なタイミングで merge するのじゃダメなのかしら?
変更点が入り組んでたりすると、面倒といえば面倒だけどね。
0502デフォルトの名無しさん2009/12/19(土) 00:49:59
大規模なプロジェクトなんで、ファイル数が30万くらいでトータルサイズが500Gくらいあるんだけど、gitだとサクサク管理できますか？
0503デフォルトの名無しさん2009/12/19(土) 02:09:33
>487
git-svn で自分は git 使うってのもありだと思う。

>500
Subversion なら >501 の通り merge するしかないんじゃね？
git なら rebase するところのような気がする。
  d-e
 /
a-b-c
を
        d'-e'
       /
a-b-c
にするのが rebase
0504デフォルトの名無しさん2009/12/19(土) 02:33:14
>>500
svnだとやっぱり>>501が言うように相方がこまめにtrunkをbranchへマージするしかないと思う。
何にせよtrunk追従は相方側の責任になるので自分（trunk保守側）がやれることはあんまりないかと。
新規開発みたいなbranchの作業が絶対にコンフリクト起きないようなものなら、
branchが落ち着いたあと一気にtrunkへmergeするってのも手といえば手かもしれない。

>>503
まさにgit rebaseの面目躍如ってシチュエーションだな。
0505デフォルトの名無しさん2009/12/19(土) 03:33:37
新機能を開発するbranchにtrunk(master)の変更をmergeするのって
Gitなんかだと御法度なんだけどな
新機能を追加するbranchには新機能以外のノイズを入れないのが正しいと思うが。

Subversionではtrunkの変更を新機能branchへマージして
その後、新機能branchをtrunkへマージするとどうなるの？
trunkの変更分が2重に適用されたりする？
0506デフォルトの名無しさん2009/12/19(土) 03:39:06
試したことないから知らんが、500GBもあるとハッシュ値とってリポジトリと
比較するだけでも膨大な処理が必要になるし使い物にならないんじゃね？

まずはバージョン管理する必要のあるファイルとないファイルに分離するといいと思う。
まさかソースコードが500GBあるわけないし
0507デフォルトの名無しさん2009/12/19(土) 09:03:27
>>505
そんなルール聞いたことないが。
Junioが言ったのか？
0508デフォルトの名無しさん2009/12/19(土) 09:18:11
>505
>新機能を開発するbranchにtrunk(master)の変更をmergeするのって
>Gitなんかだと御法度なんだけどな
Git だと branch や merge の手間が小さいし、分散だとなるだけ独立した形で新機能を
作っとくと色々なところで merge も管理もしやすくなって意義があるんだろう。

Subversion とかだと常に feature branch を切るって運用はあまりされなくて、
複数の branch で並行して開発が進められて、時たまクロスで merge されるという運用は
結構ある気がする。Git 本でも Subvesrion を使ってた人は御法度をよくやるが、みたいな
書き方だったような。

Subvesion book の例だと
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync
branch に trunk から複数回 merge して最後に trunk に merge し直してる。
trunk に merge し直す際に --reintegrate オプションを付けると >505 の二重適用を避けようとするみたい。
ただし、--reintegrate 使うとその先 branch が使えないらしいので再度 branch を作れということみたい。
--reintegrate なんてオプション知らなかったよ。
0509デフォルトの名無しさん2009/12/19(土) 16:10:44
>>500
ブランチの再統合の事かな。？
>>508と同じ操作だと思うけどtortoiseSVNの場合、その長いブランチにはtrunkから何度でも「リビジョンの範囲をマージ」でマージができるのでtrunkに追従できる。
そして、trunkからマージしてしまったブランチをtrunkにマージしたいときは「ブランチの再統合」でtrunkに１回だけマージできる。
そのブランチの変更はすべてとtrunkに含まれるのでブランチは削除できる。というか、２度とマージができないブランチになるのですぐに消そう。

練習してから試してみよう。
0510デフォルトの名無しさん2009/12/20(日) 06:15:59
>>507
ほかの方が回答してくれていますがJunio本に、そんなことが書かれてた。

個人的には、きっちり理想的な使い方を常にできるかというと
難しい気もするが。

> trunk に merge し直す際に --reintegrate オプションを付けると >505 の二重適用を避けようとするみたい。
> ただし、--reintegrate 使うとその先 branch が使えないらしいので再度 branch を作れということみたい。
> --reintegrate なんてオプション知らなかったよ。

Subversionのmergeは制約が多くて面倒ですね・・
まあ、mergeが終わった時点でそのbranchが不要になる使い方なら
全然問題なさそうですけど。
05115002009/12/20(日) 09:27:03
>>501-510
うおお、皆さんありがとうございます！
参考になりました。聞いてみるものですね。

ぜひ試してみます。
Subversion bookのも読んでみます。
--reintegrate てTortoiseSVNでもできるかな・・・。て調べたら確かにブランチの再統合ていうやつなんですね。
05125002009/12/20(日) 09:29:41
あれもしかして、Merge trackingが必要？ということは1.5のリポジトリじゃないと駄目？
svn mergeinfo
http://www.asahi-net.or.jp/~iu9m-tcym/svndoc/svn_mergeinfo.html


リポジトリ1.4のままなので変換しないといけないな…
0513デフォルトの名無しさん2009/12/20(日) 12:21:18
>>512
本家の表の「Merge tracking」を見る限り、そうみたいだね。
ttp://subversion.tigris.org/svn_1.5_releasenotes.html#compatibility
0514デフォルトの名無しさん2009/12/20(日) 13:38:52
>>512
マージをよく使うなら1.5のほうがいいと思うよ。merge trackingだけならリポジトリのアップグレードはsvnadminで一瞬で終わる。
0515デフォルトの名無しさん2009/12/20(日) 13:39:54
いまからアップグレードするなら 1.6 だろ。
0516デフォルトの名無しさん2009/12/20(日) 13:40:28
そだねw
0517デフォルトの名無しさん2009/12/20(日) 13:53:32
bzr-svnが1.6だと使えない罠
0518デフォルトの名無しさん2009/12/20(日) 20:31:24
>>512
svnmerge.pyを使え
0519デフォルトの名無しさん2009/12/21(月) 11:03:03
Subversion の 1.6.5 はマージが微妙に怪しいような気がする。
1.6.6 は試してない。

git だと、オレブランチを持って、基本的にそこで開発。
みたいなのは御法度なのかしら?
0520デフォルトの名無しさん2009/12/21(月) 21:52:02
>>519
gitだとそれが基本というかそれしか出来ない。
Subversionのマージトラッキングは調子どうなんだろう？
それ以前のマージは貧弱すぎてかなり疲労したが。。。
0521デフォルトの名無しさん2009/12/23(水) 09:02:28
>>520
調子いいよ
0522デフォルトの名無しさん2009/12/23(水) 12:13:17
>>520
Subversionのマージトラッキングは自動でマージするリビジョンを判断してくれるからかなり快適。
0523デフォルトの名無しさん2009/12/23(水) 13:25:22
Subversionの1.4から1.5にリポジトリにアップグレードしたいのですが、
svnadmin upgrade でも問題ないでしょうか？
どれもリビジョンは200くらいの小さなプロジェクトばかりです。
0524デフォルトの名無しさん2009/12/23(水) 13:41:08
>>523
アップグレードの目的による。
ほんとうにバージョンを上げたいだけなら svnadmin upgrade が早くていいかもしれない。
0525デフォルトの名無しさん2009/12/23(水) 13:47:45
>>523
upgradeだとリビジョンを1000ごとにフォルダーにまとめる変換がされない。
マージトラッキングが欲しいだけで気にしないならupgradeでOK。
0526デフォルトの名無しさん2009/12/23(水) 19:15:43
質問。git add でバイナリファイルを追加するときって、何かオプションいる？
0527デフォルトの名無しさん2009/12/23(水) 19:26:39
それタイプして質問する間にググれ馬鹿
05285232009/12/23(水) 21:47:39
サンクソ
新機能使いたいだけなのでupgradeでいってみます。

ふと聞くのですが、後から1000ごとにフォルダーわけして欲しかったら、
変換後にあとでdump/loadしても間に合う(というか分けてくれる)もんでしょうか？
0529デフォルトの名無しさん2009/12/23(水) 22:45:37
>>527
ググってもよくわかんなかったんだよね。いるならいるって書くだろうけど、いらなきゃ書かないかもと思ってオプションなしで試してみたら、うまくいったみたい。
0530デフォルトの名無しさん2009/12/24(木) 01:21:12
>>528
後からできるよ
05315232009/12/24(木) 10:46:36
>>530
ありがとう。これでこころおきなくupgradeできる。
0532デフォルトの名無しさん2009/12/24(木) 20:09:18
皆さん仕事で使ってる人なんですか？
個人で使うぶんには、バックアップ代りみたいなもんですよね。
0533デフォルトの名無しさん2009/12/24(木) 20:36:22
>>532
改良したつもりがおかしくなった、みたいなときに原因を探るとか。
0534デフォルトの名無しさん2009/12/24(木) 21:01:25
最初の「ひとまず完成バージョン」を作るまではたしかにバックアップみたいな
感じだけど、そこから使いながら機能追加やらコードのクリーンアップとかする
場合には手放せないな。

自分だけかもしれないけど、自分しか使わないコードだとクリーンアップとか
言いながら安易に変更してよく壊すしｗｗｗ
0535デフォルトの名無しさん2009/12/25(金) 00:31:01
>>532
プログラムを改造したりするときに、いつでも昔のバージョンに戻せるのは心強いぞ。
0536デフォルトの名無しさん2009/12/25(金) 02:04:33
コミットを小さな作業単位として考えると、ダラダラと変更を続けてしまって
「さっきは動いてたのに・・・」みたいな状況に陥らなくなったよ。
仕事でも趣味でも重宝してる。
0537デフォルトの名無しさん2009/12/25(金) 08:39:10
gitはインデックスがあるからさらに良いぞ。

たぶん人によっていろんな使い方が出来ると思うけど、
例えば、ソース編集→コンパイル→動かす→修正→コミットって感じなら、
まずコンパイルが通った時点で全部インデックスに突っ込んでおく。
そうするとその後、コンパイル通過後にやった差分、前回コミットから今の差分、
両方個別に確認しながら作業ができる。
コンパイル成功後にいじりすぎてぶっ壊し状態になってしまい、
「俺はいったいなにをやってこうなってしまったんだ、ついさっきまでは
いい感じでいけそうだったのに。。。」ってなった時に助かる。

あとけっこう沢山のファイルを触らないといけない場合、コミットの時にまとめて
分散した差分を確認するのは骨が折れるので、ちょっとずつ差分を追い出してく
感覚で使えるのもいい感じだ。
0538デフォルトの名無しさん2009/12/25(金) 13:58:55
俺は年賀状ソフトの宛名データすらバージョン管理してる。
0539デフォルトの名無しさん2009/12/25(金) 14:16:01
データベース使ってないの？
05405382009/12/25(金) 14:31:09
>>539
具体的には「筆まめ」を使っているけれど、
宛名データのファイル（*.fwa）をそのままバージョン管理に突っ込んでる。
いつでも過去に戻れる安心感から、宛名を心置きなく修正したり削除したりできるようになった。
0541デフォルトの名無しさん2009/12/25(金) 15:00:36
*fwaが何者なのかわからないけど、斬新すぎて衝撃を受けた
0542デフォルトの名無しさん2009/12/25(金) 15:59:39
>>541
何が斬新なんだ？
管理するファイル形式に縛りはないんだから、別に何を監理してもいいんだぜ？
0543デフォルトの名無しさん2009/12/25(金) 18:04:51
Accessの .mdb ファイルをそのまま VSS へ突っ込むような感じか。
05445412009/12/25(金) 18:18:19
>>543
そうそう。まさにそれ。
0545デフォルトの名無しさん2009/12/25(金) 20:41:56
まぁ普通にバイナリファイルだろうとなんだろうとHgで使ってるけどね。
ただ、マージとか発生するとおかしな状況が生み出されて困る
0546デフォルトの名無しさん2009/12/25(金) 21:34:56
たまに設定ふっとぶとか、設定いじったら動かなくなったことがあるフリーソフトはexeとか関係なくバージョン管理に突っ込んでるｗ
0547デフォルトの名無しさん2009/12/25(金) 21:51:13
>>532
github使ってるよ。
他人のオープンソースなライブラリとか、バグ直して本家に反映してもらったりとかが
gitの仕組みとwebサービスのサポートがあって簡単にできる。
もうバージョン管理はそれ単体(ソフトだけでってこと)で語れないと思う。
0548デフォルトの名無しさん2009/12/25(金) 21:52:44
> もうバージョン管理はそれ単体(ソフトだけでってこと)で語れないと思う
ちょっと嫌味な言い方で書いてしまったんだけど、
ようするにバージョン管理＝ソフトだけってことはないよってことです。
githubみたいにオープンソースのインフラになりうるサポートするwebサービスもあるのでってことです。
0549デフォルトの名無しさん2009/12/29(火) 23:07:27
いまさら感あふれるニュースだが

GNU Emacs、CVSからBazaarに「スイッチ」 - スラッシュドット・ジャパン
http://slashdot.jp/developers/article.pl?sid=09/12/29/0621224
0550デフォルトの名無しさん2010/01/08(金) 02:07:13
一方 Vim は Mercurial へ
0551デフォルトの名無しさん2010/01/08(金) 17:54:38
このスレの総意はMercurialってことでよろしく。
0552デフォルトの名無しさん2010/01/08(金) 18:15:38
やかましい
0553デフォルトの名無しさん2010/01/09(土) 16:05:21
>>551
誰が総意をまとめろと言った。
このスレのいいところは様々なSCMについて横断的な情報が集まるところだぞ。
0554デフォルトの名無しさん2010/01/09(土) 19:19:57
ところで Software Configuration Management System なのに
SCMS じゃなくて SCM なのはなぜなん？
0555デフォルトの名無しさん2010/01/09(土) 19:36:08
DOSの拡張子が3文字だから
0556デフォルトの名無しさん2010/01/09(土) 19:40:32
>>554
お前にとって最後のSystemはそんなに重要なのか？
0557デフォルトの名無しさん2010/01/09(土) 19:56:39
>>555
納得した！
考えてみれば当然の事やんな。
0558デフォルトの名無しさん2010/01/09(土) 20:13:10
VSS以外で、VSSで言うところの「ファイル共有」機能が実装されているバージョン管理システムはありますか？
0559デフォルトの名無しさん2010/01/09(土) 23:52:48
>>558 昔は俺もVSS使いでした。
Subversion/TortoiseSVNではexternalsが良く似た機能になる。VSSは完全に共有になるが、externalsは参照になる。
違いは、VSSは単純に共有になるので参照元のような概念が無くて平等なので、変更箇所が他の共有先に意図せず反映されてはまることがある。
externalsはtagバージョンで参照させれば、参照元のバージョンを管理できたり、参照しているライブラリを間違えてコミット使用としたときに警告を出させたりできる。
0560デフォルトの名無しさん2010/01/10(日) 01:05:30
>>559
なるほど、似たようなのがあるんだね。

5年ほど前にCVS使った時はvファイルのシンボリックリンク張って
無理矢理対応したりしてたけど。
やっぱ不満が出てたんだね。時代は廻るものですな。
0561デフォルトの名無しさん2010/01/14(木) 21:23:04
>>532
やね氏はsvnとか使わずにwinrarで圧縮してftpでどっかにうｐするだけらしい。
エロいPGでも個人じゃ不可欠ってわけでもないのか。

自分は二か所にチェックアウトして日常の細かい修正用と冒険用に分けるのが便利で一応使ってるけど。
trunk, tags, branchなんて面倒だからやってない。
仮にtagsにバージョン切ってもライブラリ側との整合性が取れないから
雑な運用じゃ古いバージョンのビルドなんてほとんど不可能だな…
0562デフォルトの名無しさん2010/01/14(木) 21:59:47
svnはtagとbranchがふざけてんの？って言いたくなる形式だから、
既存のプロジェクトがsvn使ってるから以外の理由で使う気にならない
0563デフォルトの名無しさん2010/01/14(木) 22:23:16
別にsvnでも全然困ってないぜ
0564デフォルトの名無しさん2010/01/14(木) 22:27:16
チェックアウトして修正したまま1週間以上放置してあるファイルがあったら
幼女が怒ってくれる転覆MODが欲しい今日この頃
0565デフォルトの名無しさん2010/01/14(木) 22:56:05
subversionは .svn フォルダがあちこちに出来るから嫌い
0566デフォルトの名無しさん2010/01/14(木) 23:02:27
>>561
VCSは個人がバラバラに持ってた管理ノウハウをシステム化したって色が濃いツール。
そもそも昔はVCSなしでなんでも管理してたわけだし、経験のある人ほど冗長性だとか
スナップショットだとか、VCSが確保してくれるものを自分のやり方でやれていて
必要性が感じられないんだと思う。
0567デフォルトの名無しさん2010/01/15(金) 21:07:27
そういうこと言うと、スーパーハカー気取りの素人が
「バージョン管理なんて素人のやることさ！」とか思い込むからやめてくれ。
ノウハウがソフトウェアとして定型化・自動化されたことのメリットはやはり大きいわけだし。
0568デフォルトの名無しさん2010/01/15(金) 21:33:22
個人的に使うなら何でもいいけど
共同作業するためにはシステム化する必要があると思う
0569デフォルトの名無しさん2010/01/16(土) 09:03:07
>>567
ハカー気取りなら、Linusが1週間プロトタイプ作ったうんぬんsvnはクソだ！とか言い出してgit使うだろJK
0570デフォルトの名無しさん2010/01/17(日) 21:15:23
Linusを信奉しちゃうあたりがハカー「気取り」にすぎないって話ですね
0571デフォルトの名無しさん2010/01/17(日) 21:30:16
そうだねー、真のハカーはBSDだよねー
0572デフォルトの名無しさん2010/01/17(日) 21:31:52
夏真っ盛り
0573デフォルトの名無しさん2010/01/17(日) 22:18:22
南半球在住ですか。
0574デフォルトの名無しさん2010/01/17(日) 23:10:58
まあ、linuxのコードでlinusの書いた部分を少しでも読んでりゃ、あれっと思うわな
0575デフォルトの名無しさん2010/01/18(月) 02:19:58
どう思うの？
あまり良くない設計だったり？
0576デフォルトの名無しさん2010/01/18(月) 15:44:22
linuxはどうかしらんが、GitのCUIはクソ
0577デフォルトの名無しさん2010/01/18(月) 15:48:02
で、クソじゃないのはTortoiseSVN
0578デフォルトの名無しさん2010/01/18(月) 16:19:55
なんでもGUIにしてもらわないと使えないとは...
0579デフォルトの名無しさん2010/01/18(月) 18:08:55
>>578
＞使えない
と、誰が言ったのか？
0580デフォルトの名無しさん2010/01/18(月) 20:20:58
GitのCUIはLinusじゃないんだが。。。
0581デフォルトの名無しさん2010/01/18(月) 20:29:36
linusのオリジナルだとハッシュ値を直接登録とかだからもっとひどい
0582デフォルトの名無しさん2010/01/18(月) 20:37:32
このスレの総意はMercurialってことでよろしく。
0583デフォルトの名無しさん2010/01/19(火) 00:04:29
gitはnativeな操作だけ用意して、インターフェイスはそれらを組み合わせて作られてきたもの。
だから直接登録でも問題ない。
0584デフォルトの名無しさん2010/01/19(火) 01:32:32
Linusは自分のことが分かってて、ユーザインタフェースは俺にはムリだからって他の人に頼んだ。
Gitの内部設計は斬新でカッコイイよ。
0585デフォルトの名無しさん2010/01/19(火) 04:20:36
かっこいいが斬新ではないだろう
0586デフォルトの名無しさん2010/01/19(火) 04:41:48
斬新さなどあって無かろうなのだァーッ！
0587デフォルトの名無しさん2010/01/19(火) 05:55:23
>>585
差分取らずにコミットまるごと保存でファイルシステムみたいなリンク構造って
斬新だなーと思ったんだけど、そんなことないのか。
0588デフォルトの名無しさん2010/01/19(火) 13:58:10
>>582
ハゲドウ!!
0589デフォルトの名無しさん2010/01/19(火) 17:43:36
>>587
じゃあ、ファイルシステムをそのまま使えばいいじゃん。
リンクに循環がないわけだし。
圧縮ファイルシステムもあることだし。
0590デフォルトの名無しさん2010/01/19(火) 18:39:41
>>587
つ　CVS -k

だっけか。バイナリのやつ。
最近は使わないから忘れた。
0591デフォルトの名無しさん2010/01/20(水) 00:11:20
>>587
それって履歴の一覧を見るのが大変じゃないの？てか、どんな金持ち
0592デフォルトの名無しさん2010/01/20(水) 18:50:26
>>587
GIT
0593デフォルトの名無しさん2010/01/20(水) 19:44:00
>>592
いや、>>585あたりのがまさにGITの話だから。
0594デフォルトの名無しさん2010/01/20(水) 20:56:57
pdumpfs だって同じだし、構想的には目新しい物ではないな。
0595デフォルトの名無しさん2010/01/21(木) 10:38:38
>>549
GNU って言ったら arch ってのがあったような気がするんだが、
どうなったのだろう...
0596デフォルトの名無しさん2010/01/21(木) 10:48:36
Linusはファイルシステムを書き始めたけど
使い物になりそうにないのでバージョン管理システムにしたてた、ってのが真相。
もし完成してたらbtrfsみたいなのが出来上がっていたかもね。
0597デフォルトの名無しさん2010/01/21(木) 14:33:55
>>596
>Linusはファイルシステムを書き始めたけど
>使い物になりそうにないのでバージョン管理システムにしたてた、ってのが真相。

ソースきぼん
0598デフォルトの名無しさん2010/01/21(木) 17:36:07
windowsのCドライブをUSB HDDにドラックドロップで単純にコピーしたものが
４つぐらいあります。どれも微妙に食い違っててて単純に日付の新しいものに
上書きしただけじゃ、全部最新にはなりません。

多分、目視で１つ１つ違うファイルを確認することになると思うのですが
大部分は同じファイルです

全部のファイルを見るのは嫌なのですが、何かいいツールはないのでしょうか
0599デフォルトの名無しさん2010/01/21(木) 19:54:34
>>598
すれ違い
0600デフォルトの名無しさん2010/01/22(金) 14:56:04
git で、あるコミットだけをパッチの形で取り出すにはどうしたらいいでしょうか。
git format-patchだと、一連のパッチができてしまいます。
そうじゃなくて、指定したコミットだけを取り出すことがしたいです。
0601デフォルトの名無しさん2010/01/22(金) 15:10:44
>>600
git show コミット > hoge.patch
0602デフォルトの名無しさん2010/01/23(土) 11:23:51
>>600
git diff commit^..commit
0603デフォルトの名無しさん2010/01/23(土) 16:22:34
>>598
ファイルごとにMD5でハッシュ値を計算し、比較してみたらいいんじゃないかな。
Rubyだったらこんなかんじのコードで。

## ファイル名: C:¥hoge.rb
require 'digest/md5'
filenames = Dir.glob("**/*") ## ファイル名をすべて列挙
for filename in filenames ## それぞれのファィル名について
　if File.file?(filename) ## それがファイルのときだけ
　　s = File.open(finename, 'rb') {|f| f.read() } ## 中身を読み込んで
　　digest = Digest::MD5.hexdigest(s) ## MD5でハッシュ値を計算し
　　puts("#{filename}¥t#{digest}") ## ファイル名と共に出力する
　end
end

## コマンドプロンプトで
C:¥> cd dir1
C:¥dir1> ruby C:¥hoge.rb > ..¥list1.txt
C:¥dir1> cd ..¥dir2
C:¥dir2> ruby C:¥hoge.rb > ..¥list2.txt
C:¥dir2> cd ..
C:¥> diff list1.txt list2.txt

いや、diffコマンドが使えるなら、diff -r dir1 dir2 でいいのか。
0604デフォルトの名無しさん2010/01/24(日) 07:22:53
gitで複数行のログを一覧表示する方法ってないの？
git log --pretty=format:"%s" ^^HEAD...HEAD
みたいのだと１行目しか表示されません・・・
0605デフォルトの名無しさん2010/01/24(日) 08:41:31
>>604
よくわかんないけどこういうこと？
git log --oneline
0606デフォルトの名無しさん2010/01/24(日) 08:57:59
>>605
fatal: unrecognized argument: --oneline
とか言われる。
0607デフォルトの名無しさん2010/01/24(日) 09:07:03
>>606
うちだとこんな感じになる。
$ git version
git version 1.6.5.6
$ git log --oneline
27b34ed IEマター
133ffa8 起動オプションのGUI
29ccecd bodyのスタイル
62a778b 見た目調整
(略
0608デフォルトの名無しさん2010/01/24(日) 16:20:00
>>607
git古いせいかもバージョンアップしてくるわ
0609デフォルトの名無しさん2010/01/25(月) 00:06:45
うちのgit 1.5.4.3だとgit log --pretty=onelineだな。
0610デフォルトの名無しさん2010/01/26(火) 00:43:52
はい、Mercurialきましたー

米MicrosoftのCodePlex、分散型バージョン管理システム「Mercurial」のサポートを発表
2010年01月25日 11:37AM

　米Microsoftは1月23日、オープンソースのプロジェクトホスティングサービスCodePlexで
分散バージョン管理システム（DVCS）「Mercurial」をサポートすることを発表した。既存
プロジェクトもMercurialに移行できる。

ttp://sourceforge.jp/magazine/10/01/25/0241213
0611デフォルトの名無しさん2010/01/26(火) 22:43:50
TortoiseGit 1.3.2.0出た。日本語言語ファイルもSF.jpに上がってる。
1.2.1.0からアップグレードしようとしたらいろいろ変なことになったので、
アンインストール→ログアウト→ログイン→1.3.2.0インストール
ってやった方がいいと思われ。
個人的には「ログメッセージ表示の際に一番最初のリビジョンが表示されない」というバグが直って嬉しい。

それはそれとして、GitCheetahって何？
0612デフォルトの名無しさん2010/01/26(火) 23:15:21
GitCheetahはmsysGit同梱だった気がする。

たしかGitCheetahの方が先に始まったんだけど、Tortoiseというネームバリューの
せいなのか後発のTortoiseGITが有名になっちゃったという・・・。
TortoiseGITはTortoiseSVNをベースに作ってるけどGitCheetahは違うんかな。
0613デフォルトの名無しさん2010/01/27(水) 21:00:20
>>612
なるほど。GitChiitahの方が先だったのかぁ。
0614デフォルトの名無しさん2010/01/28(木) 15:50:11
微妙に異なる3ファイルの差分を表示してくれるツールってないですか。
TortoiseSVNのDiff, WinMergerでは出来ないっぽいです。
0615デフォルトの名無しさん2010/01/28(木) 16:02:05
diff3
0616デフォルトの名無しさん2010/01/28(木) 16:45:03
KDiff3というGUI版がよさそうな感じです。
ありがとうございます。
0617デフォルトの名無しさん2010/01/28(木) 17:16:43
vimも３ペインできるよ
0618デフォルトの名無しさん2010/01/28(木) 20:20:34
WinMergeもできるよ
0619デフォルトの名無しさん2010/01/29(金) 08:56:24
GoogleもMicrosoftもMercurial採用するみたいだけど、
多言語全然考えないっていう表明なんかね？これは
それとも今後解決するという希望の元になんだろうか？
0620デフォルトの名無しさん2010/01/29(金) 08:57:07
>>614
Windowsならp4mergeはどうかな？p4merge自体はフリーで入手できたはず
0621デフォルトの名無しさん2010/01/29(金) 19:10:20
だからといってBazaar採用するわけにゃいかんだろう
0622デフォルトの名無しさん2010/01/29(金) 20:35:51
>>621
なぜ？GNUだから？
0623デフォルトの名無しさん2010/01/29(金) 20:54:30
Ubuntuの開発元で作ってるから？
0624デフォルトの名無しさん2010/01/29(金) 21:14:04
Mercurialって多言語うんぬんの問題はあるけど、
政治的な立場がわりと中立だから採用しやすいのかなぁ。

そういえばSunが運営してたProject Kenaiが公開停止らしい。
0625デフォルトの名無しさん2010/01/29(金) 23:36:28
このスレの総意はBazaarってことでよろしく
0626デフォルトの名無しさん2010/01/30(土) 01:31:14
ClearCaseがクソらしいというのだけは総意と言える
0627デフォルトの名無しさん2010/01/30(土) 07:27:47
gitで手元でgit init したunkoserviceリポジトリを、
サーバー(ファイル共有でもなんでもいいけど)側に置いておきたいのですが、
どうしたらいいんでしょ。

単純コピーとか、手元からサーバーへcloneとか？

例えば、ファイルサーバー上にうｐしときたい場合はこんなんでよろし？
cd remote-unkoservice
git init

cd unkoservice
git remote add origin /remote/remote-unkoservice/.git
git push origin master

すごい基本的なことなんだけど、こういうちょっとした当たり前の運用tipsはどっかにまとまってないのかな？
0628デフォルトの名無しさん2010/01/30(土) 12:33:08
>>627
http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/gittutorial.html
0629デフォルトの名無しさん2010/01/31(日) 00:05:05
ウンコサービスっておまえ・・・w
0630デフォルトの名無しさん2010/01/31(日) 02:09:54
unkoをpushしないでください！
0631デフォルトの名無しさん2010/01/31(日) 15:50:03
初心者でVisualSourceSafe2005を使っています。
拡張キーワードの$Histor:$で日本語コメントが10文字程度しか反映されません。
たとえばチェックイン時にコメントで「コメント反映テスト」と入力しても、
Comment:コメント反映　までしか置換されません。

ググってもそれらしい話題にいきつかなかったのですが、どなたかご存知ないでしょうか。
0632デフォルトの名無しさん2010/01/31(日) 16:04:06
>>631
$Histor $
0633デフォルトの名無しさん2010/01/31(日) 16:06:45
>>631 スペースを入れてみたらどう？ >>632はスペースが消されてしまった。
$Histor            $

0634デフォルトの名無しさん2010/02/01(月) 15:07:30
趣味グラマなんですけど、今はバージョン番号や日付でフォルダ作って、
丸々バックアップって感じで、バージョン管理しています。
個人用途でもバージョン管理システムを使えばハッピーになれる？
0635デフォルトの名無しさん2010/02/01(月) 15:15:59
なれる。
なんで今まで使ってなかったんだろう、と思うことうけあい。
0636デフォルトの名無しさん2010/02/01(月) 15:49:12
darcs冷遇されすぎ
0637デフォルトの名無しさん2010/02/01(月) 16:36:28
エミュのステートセーブみたいなもんだよ
0638デフォルトの名無しさん2010/02/01(月) 17:38:54
一人で使うならリポジトリって実ファイルと同じディレクトリに.svnrepositoryとか作って格納したほうが幸せに慣れそうな気がしてきた。
もちろんバックアップは別系統できっちりとって。
0639デフォルトの名無しさん2010/02/01(月) 17:43:12
そして HDD あぼーん
0640デフォルトの名無しさん2010/02/01(月) 17:46:43
あ、バックアップはするのか。すまそw
0641デフォルトの名無しさん2010/02/01(月) 18:28:02
>>638
そんなあなたにbzr。
0642デフォルトの名無しさん2010/02/01(月) 21:58:44
>>638
そんなあなたにMercurial。
0643デフォルトの名無しさん2010/02/01(月) 23:45:58
>>638
そんなあなたにRCS。
0644デフォルトの名無しさん2010/02/02(火) 08:53:55
ファイルを以前の版に戻したいけどどの版が目当ての内容なのか判らないって時どうする？
0645デフォルトの名無しさん2010/02/02(火) 09:22:03
>>644
annotate
0646デフォルトの名無しさん2010/02/02(火) 12:46:58
>>644
もちろんコミットメッセージなんかあてにできないんだろうが、
「この処理はいつ消えた？」とかなら Diff していけばわかるだろ。
0647デフォルトの名無しさん2010/02/02(火) 13:00:43
どこの変更が原因でおかしくなったか分からない場合は
確実に動く版と現在の版の間で二分探索。
そのための機能がついてるシステムもあるな。
0648デフォルトの名無しさん2010/02/02(火) 13:06:23
順番にdiffとってそれを1ファイルで表示するって機能でもあればいいのかも
0649デフォルトの名無しさん2010/02/02(火) 13:25:37
TracとかRedmineとかと連携させればできるね
0650デフォルトの名無しさん2010/02/02(火) 14:14:01
>>648
hg log -p filename
のこと?
0651デフォルトの名無しさん2010/02/02(火) 14:54:20
>>646「この処理はいつ消えた？」とかなら Diff していけばわかるだろ。
むかしCVS annotateに行ごとにどのリビジョンで消えるかを出すパッチを書いたことがある。
テストスクリプトを書かないと受け付けてくれなくて、面倒になって捨てた覚えが。
0652デフォルトの名無しさん2010/02/02(火) 14:55:52
>>647
git bisect こないだ初めて使ってみたんだが、
ひどく便利だった。
0653デフォルトの名無しさん2010/02/02(火) 16:25:18
これはひでー
0654デフォルトの名無しさん2010/02/02(火) 16:42:31
分散バージョン管理システムMercurial 1.4.3/TortoiseHg 0.9.3リリース
ttp://sourceforge.jp/magazine/10/02/02/0556226
0655デフォルトの名無しさん2010/02/02(火) 17:54:40
Mercurialはゴミ
日本人に紹介すんな
0656デフォルトの名無しさん2010/02/03(水) 22:25:08
>>655
日本人でなければいいのか？

そういう外国人には何してもいいという考えは、
歴史上数々の国際紛争を引き起こしてきた一因ではないのか？
0657デフォルトの名無しさん2010/02/04(木) 05:05:57
そういうことは学校で議論しようね
06586272010/02/04(木) 07:51:07
ベアリポジトリを作る方向性にしました。
(source_path) 手元のリポジトリとソース
(dest_path) リポジトリをおいておく先

git clone --bair (source_path) (dest_path)
mv (source_path) (source_path).old
git clone (dest_path)

みたいな感じで無事に手元のをサーバーへおいておけました。
サーバー側へのpushも無事いけました。

このへんとかも参考になりました。
分散型の Web 開発の様相を変える Git
http://www.ibm.com/developerworks/jp/web/library/wa-git/index.html

あまりにも基本的なことを聞いてしまったようで失礼いたしました。
レスくださった方々ありがとうございました。
0659デフォルトの名無しさん2010/02/04(木) 12:06:26
>>656
Mercurialの日本語サポートに難があるから日本語には他のを勧めろという話だよ
外国人を差別していいという話じゃない
0660デフォルトの名無しさん2010/02/04(木) 15:07:01
>>659
難があるなら直せばいいじゃない
0661デフォルトの名無しさん2010/02/04(木) 15:12:06
直してから薦めればいいじゃない
06626342010/02/04(木) 15:27:07
>>635
ありがとう。使ってみます。
Mercurial使ってみようかと思ったんですが、
ゴミとか言ってる人がいるんで、gitかbazaar使ってみます。
0663デフォルトの名無しさん2010/02/04(木) 16:11:40
>>660
パッチがMercurialのMLに送られていたので wktk しながら見守っていたら、
「ファイル名はバイト列なんじゃい」と突き返されていたのを見て、
Bazaar に乗り換えました。
0664デフォルトの名無しさん2010/02/04(木) 16:23:44
まぁ仕事では使えんわな
0665デフォルトの名無しさん2010/02/04(木) 17:02:25
日本人の水銀に対するアレルギーは異常
いつまで引きずってるんだよ
0666デフォルトの名無しさん2010/02/04(木) 17:18:07
日本語に難がないのってBazaarだけじゃないの？
でもBzrってうんこじゃね
0667デフォルトの名無しさん2010/02/04(木) 17:40:30
>>663
勝手に日本語版を作ればいいじゃない
0668デフォルトの名無しさん2010/02/04(木) 19:33:45
bzrは何でもできるようにしたいって姿勢はわかるけど、なんか現時点で揃ってる機能のバランスが悪い
0669デフォルトの名無しさん2010/02/04(木) 20:48:09
>>668
なにが足りてなかったっけ?
0670デフォルトの名無しさん2010/02/04(木) 22:16:05
>>667
すっごい基本的な部分が変更されるから、いろんなプラグインや
外部ツールが動かなくなるのに？

>>666
どこがうんこ？
0671デフォルトの名無しさん2010/02/04(木) 22:42:29
名前が挙がるたびに即否定されるBazaar……

真っ当な理由のついてるレスを見たことがないんだが
0672デフォルトの名無しさん2010/02/04(木) 23:19:29
>>671
svkみたいなところ
0673デフォルトの名無しさん2010/02/04(木) 23:30:29
SVNから移行するには一番受け入れ易いんじゃないかな？Bazaar
ただgitやhgからならシンプルさ故に物足りない感じもするBazaar
現在絶賛拡張中でもあるし、特にgitやhg由来の機能についてはUIが
まだまだこれからという感じ。
ただgitやhgを使っている人でBazaarに期待を寄せている人も少なからず
いるということの裏返しとも言える。
0674デフォルトの名無しさん2010/02/04(木) 23:31:22
とはいえ日本語まともに使いたいとbazaarなんだよなぁ
0675デフォルトの名無しさん2010/02/04(木) 23:33:03
>>670
そうなの? Linuxでは問題なく使えているから、Windowsでもファイル名扱うと
ころだけ直せばいいんじゃないの。Pythonなおしたほうが早いのかもしれんが
0676デフォルトの名無しさん2010/02/04(木) 23:37:10
Windowsって本当に国毎に違うからな
unicode使ってるアプリでも他言語じゃ動かなくなることもあるし
0677デフォルトの名無しさん2010/02/04(木) 23:51:59
>>675
Pythonの問題じゃなくて完全にMercurialの設計思想の問題。
Python は Unicode でのファイルアクセスを許可しているし、
現にBazaarはファイル名をUnicodeで扱っている。

Linux で問題なく使えているのは、そのリポジトリにアクセスしているのが
全員 locale=utf-8 だからだよね？
一人でも euc の人が混じると、誰かのファイル名が文字化けする。
0678デフォルトの名無しさん2010/02/04(木) 23:59:51
>>677
そう、全員utf-8だからだね。
つまりhg専用のpython-jpを用意して、バイナリファイル名でのアクセスを勝
手にUnicodeでのファイルアクセスに置き換えるようにすればいいんだな。
0679デフォルトの名無しさん2010/02/05(金) 00:12:46
結局、あーだこーだといろいろ考えるよりも、ポッとインストールして
気軽に日本語が使える Bazaar が好きです。
0680デフォルトの名無しさん2010/02/05(金) 00:19:23
TortoiseBzrもだいぶ機能が入ってきたしね。
コミットメッセージの改行問題は地味に痛いが
0681デフォルトの名無しさん2010/02/05(金) 01:05:35
svnで何も困ってない　　けど
こんなにsvnが話題にならないってことは
きっと他のは凄いんだろうな
svnとCVSとRCSしか使ったこと無いからよく分からんけど

RCSはローカルのWindowsマシンでちょっとファイルを編集するときに未だに使ってる
0682デフォルトの名無しさん2010/02/05(金) 01:14:41
svnは機能的にも実装的にも安定し過ぎててあまり話す事がない。
専用スレもあるし。
0683デフォルトの名無しさん2010/02/05(金) 07:55:00
svnはテメエで trunk/ tags/ branches/ を作れっていう考えなのが嫌い
内部の実装はそれでもいいけど、ユーザにそれを見せるなって思う
0684デフォルトの名無しさん2010/02/05(金) 08:01:56
>>669
今のbzrにはもうgit branchとかhg branch相当の機能って入ってる？
0685デフォルトの名無しさん2010/02/05(金) 12:07:09
>>681-682
仕事で少人数でTortoiseSVN開発してるけど、
ちょっとしたことでうちで開発したくなった時以外、あまり困ったことない。

gitとかも憶えようと使っているけどsvnで困ってないのはgitをまだ全然理解できてないせいだと思うけどｗ

>>684
マジか、bzrってbranchないのかよ！どうやって枝分かれして開発寸の？毎回リポジトリcloneすんのかな？
0686デフォルトの名無しさん2010/02/05(金) 12:08:02
x うちで開発したくなった時
o 家で開発したくなった時

紛らわしかったすまそ
0687デフォルトの名無しさん2010/02/05(金) 12:15:54
>>685
いや、普通にbranchあるよ。
git や hg に比べると、操作の主体がリポジトリじゃなくてブランチになってるから
移行組には判りにくいだけ。
むしろ、初心者にとってはディレクトリパスやURLが直接ブランチを指すのは
判りやすいんじゃないかな。

>>684
今はまだプラグイン。
0688デフォルトの名無しさん2010/02/05(金) 12:17:32
人数が多くなってくると分散型でもないと気軽にbranchとか作れないからな
0689デフォルトの名無しさん2010/02/05(金) 12:43:13
フレームワーク型のプロジェクトで、
プロジェクトのルートディレクトリ以下は公式からもらってくるupdateオンリーで、
そのサブディレクトリ以下に手元で更新するファイルを独自に管理したいんだけど、
こういうのができるバージョン管理システムってあるのかな。
Subversionではうまくいかないみたい。
0690デフォルトの名無しさん2010/02/05(金) 13:19:25
>>689
Bazaar の scmproj プラグインでできると思う。
scmproj プラグインは、Bazaar以外のVCSとも連携できる。
0691デフォルトの名無しさん2010/02/05(金) 19:54:10
>>689
boostとか最新版のzipのダウンロードを展開してSubversionにぶち込んでるけど、うまくいかないってどんな風になの？
0692デフォルトの名無しさん2010/02/05(金) 21:18:17
>>690
ども。試してみる。
>>691
大雑把に言えばこんな感じ。
framework/
　/bin
　/usr
　/projects(*)
　/shared
　/plugin
こんな構成でprojects以下を独自に管理したいとき、
別のリポジトリからチェックアウトしたものでサブディレクトリを上書きすると、
ルートディレクトリ（framework）からupdateがかけられない。
0693デフォルトの名無しさん2010/02/05(金) 21:56:35
>>692
チェックアウトしたものを上書きするってことは.svnを上書きしたな。それならupdateできないな。
マージで上書きするか、エクスポートして上書きするほうが良いんじゃないか。

ところで(*)ってファイル名？
0694デフォルトの名無しさん2010/02/05(金) 22:14:53
svn的に言えば、svn:externalsを使うのかな。

/projects を特別扱いするんじゃなくて、逆に
/bin, /usr, /shared, /plugin を他リポジトリから持ってくる。
0695デフォルトの名無しさん2010/02/06(土) 00:32:40
>>687
URLでブランチということはsvnみたいってこと？
0696デフォルトの名無しさん2010/02/06(土) 08:13:17
>>689 じゃないけど、Redmineみたいにフレームワークやアプリの基本ソースが常にアップデートしていく場合、
そのシステムに対する変更をする場合、gitだとうまく管理するにはどうしたらいいのかな？

redmineの公式リリースをredmine_releaseリポジトリで管理して、
そこからcloneしてmy_redmineリポジトリで管理、
my_redmineを自分の好みに弄る。
redmineがバージョンアップしたのでredmine_releaseリポジトリを更新、
my_redmineはredmine_releaseからpull、
という感じですればパッチを適用しつつ、公式に追従できるのかな？

もっとやりやすい方法有る？
branchでもできるのかもしれないのだけどよくわからない・・・。branch間のpullてできるの？
この辺に関連するドキュメントってどこら辺に有りますか？
0697デフォルトの名無しさん2010/02/06(土) 08:30:05
>>696
branch間はmergeじゃないかな。cloneでやってもいいけど。
0698デフォルトの名無しさん2010/02/06(土) 09:55:21
>>696
git remote add origin redmine.gitしてpull
git checkout -b myredmine origin/masterとかして以後はmyredmineブランチで作業しつつ
公式の変更を取り込みたいときはpullなりfetchなりしてorigin/masterをmyredmineにmergeかなあ
0699デフォルトの名無しさん2010/02/06(土) 15:45:15
>>685
cloneする

>>695
branch自体ない
0700デフォルトの名無しさん2010/02/06(土) 16:14:28
>>683
それは強く思う
0701デフォルトの名無しさん2010/02/07(日) 09:44:03
>>699
だからbranchあるって。むしろ今はcloneが無い。
今はcloneコマンドはbranchコマンドのエイリアスになっているけど、
次のバージョンではエイリアスを解除して、さらに次のバージョンでcloneが作られる。

>>699がレポジトリだと思っている物は実際はブランチだから。
hgとgitとはブランチをどう扱うかに違いがあるだけで、ちゃんとブランチはある。
hgやgitと同じ扱い方をする為のプラグインもあるし、将来メインに統合される予定。

>>695
svnと比較すると、 tags/ が各ブランチの中で管理されて、各URLが指すのが
ブランチのみになる。
0702デフォルトの名無しさん2010/02/07(日) 10:05:19
>>697-698
おおそれでいいのか。branchで十分て感じなのね。
やってみるっす！ありがとう。git便利ね！
0703デフォルトの名無しさん2010/02/08(月) 10:48:38
個人開発でよさげなのって何かないすか？
0704デフォルトの名無しさん2010/02/08(月) 11:39:18
rcs
svn file://
0705デフォルトの名無しさん2010/02/08(月) 11:49:50
>>703
WindowsユーザーならTortoiseSVN
0706デフォルトの名無しさん2010/02/08(月) 18:55:38
Subversionを使っててMercurialに乗り換えてしばらくした後、
どうしてもSubversionじゃないといけないプロジェクトで再び使ってみたら
あまりの遅さにビックリした。何をするにも中央リポジトリと通信するから
もうアホみたいに遅い。特にTortoiseSVNと使うと余計遅い。
0707デフォルトの名無しさん2010/02/08(月) 19:06:50
winユーザにはSVNが一番薦めやすいのが現実
0708デフォルトの名無しさん2010/02/08(月) 19:20:08
比喩的な比較。

Bittorrent: Subversion
Winny, Share: Mercurial
WinMX: git
0709デフォルトの名無しさん2010/02/08(月) 19:29:04
どういう要素をどう比較した喩えなのか全然分からん
0710デフォルトの名無しさん2010/02/08(月) 19:40:47
MS-IME: Subversion
一太郎: Mercurial
Google日本語入力: git
0711デフォルトの名無しさん2010/02/08(月) 20:04:09
そういうのいいから
0712デフォルトの名無しさん2010/02/08(月) 21:10:01
TortoiseSVNがあったからここまでバージョン管理が一般化したってのはある。
でももうSubversionはレガシーな気がしてならない。
0713デフォルトの名無しさん2010/02/08(月) 21:14:08
RabbitGitが出たら乗り換える
0714デフォルトの名無しさん2010/02/08(月) 22:26:59
>>713
GitCheetahには期待しないということですね。わかります。
0715デフォルトの名無しさん2010/02/08(月) 23:02:47
gource
http://code.google.com/p/gource/
0716デフォルトの名無しさん2010/02/09(火) 11:51:44
>>710
そんな感じだなｗ
x 一太郎
o ATOK
0717デフォルトの名無しさん2010/02/11(木) 16:09:47
VSSがダメなのってなんで？
VSと連携できるバージョン管理システムって他になんかある？
0718デフォルトの名無しさん2010/02/11(木) 16:16:14
>>717
ダメってことはないよ。ダメだといっている人は
文字コードをうまく扱えない人が多いんだと思う。
0719デフォルトの名無しさん2010/02/11(木) 17:29:52
>>717
プラットフォームが限定されるとかクソ高いとかそんなところだろ。
プロジェクト間でファイルを共有できる機能はいいよねえ。
ほかのツールでも実装されると嬉しいんだがな。
0720デフォルトの名無しさん2010/02/11(木) 17:32:03
チェックアウトしないと編集できない
他の人がチェックアウトしてるとチェックアウトできない
というのは相変わらずなの？
0721デフォルトの名無しさん2010/02/11(木) 17:39:16
>>720
変えることは無いと思う。
一元管理を徹底することが主眼になってるから
その前提を覆す実装は今後もないんじゃないかな。
0722デフォルトの名無しさん2010/02/11(木) 17:39:27
>>717
svnやhg等でもVSに組み込めるよ。
0723デフォルトの名無しさん2010/02/11(木) 18:04:34
>>717
Visual Studioと連携できるのっていうと、
MS謹製なら Visual Studio Team Foundation Server かな。
あれはソース管理だけじゃなくてITS/BTSとか
ビルドサーバとか色々抱き合わせになってるけど。

VS2010が出るタイミングで、MSDN契約者ならタダで使える下位版が
出るって話をどこかで聞いたような覚えがあるような無いような。
0724デフォルトの名無しさん2010/02/11(木) 18:35:28
ビルド作業をサーバー側にやらせないといけないような規模の案件には
あいにくお目にかかったことがないのでどうでもいいっちゃいいな。
07257172010/02/11(木) 18:44:41
>>718
逆に言うと文字コード周りで不具合があるんでしょうか？
試しに使っている分ではUTF-8で問題なさそうです。

>>719
VSで開発って時点でサブスクリプションに入っているので、その辺はクリアです。

>>720
VSS2005ですが、DB(リポジトリと言うべき？)の設定で変えられます。

>>727
調べてみます。

>>723
だがしかし、サブスクリプションの最上位ではなかったorz
0726デフォルトの名無しさん2010/02/11(木) 20:41:21
>>712
でもまぁ、巷では枯れてから始めて本格的に使い始めるようなところも多いしね。
0727デフォルトの名無しさん2010/02/11(木) 20:57:12
VSからbazaar使う方法ありますか？あれば教えてください。
0728デフォルトの名無しさん2010/02/11(木) 21:00:44
>>727
いちおうプロジェクトはあるみたい
http://wiki.bazaar.canonical.com/VisualStudioIntegration

でも、Visual Studio のアドオンを作るのにも使うにも Standard
以上が必要だから、あんまり開発進んでないと思う。
0729デフォルトの名無しさん2010/02/12(金) 13:59:08
>>725
> >> 720
> VSS2005ですが、DB(リポジトリと言うべき？)の設定で変えられます。

多重チェックアウトのことをいってるなら、VSS の 5 あたりからできてたはず。
それより前のバージョンは知らない。
これ設定できるの知らないやつ結構多いね。
(VSS の)admin 権限で操作すれば、他人のチェックアウトを強引に取り消すこともできるから、
チェックアウトしたまま蒸発したり氏んでしまったりしても大丈夫。
管理者が蒸発したり氏んだりしなければ。
0730デフォルトの名無しさん2010/02/12(金) 14:54:11
チェックアウトしないと編集できないというのが致命的。
0731デフォルトの名無しさん2010/02/12(金) 21:32:23
クリアケースつかえねぇわ
0732デフォルトの名無しさん2010/02/13(土) 11:04:04
>>730
分岐してマージはできるから問題ないけどな。
0733デフォルトの名無しさん2010/02/13(土) 15:03:53
>>683
tool側で何とでもしろ、っていうことじゃないのかな？
例えばSubversiveだったら意識させないような作りになってるけど。
0734デフォルトの名無しさん2010/02/13(土) 16:20:31
>>376
hg は根本解決ができないっていうなら、gitもだよ。
utf-8 cygwin 入れたら使えるのは hg も git も同じ。

hg はcygwin無しでもがんばれば utf-8 化できるけど、そこをがんばれる人材
(PythonでUnicode使いたい人)はbzrを選んじゃう
0735デフォルトの名無しさん2010/02/13(土) 16:22:57
>>683
内部の実装には、trunk/tag/branchesは関係ない。
ただの運用上の指針じゃないか。だたそれに従っておけば、totoisSVNだとtagに変更をコミットしようとしたときに警告が出たりリビジョングラフが分りやすくなったりするメリットはあるね。
0736デフォルトの名無しさん2010/02/13(土) 16:52:05

>>734
根本的、っていうのは>>663みたいなプロジェクトの方針みたいなのも含まれるのかなあ、と。
0737デフォルトの名無しさん2010/02/14(日) 00:18:38
>>683
svnにtag branchなんていらないと言ってるんだからあきらめろ

>>734
branchなくても困らないならbzrでいいんじゃないの?
branchがないと言ったらまたbzr厨が暴れるかwww
0738デフォルトの名無しさん2010/02/14(日) 00:27:18
bzrにbranchが無いとかほざいてる方が頭おかしいと思うが。
0739デフォルトの名無しさん2010/02/14(日) 01:46:22
知ってるつもりって番組あったよな
0740デフォルトの名無しさん2010/02/14(日) 10:30:51
試してガッテンというのもあったな
0741デフォルトの名無しさん2010/02/14(日) 10:38:17
>>738
Bazaar の実装は少し変わってるけど、そこをきちんと説明しないからいけない。
0742デフォルトの名無しさん2010/02/14(日) 10:46:14
>>741
なんでいきなり説明責任を押し付けられるんだよ
ブランチが明示的なディレクトリになっているのなんて、svnも一緒じゃん。変でもなんでもない。
hgやgitと違うからってだけで、ブランチが無いとか決め付けてる>>699がいるから
ブランチあるよと言っただけなのに、なんでbzr厨呼ばわりされなきゃならんのだ。
0743デフォルトの名無しさん2010/02/14(日) 12:48:31
「ブランチ」という名前の何かを作れるということと、
gitみたいな機能や使い勝手を実現していることとは別問題じゃね。
0744デフォルトの名無しさん2010/02/14(日) 12:53:35
>>743
そう。それを >>687 で説明済みなのに、>>695 に対して >>699 みたいな
回答をするアンチがいるだけ。
0745デフォルトの名無しさん2010/02/14(日) 14:31:45
>>742
すまんな、お前に押し付けたつもりはない。Bazaar の説明全般に言えることだ。
だが >>738 の書き方もほめられたもんじゃないがな。
0746デフォルトの名無しさん2010/02/14(日) 15:02:20
>>745
Bazaarの説明全般って、
http://doc.bazaar.canonical.com/bzr.2.0/ja/user-guide/core_concepts.html
http://doc.bazaar.canonical.com/bzr.2.0/ja/user-guide/organizing_your_workspace.html
に十分書いてあると思うけど。

どのVCSを選んでも、ブランチの扱いについてはある程度の勉強が必要。
gitかhgを使ってた人がちょっとbzrを触って今までと同じ使い方ができなかったからって、
「bzrにブランチは無い」なんて間違った情報を書き込み、間違いを指摘されたら
>>737みたいな言い方をするんだ、あきれて >>738 みたいな返し方しかできない。
0747デフォルトの名無しさん2010/02/14(日) 15:45:21
どうでもいい事で引っ張りすぎ
0748デフォルトの名無しさん2010/02/14(日) 16:51:34
頭のおかしなキチガイをのさばらせることの、
どこがどうでもいい事なんだ
0749デフォルトの名無しさん2010/02/14(日) 17:07:15
cvsしか使ったことのない人間に薦めるならgitとbzr、どっちがいい？
どうせ性能は拮抗しているだろうから操作感覚がコンパチな方を教えろ。
0750デフォルトの名無しさん2010/02/14(日) 17:13:09
git
0751デフォルトの名無しさん2010/02/14(日) 17:30:47
cvs からならどっちでもいいんじゃね?
svn からなら bzr だろうけど
0752デフォルトの名無しさん2010/02/14(日) 18:43:38
>>750-751
ありがとう
svnは個人的に思想が嫌いなので、bzrはやめてgitにします。
0753デフォルトの名無しさん2010/02/15(月) 05:51:35
>>752
思想的にはsvnよりかはgitの方が嫌らしいと思うが。
0754デフォルトの名無しさん2010/02/15(月) 07:13:21
いやらしいのが好きです
0755デフォルトの名無しさん2010/02/15(月) 08:19:06
gitなんて使ったらボク妊娠しちゃう；；
0756デフォルトの名無しさん2010/02/15(月) 10:46:42
>>753
どんな風に？

svnはやたらとCVSをディスってて気分が悪くなったものだが
0757デフォルトの名無しさん2010/02/15(月) 10:56:21
CVS はディスられてもしょうがないじゃん。
(歴史的事情とかはあるけどね

git つか Linus の svn へのディスりようも相当だったけれど
これも言われて当然じゃね?
0758デフォルトの名無しさん2010/02/15(月) 17:26:16
そうか・・・gitも悪い子だったか・・・
cvsを使い続けようかな
0759デフォルトの名無しさん2010/02/15(月) 17:32:22
それはないわ
0760デフォルトの名無しさん2010/02/15(月) 17:52:25
困ってなさそうだから
それはそれでいいのでは?
0761デフォルトの名無しさん2010/02/15(月) 22:18:24
>>757
svnはBitKeeperの代替にはなれないのでは
0762デフォルトの名無しさん2010/02/15(月) 22:44:59
しかし現状では安牌と言わざるを得ないのが現実。
0763デフォルトの名無しさん2010/02/15(月) 22:47:20
冷凍庫の中もバージョン管理したいよな・・・
このコロッケはいつのだろうか・・・
0764デフォルトの名無しさん2010/02/15(月) 22:57:18
Linus の批判はもっともな点があると思うけど、
実際問題、ブランチとかマージとかって、みんなそんなに頻繁にやる事なの？
たとえば、非プログラマのユーザに、文書ファイルの管理を
TortoiseSVNでやらせる、みたいなファイル共有+差分バックアップ+α　の機能しか
使わないような分野もけっこうあるのでは？
というか、最終的には全体としてはそういうプログラム開発以外での使用が
大多数を占めて、プログラム開発というのは、特殊な一用途に過ぎなくなる
かもしれない（まあ、こんなことまで考えるのは板違いかもしれんけど。）。
0765デフォルトの名無しさん2010/02/15(月) 23:00:30
>>764
ブランチは結構するかな。
すぐ本家に反映して、ブランチはぶらぶらさせたまま放置するけど。

ハッ！　だからブランチっていうのか！
0766デフォルトの名無しさん2010/02/15(月) 23:28:40
>>764
svnだとめんどくさいんであんまりやらないけど、gitだとまずブランチ切って作業って手順が体に染みついてるなあ。
リモートにpushしないローカルだけのブランチは、なんというか俺の部屋って感じで好き勝手できて気が楽だｗ
0767デフォルトの名無しさん2010/02/15(月) 23:32:16
>>761
今更「なれないのでは」って…
SVNの中の人もとっくの昔に「無理です」って言ってたのに
0768デフォルトの名無しさん2010/02/15(月) 23:44:38
Linusの場合はLinuxの開発フローに対して使えるか使えないかに
最も興味があって、その場合頻繁なマージが容易にできるという
のがキーになる。それだけのことだろう。
一般的にそのようなケースがレアであろうと、彼にとってはどう
でもいいはず。
0769デフォルトの名無しさん2010/02/16(火) 03:00:18
>>746
わかった
bzrにはbranchがあります。
ただしリポジトリに対してlogを見たりtagを打ったりはできませんでいいか？
0770デフォルトの名無しさん2010/02/16(火) 04:55:26
それでもあえてdarcsを使いつづける
0771デフォルトの名無しさん2010/02/16(火) 09:32:01
>>767
Linusの選択基準の想定をしたまでで、指摘されなくても知ってます。
0772デフォルトの名無しさん2010/02/16(火) 09:58:36
>>764
プログラム開発でも、おいらのまわりでは残念だけど一部だけかなぁ、
ブランチとか使ってるのって。

ネット界隈を見てると、みんな使いこなしているように思えるけれどね。
0773デフォルトの名無しさん2010/02/16(火) 11:12:39
>>769
そうですね。bzrではブランチが一連の変更履歴、リポジトリはリビジョンを格納する場所と
明確に分かれているので、 log の対象はブランチになります。
git や hg では、リポジトリに対するログは、リポジトリのデフォルトのブランチに対するログ
ではなくて、リポジトリ内の全ブランチに対するログになるのでしょうか？
bzr では複数ブランチに対するログは qlog などの GUI やプラグインで可能ですが、
標準コマンドでは一つのブランチに対してしかログができませんね。
0774デフォルトの名無しさん2010/02/16(火) 11:17:45
ブランチって切るものだったのか
0775デフォルトの名無しさん2010/02/16(火) 12:38:16
ブランチって食べるものじゃね？
0776デフォルトの名無しさん2010/02/16(火) 12:53:16
uncommit
0777デフォルトの名無しさん2010/02/16(火) 13:10:22
Hgではコミットごとにブランチができる感じ。
マージすればブランチが網の目のようにつながる。
どのリビジョンからも新しいブランチを作れる。
0778デフォルトの名無しさん2010/02/16(火) 13:12:33
どのリビジョンでもいじってコミットすれば新しいブランチができてる
です。
0779デフォルトの名無しさん2010/02/16(火) 13:23:19
>>768
そういう点では、Linux の偉大さを除外して考えると、
自分の業務には使えない・合わない、
みたいな理由で、特定の製品を屑だとかゴミだとか
叩いてる、2ch でよく見かけるアンチ君たちと、
メンタリティ的には変わらないんだよね。
0780デフォルトの名無しさん2010/02/16(火) 16:58:15
Git 1.7.0登場、一部に後方互換性なし
ttp://journal.mycom.co.jp/news/2010/02/16/031/index.html
0781デフォルトの名無しさん2010/02/16(火) 17:14:56
>>779
ゴミばかりだから自分で作る
という所までいかないと
0782デフォルトの名無しさん2010/02/16(火) 17:32:17
>>781
ああそうか、Linus の根本的に違うところはそこか。
どんなにわがままな事いう奴でも、
それを自分で実現しちゃう奴は、けなしようがないもんな。
0783デフォルトの名無しさん2010/02/17(水) 04:04:09
msysGitで早く1.7.0出ないかなー。
0784デフォルトの名無しさん2010/02/17(水) 08:26:55
msys使うのは糞
0785デフォルトの名無しさん2010/02/17(水) 14:42:34
Bazaar 2.1.0リリース
ttp://sourceforge.jp/magazine/10/02/17/0426233

>Bazaar 2.1.0は機能のブラッシュアップとバグフィックスを中心としたリリースで、
>Bazaar 2.0系から機能面での大きな変更は加えられていない。
>主な改善点としては「bzr+ssh://host/?/」といったスタイルでの
>リポジトリ指定に対応したほか、メモリ消費量の削減やWindows環境における
>ワイルドカードを利用したファイル名指定サポートの改善などが挙げられている。

>Bazaar 2.1系では今後バグフィックスのみが行われ、新機能の追加等は
>次期版となるBazaar 2.2系に対してのみ行われる予定だ。
0786デフォルトの名無しさん2010/02/17(水) 16:22:51
ttp://dsas.blog.klab.org/archives/51639672.html
>updateコマンドに-rオプションがつきました。
やっとか。
0787デフォルトの名無しさん2010/02/17(水) 22:32:44
おお、ついに Mercurial を捨てるときが来たか。
0788デフォルトの名無しさん2010/02/18(木) 11:40:38
>>764
仕事がsvnだが一個機能実装するときはまずブランチ切ってるよ。

>>786
指定のリビジョンに更新ができるようになったってことか。ようやくまともに使えるようになるなｗ
0789デフォルトの名無しさん2010/02/18(木) 11:52:39
>>788
実装が終わったらブランチは消してる？そのまま？
07907882010/02/18(木) 12:18:23
ブランチそのままだわ。普通はtrunkにマージしたら消すもんなのかな？
07917882010/02/18(木) 12:19:54
当たり前だけどブランチのディレクトリ消しても、リビジョンやコミットの情報は残るんだよね？
過去のを参照できなくなる訳ないよな。見た目上ブランチのディレクトリがないから消したら参照しにくいだけで・・・
0792デフォルトの名無しさん2010/02/18(木) 14:01:33
>>788
> 指定のリビジョンに更新ができるようになったってことか。ようやくまともに使えるようになるなｗ

戻すだけなら revert とかでもできたけどね。
0793デフォルトの名無しさん2010/02/18(木) 16:37:50
外部公開用ファイルと自分の秘密ファイルの混合運用できるのってないの？
公開リポジトリに秘密ソースの痕跡は絶対残したくない
0794デフォルトの名無しさん2010/02/18(木) 18:02:43
>>793
mq
0795デフォルトの名無しさん2010/02/18(木) 18:05:03
>>791
残る。削除したディレクトリと同じ扱い。
削除してないということは、ブランチはみんな別の名前がついてるんだね。
0796デフォルトの名無しさん2010/02/18(木) 18:27:57
>>794
これのこと？
http://d.hatena.ne.jp/dayflower/20090520/1242794877
0797デフォルトの名無しさん2010/02/18(木) 21:29:18
>>796
pbranchとかもあるよ
0798methane2010/02/18(木) 21:33:30
あちゃー、bzr-2.1 で WinMerge とかで日本語ファイル名のdiffを見ようとすると止まる。
qdiff しか使えない。
0799デフォルトの名無しさん2010/02/19(金) 02:25:49
>>793
gitならstgit
あるいはそういうの使わなくても、分散型ならリポジトリ分ければ出来るような。
08007882010/02/19(金) 09:24:36
>>795
そっかサンクス。消したディレクトリと同じ扱いか、わかりやすいな。
確かにブランチは全部別の名前つけてるねｗ

よく考えたら消したブランチとかの名前もリビジョングラフとか見たらわかるからまあいいのか
0801デフォルトの名無しさん2010/02/21(日) 03:09:21
なぜdarcs使いがあまりいないんだ
0802デフォルトの名無しさん2010/02/21(日) 05:24:47
布教してみてよ
0803デフォルトの名無しさん2010/02/22(月) 00:08:58
Haskellerだからdarcs使ってるが、そうじゃなかったら多分使ってないな
0804デフォルトの名無しさん2010/02/22(月) 17:22:52
ver A-> ver B->ver C
と改良していって
ver Bの変更が気に入らないのでそれを抜かして
ver A -> ver C
にできるのがdarcs
0805デフォルトの名無しさん2010/02/22(月) 20:44:22
>>804
リバースマージ機能？
それだけだと他のVCSに対する優位性が分からないかと…
0806デフォルトの名無しさん2010/02/22(月) 22:38:14
17日(米国時間)にSubversionプロジェクトがApacheプロジェクトのもとでトッププロジェクトとして認定されたと発表されている。

名称が『Subversion』から『Apache Subversion』となるほか、ホームページもhttp://subversion.apache.org/へ変更となる。

Subversionは2009年11月にApacheプロジェクトへ提案されている。4
ヶ月ほどでトップレベルプロジェクトへと昇格したことになる。

SubversionはOSSで開発されているバージョン管理システム。
CVSの問題を解決するべく開発されたシステムで、CVSにおける問題のいくつかが解決している。
操作方法がCVSを踏襲していることからCVSから乗り換えるプロジェクトも多く、発表当時は次期バージョン管理システムとして人気があった。

現在、バージョン管理システムはSubversionではなく、Subversionが抱える問題を解決した新しい分散型のバージョン管理システムGitや
Mercurialなどに人気があり、Subversionから乗り換えるプロジェクトも多い。

http://journal.mycom.co.jp/news/2010/02/22/004/index.html
0807デフォルトの名無しさん2010/02/22(月) 23:07:15
>805
良く分からんけど、最初っから verB が存在しなかったかのように扱えるってことじゃないの？
git なら rebase -i でできると思うけど。
0808デフォルトの名無しさん2010/02/22(月) 23:20:02
svn roadmapの

Long-term Goals

*

hybrid distributed/centralized VC model

ってどゆこと？
0809デフォルトの名無しさん2010/02/22(月) 23:40:59
>>804
たとえば、verBではクリスマスになったらウィンドウを真っ赤にするコードが
入っていて、それを取り除くことが出来るってこと？
0810デフォルトの名無しさん2010/02/22(月) 23:56:34
>>809
うん
0811デフォルトの名無しさん2010/02/23(火) 00:40:55
ver A-> ver B の変更箇所をさらに ver B->ver C でも変更してた場合はどうなるの？
パッチベースでもさすがに ver B をなかったことにはできないと思うんだけど。
0812デフォルトの名無しさん2010/02/23(火) 20:22:24
その場合は競合になるけど？
何が問題？
0813デフォルトの名無しさん2010/02/24(水) 02:01:36
しかし、どうやってver Bを取り除いてるんだ？
行番号の整合性とかどうしてるんだろう
まさかそれ以降のコミットの行番号をすべてずらしてるとか？
0814デフォルトの名無しさん2010/02/24(水) 12:47:02
>>813
行番号の整合性くらいはどうとでもなるでしょw
0815デフォルトの名無しさん2010/02/24(水) 13:00:54
とりあえず同じことはgitでもできるってことでいいのかな?
0816デフォルトの名無しさん2010/02/24(水) 19:22:32
殆どのバージョン管理システムではできるはずだよ。
0817デフォルトの名無しさん2010/02/25(木) 10:11:00
>>816
DAGで合流のところはマージを表しているけど、
unmargeってどう表現するの?
できるっていっても、逆差分だったり履歴の改変だったりしない?
0818デフォルトの名無しさん2010/02/25(木) 10:32:18
「VersionControlTools」
http://martinfowler.com/bliki/VersionControlTools.html

ファウラーたんがClearCaseとTFSにダメ出し。
あと、VSSは論外とか書いてるね。
英語が分からんので、詳しいところまで読めてないけど。
0819デフォルトの名無しさん2010/02/25(木) 18:32:01
>>818
bazaarも論外ですかね？
0820デフォルトの名無しさん2010/02/25(木) 19:06:57
TFSも2010のは気になるんだけどね。
アレと同じ事をOSS組み合わせてやるのも大変かなーと思って。
0821デフォルトの名無しさん2010/02/25(木) 20:03:47
でもお高いんでしょ？
0822デフォルトの名無しさん2010/02/25(木) 20:43:08
>>819
Bazaarの評判は時々聞くが、gitやMercurialほどの頻度でもないから省いた、とある
0823デフォルトの名無しさん2010/02/25(木) 20:52:29
>>818
判断基準が解らないなあ
0824デフォルトの名無しさん2010/02/25(木) 21:09:16
>>821
これを見ると、VS2010 Pro with MSDNを買えば、サーバもCALもついて$1,199(更新$799)。
VS2010での開発もできるし、MSDNもつくし、2008の価格に比べれば導入も現実的な価格じゃないかな。
http://blogs.msdn.com/slange/archive/2010/01/26/it-s-official-vs-2010-branding-pricing.aspx
0825デフォルトの名無しさん2010/02/25(木) 22:02:43
VSSは昔は文字コードおかしいだけでリポジトリ飛んだりとかかなり糞だったけど
今は普通に使えると思う
得にCJK環境においては、ファイル名化けないってだけでもアドバンテージでかい
0826デフォルトの名無しさん2010/02/28(日) 17:32:07
gitみたいな分散型って、
　一人svnで使ってるリポジトリ間でマージやコミットもできる
みたいなノリなの？
0827デフォルトの名無しさん2010/02/28(日) 19:37:57
出張前に、ノートパソコンに出張用svnリポジトリ作って会社svnリポジトリからコピーさせて、帰ってきたら会社のsvnリポジトリにマージさせてるけど、そんな感じなのかな？
0828デフォルトの名無しさん2010/02/28(日) 19:43:07
>>826-827
つ分散バージョン管理入門 (イラスト入り) - tcha.org
http://tcha.org/2010/intro-to-distributed-version-control-illustrated/
0829デフォルトの名無しさん2010/03/03(水) 22:07:27
ソースコード管理システム「Darcs 2.4」リリース
ttp://sourceforge.jp/magazine/10/03/03/0326231
0830デフォルトの名無しさん2010/03/04(木) 01:49:51
今の時代は、ＶＳＳからＳＶＮに移行してるんじゃないの？
悲観的ロックって時代遅れ？
0831デフォルトの名無しさん2010/03/04(木) 02:03:45
>>830
今時svnはないな。CVSのままか、gitに移行してるかの二択だろ。
0832デフォルトの名無しさん2010/03/04(木) 02:24:52
え？
0833デフォルトの名無しさん2010/03/04(木) 05:30:12
gitでgitignoreの書き方がイマイチわからんです。
例えば、cacheディレクトリのdotfile以外(.htaccessとか)を無視するにはどう書けばいいんでしょ
.gitignoreにて、
　cache/
などと指定しておいて、
　git add cache/.htaccess -f
でもまあいいんですが、みなさんこんなことしているのかな、と思いまして。
08348332010/03/04(木) 06:13:04
cache/*.*
!.htaccess
のように.gitignoreを記述したら上手く行きました。
cache/
!.htaccess
ではダメでした。この辺の違いがイマイチわからんですが、できたのでよしとします。

しかし思うのですがgitでgitignoreを記述した時やファイル含むディレクトリを追加するときに、ただgit statusした場合、
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# cache/
などと表示されcache/以下が結局どうなるか？というのがイマイチわからず、
git add . してgit statusして初めて詳細がわかる、というのはこんなものなのでしょうか？
0835デフォルトの名無しさん2010/03/04(木) 06:51:20
>>834
cache/以下はUntrackedだから、その下がどうなってようと表示する意味もないし、それで合ってるんじゃない？
0836デフォルトの名無しさん2010/03/04(木) 09:11:26
>>831
オプソと非オプソで状況は違う。

プロプライエタリなソフト開発の現場では
リポジトリは開発者個々人のものではなく、会社の資産になるので、
分散型の場合は管理し辛い。

そもそも会社組織つーのはバザールモデルの対極にあるわけだから、
最初から分散型がうまく適合するなんていうところはむしろ稀だと思うよ。
0837デフォルトの名無しさん2010/03/04(木) 14:47:55
Mercurialの一人勝ちだな。Git(笑)
http://www.google.co.jp/trends?q=vss%2Crs%2Ccvs%2Csvn%2Cgit%2Cmercurial&ctab=0&geo=all&date=all&sort=0
0838デフォルトの名無しさん2010/03/04(木) 15:01:12
rsって何?
0839デフォルトの名無しさん2010/03/04(木) 15:13:05
6 つ目以降のキーワードは除外されています
0840デフォルトの名無しさん2010/03/04(木) 16:11:23
http://www.google.co.jp/trends?q=cvs%2Csubversion%2Csvn%2Cgit%2Cmercurial
MercurialよりGitの方が多いですね。
アメリカではCVSが、日本ではSubversion=SVNが主流のようです。
0841デフォルトの名無しさん2010/03/04(木) 21:32:50
CVSって同音異義語が多くね？
0842デフォルトの名無しさん2010/03/04(木) 21:43:30
Mercurialはhgの別名もあるから、キーワードが分散してるかもね。
Subversionよりもsvnの方が多いし、別名がないgitはやや有利か？
0843デフォルトの名無しさん2010/03/04(木) 23:26:33
>>838
ロマサガじゃね
0844デフォルトの名無しさん2010/03/05(金) 00:00:43
>>840
Mercurialハナクソだな
0845デフォルトの名無しさん2010/03/05(金) 00:06:18
SVNったらスロベニアが出てくるぞたくさん
スポーツなんかはみんなSVN表記だしな
0846デフォルトの名無しさん2010/03/05(金) 00:08:37
gitもたくさんあるじゃん
http://en.wikipedia.org/wiki/Git
0847デフォルトの名無しさん2010/03/05(金) 00:09:40
同じ条件で検索しないと
+developerとか+"source code"とか
0848デフォルトの名無しさん2010/03/05(金) 03:31:52
svkだとスロバキアになるのか
0849デフォルトの名無しさん2010/03/05(金) 05:27:15
>>840
CVSってCVS/pharmacyのことだろ？
0850デフォルトの名無しさん2010/03/05(金) 10:37:40
アメリカじゃあんまりCVSとは言わんよ
0851デフォルトの名無しさん2010/03/05(金) 11:38:14
じゃ何と言ってるんだろう？
0852デフォルトの名無しさん2010/03/05(金) 17:05:55
ちょっとした質問。

現在、Subversionからローカルにチェックアウトしたソースがある状態で、
svnリポジトリが閉じた社内LANにあるなどアクセスできない状態で、
ちょっとだけ外で開発したくなった場合、一時的にローカルで分散バージョン管理など使って管理しつつ、
開発した後、パッチ出力して後でsvn側にマージするようなことってできますか？
ちょっとわかりにくいですが。

本当はbzr+svnなりgit+svnなりで最初にsvnリポジトリから分散バージョン管理ソフトで
持ってこれたらよかったんですが、現地で環境整えられなかったので。
0853デフォルトの名無しさん2010/03/05(金) 17:21:25
>>852
> 現在、Subversionからローカルにチェックアウトしたソースがある状態で、
> svnリポジトリが閉じた社内LANにあるなどアクセスできない状態で、
リポジトリにアクセスできない所へは、どうやって持って行ったの？
逆にアクセスできる所へ(更新したディレクトリツリーを)持って行けば
いいんじゃないの？
0854デフォルトの名無しさん2010/03/05(金) 17:53:20
>>853
ありがとう。
ええっと、現在アクセスできないsvnリポジトリから事前にチェックアウトしたソースがあって、
後でアクセスできる場所へ行ってsvnコミットしたいという話です。

ただ、それだとその場所でしか開発しにくいのでどうしたものかと。
都合により内部には鯖たてるのはいいんですが、外部にsshとか公開できないのです。(将来はわかんないけど)

現在ローカルにあるテスト的なソース郡でgit試してたんですが、
(1)ソース変更→gitでコミット→1から繰り返す→(svnコミットできるLAN内に移動)→(2)過去のバージョンにgit checkout→svnコミット→(2)を繰り返す
というのでいけるかな、と。ちょっと不毛な気がしますが。

gitのコミットごとにパッチ作って、svnでコミットできるようになったら、順にパッチを当てる方法も考えました。
ただgit diffでパッチを出力してみて、古いリビジョンにcheckoutで戻してpatchコマンドでパッチあてたり試してたんですが、
テキストの変更はいいのですが、git mvで変更した場合にうまくパッチあてられないですね・・・うーん。


それはそれとして >>852 の様な根本的な問題解決には将来的には多分以下になるかと思います。
その他にも何かよい方法あったら教えて欲しいです。

・外部にVPSとか立てておいてリポジトリそこにおいてsvn
・git-svnとかbzr-svnでsvnリポジトリのまま分散管理で扱う
・分散管理バージョン管理系に移行(git、bzr等)
・VPNでLANないsvn（とかって外部に鯖公開でない状態でできるのか調べてない・・・）
0855デフォルトの名無しさん2010/03/05(金) 17:58:19
>>854 のgit checkoutで編集中に戻れる状況なら、
途中のパッチ作ってパッチあてる方法って意味ないか・・・。

面倒だからさっさと、分散系の環境整えた方がいいな。
日記見たくなってスマソ。
0856デフォルトの名無しさん2010/03/05(金) 18:41:36
>>854
> gitのコミットごとにパッチ作って、svnでコミットできるようになったら、順にパッチを当てる方法も考えました。
> ただgit diffでパッチを出力してみて、古いリビジョンにcheckoutで戻してpatchコマンドでパッチあてたり試してたんですが、
> テキストの変更はいいのですが、git mvで変更した場合にうまくパッチあてられないですね・・・うーん。
hg でもだめだったのでしょうか?
0857デフォルトの名無しさん2010/03/05(金) 18:54:27
# 作業ブランチでの作業を記録
bzr-svn プラグインをオフにしておく
bzr init
bzr ignore .svn
bzr add .
bzr commit -m "initial import"
あとはbzrで作業。

# bzr の cherrypick merge を使って svn に書き戻し
bzr-svn を有効にしておく
bzr branch http://svnブランチのパス/ work
cd work
bzr merge ../作業ブランチ -r1..-1
bzr dpush http://svnブランチのパス/
0858デフォルトの名無しさん2010/03/05(金) 19:03:58
ローカルのリポジトリにはメモ的に細かくコミットして、
共有リポジトリには大きな粒度でまともなコミットログを付けてコミット。
共有リポジトリ見てる同僚には、ローカルリポジトリでやった間抜けな試行錯誤や
ゴミコメントは見られないようにする。

これをMercurialでやろうとすると案外めんどくさいみたいだね。ややこしい。
こういう作業をやりやすいのは、どのバージョン管理システム？
0859デフォルトの名無しさん2010/03/05(金) 19:15:52
>>858
git で rebase -i とか使ってコミットをまとめたり分割したり。

0860デフォルトの名無しさん2010/03/05(金) 19:20:15
>>854
たまにLANにノート持ち込んでそこからならsvn接続出来る、的な感じ
なんでしょ？
なら次に繋げる時にgit-svnすればオールオッケーだと思う。
それまでの分のコミットはこっちに溜めておいても、git-svn init後にrebaseすれば良い。
0861デフォルトの名無しさん2010/03/05(金) 19:35:22
>>857 >>860
bzr-svn、git-svnて後からリポジトリ作っても既存のsvnに突っ込めるんですね。なにそれすごい・・・
やってみます！

>>856
ごめんhgはちょっと・・・
0862デフォルトの名無しさん2010/03/05(金) 21:02:50
>>852
ローカルにSVNリポジトリ作ってそこで作業して、帰社したらマージすればいいし
0863デフォルトの名無しさん2010/03/05(金) 23:54:03
つかbzr,git,hgどれも集中型連携はググれば出てこないか？
0864デフォルトの名無しさん2010/03/06(土) 05:30:23
>>862
一回しかコミットしないとか、何回のコミットを最終的に一回のマージですます、ならいいんだけどね。
複数のコミットを全部順番にマージしたいとかだと面倒だよね
0865デフォルトの名無しさん2010/03/06(土) 05:31:24
>>863
最初に分散型から集中型リポジトリにアクセスしてとってこないとできないと思ってました・・・。
0866デフォルトの名無しさん2010/03/06(土) 06:44:45
>>861
git svn dcommit を後からやるんならちょっと細工というか工夫が必要だけどね。
いろいろなやり方が考えられるけど、ようはsvnから切り離した時点でのコミットの後に
ローカルなコミットが続くような状態になれば、git-svn-idを見て処理してくれるようになるから、
rebase --ontoとかcherry-pickとか使ってそういうブランチを作って、その状態で
git svn rebase、そしてdcommitする。
てか初回はそういう意味で面倒だから、ローカルなのは１つのコミットにまとめてしまって
やったほうが楽だと思うな。
0867デフォルトの名無しさん2010/03/06(土) 11:24:23
>>865
cherrypick merge は本当のマージじゃなくてパッチを順番に当てていく
イメージだから、 >>857 みたいなことができる。
もちろん、最初から bzr-svn, git-svn, hgsubversion でチェックアウトしておいた
方が良いのは変わらないけど。
0868デフォルトの名無しさん2010/03/06(土) 11:50:20
cygwin gitのgitkってUTF-8のテキストファイルも化け化けなんだがなんでだぜ？
gitのせいなのか、gitkのせいなのか、cygwinのせいなのかどこで聞けばいいかわからん。

git version 1.6.6.1 cygwin 1.7
08698682010/03/06(土) 11:57:25
git config --global gui.encoding utf-8
したら、gitkのdiffは化けなくなった。マルチバイトのファイル名は化け化けだが。これはなんとかならんもんなのかな
0870デフォルトの名無しさん2010/03/06(土) 13:21:01
事務のおねーちゃんが読むExcel本みないなバージョン管理システム本書いてくれよ
「TortoiseSVNでひとりsvn」ぐらいのレベルでさ

いろんなExcelファイルを使ってるから履歴管理させてあげたいんだけど
「リポジトリ」とか、「コミット」とか、説明するのがメンドーなんだよ
0871デフォルトの名無しさん2010/03/06(土) 14:14:13
>>850
http://en.wikipedia.org/wiki/Concurrent_Versions_System
0872デフォルトの名無しさん2010/03/06(土) 15:00:47
>>870
そういうレベルなら、ファイルサーバの共有フォルダに
シャドウコピーの設定をしてるだけで十分な場合が多い。
0873デフォルトの名無しさん2010/03/06(土) 16:37:28
>>870
僕の亀も(ry
0874デフォルトの名無しさん2010/03/06(土) 17:04:25
gitの質問いいでしょうか？

git chekcout HEAD^ した後に、うっかりそこで作業して何度かコミットしまくってしまい、
名無しのブランチ(?)のようなものを作ってしまいました。

変更しているのにgit pushでEverything up-to-dateといわれてようやくこの状態に気づいたのですが、
その後、あわてて、git pullしてgit checkout masterしてしまいました。

名無しのブランチでの作業が、gitkなどで履歴を見てもどこにも見当たらないのですが、
とりだしてmasterにmergeすることってできますでしょうか？
git branchで見てもmasterしか見当たりません。
0875デフォルトの名無しさん2010/03/06(土) 17:25:56
>>870
「できる！Subversion」
全頁フルカラー！豊富な図解で分かりやすい！

みたいな感じ？
0876デフォルトの名無しさん2010/03/06(土) 17:41:13
>>875
フルカラーなはずなんだけど、「TortoiseSVN」ではなくあくまで「Subversion」なので、
ほぼすべてがコンソールのスクリーンショットになってフルカラー涙目な状況。
08778742010/03/06(土) 17:44:25
解決しますた

$ git fsck --lost-found
して表示できないコミットを表示して、表示されたIDを
$ git log (ID)
で新しいか確認して、
$ git merge (ID)
したらmasterにマージいけました。
0878デフォルトの名無しさん2010/03/06(土) 17:48:24
>>876
viの設定がカラーになってるから見栄えはいい
0879デフォルトの名無しさん2010/03/06(土) 17:50:45
>>878
いや、viの時点でもう初心者向けではないだろう・・・
0880デフォルトの名無しさん2010/03/06(土) 17:56:39
git log -gで、以前にHEADだったコミットが見られるから、必要なコミットを探してチェックアウト。
あらためて名前をつけてブランチにするのがいいと思う。
0881デフォルトの名無しさん2010/03/06(土) 17:57:39
解決してましたね。失礼
0882デフォルトの名無しさん2010/03/06(土) 19:11:23
じゃあvimで
入力モードでもカーソルキー使えるぞ
0883デフォルトの名無しさん2010/03/06(土) 19:34:50
nanoじゃだめなの？
0884デフォルトの名無しさん2010/03/06(土) 20:20:08
表紙は萌えキャラsvnちゃん
0885デフォルトの名無しさん2010/03/06(土) 20:28:03
LinuxじゃなくてWindows向けの解説だからviはないだろ
EDLINじゃね？
0886デフォルトの名無しさん2010/03/07(日) 02:25:19
>>870 いっそ、msofficesvn じゃだめ？
ttp://code.google.com/p/msofficesvn/wiki/Introduction_ja
0887デフォルトの名無しさん2010/03/08(月) 13:30:25
gitって名無しブランチを作れるの?
0888デフォルトの名無しさん2010/03/08(月) 23:08:26
>>887
gitにゃ無理だう！
0889デフォルトの名無しさん2010/03/09(火) 00:16:25
むしろgitは名無しブランチの先に旗立ってる特別な奴が名前付きブランチ
0890デフォルトの名無しさん2010/03/09(火) 03:19:21
>>889
1つの名前つきブランチが枝分かれしているという状況はないってことであってる?
hgだと普通に起こり得るけど。
0891デフォルトの名無しさん2010/03/09(火) 07:57:25
>>890
hgはよくわからないんだが、gitは特定のコミットに名前を付けるとブランチだし、
同じ親を持つコミットが複数あれば枝分かれしてるってことになる。シンプルだと思うが。
0892デフォルトの名無しさん2010/03/09(火) 12:42:55
>>890
gitも基本は同じだが、ブランチの名前をつけずにコミットしたら、そのコミッ
トは別のブランチをcheckoutすると見えなくなるから、名無しのブランチに戻
るにはその時のコミットIDを覚えておいて直接checkoutに指定するしかないら
しい。不便なので普通は名前を付けるんだと思う。
08938742010/03/10(水) 14:01:43
>>892
俺がついこの前そんな感じになったよｗ
08948742010/03/11(木) 13:42:32
各分散バージョン管理のかなり詳細な比較記事

InfoQ: 分散バージョン管理システムの詳細なガイド
http://www.infoq.com/jp/articles/dvcs-guide
0895デフォルトの名無しさん2010/03/11(木) 14:35:42
>>894
中身が滅茶苦茶
全く役に立たない
0896デフォルトの名無しさん2010/03/11(木) 15:03:56
>>895
「滅茶苦茶」じゃなくて「ごちゃごちゃ」なだけだろ
ちゃんと読めば役に立つ
0897デフォルトの名無しさん2010/03/11(木) 15:24:10
>>895
どこが間違ってるのかちゃんと書けカス
0898methane2010/03/11(木) 15:38:59
>>897
>>895 じゃないけど、 TortoiseBZR のメンテナをやってます。
去年の1月頃から停滞していたのを、去年の7月頃から私が引き継いだので、現在は
そこらへんの説明無しにTortoiseBZRへのリンクだけ張ってもらえば良い状況ですね。

あと、olieve という GTK系のＧＵIが紹介されていますが、どちらかといえば推奨されて
いるのはQt系のGUIの方で、WindowsにおいてGTKよりも良いルックアンドフィールを
提供しています。
0899methane2010/03/11(木) 15:41:27
Mercurialも、リポジトリフォーマットがNTFS向きじゃないと解説されているけれど、
その後リポジトリフォーマットが変更されたんじゃなかったかな。

良い記事だけど情報が古いので、最新の情報に同じような記事が出ると良いですね。
0900デフォルトの名無しさん2010/03/11(木) 15:53:35
そもそも原文が微妙に古いし(2009/08/19)、評価したバージョンが古すぎ。

> 2008年3月24日にリリースされたMercurial 1.0(Edgy用のIssue 1050パッチを適用)
> 2008年4月8日にリリースされたGit 1.5.5
> 2008年4月10日にリリースされたBazaar 1.3.1
0901デフォルトの名無しさん2010/03/11(木) 16:25:02
tortoiseGitも未リリースだったのか
09028742010/03/11(木) 23:01:12
>>894
TortoiseHgもUI古いバージョンだな
古い比較記事はるな。氏ねよ
09038742010/03/11(木) 23:01:59
あ、あ、、、、、
09048742010/03/11(木) 23:11:27
オッス！オラ874！！
0905デフォルトの名無しさん2010/03/12(金) 22:03:26
>>894 svnについても古くないか？
＞ブランチ間でマージされたリビジョンの追跡を行う必要があります(Subversionにはこのような機能がありません)。
1.5以降でマージ追跡ができるようになってマージが簡単になりました。
＞ファイルやディレクトリの名前が変更されていたら、マージが失敗してしまいます。
普通にできるし

あとの、externals,trunk,branch,tagsとかは好みの問題だろうし。
0906デフォルトの名無しさん2010/03/12(金) 22:49:10
>>894 http://www.infoq.com/jp/articles/dvcs-guide
この記事ダメダメだな。
＞1986年、初めてCVSが使われ、
最初から間違いで始めるなよ、最初は由緒正しきSCCSだろ。

http://ja.wikipedia.org/wiki/Source_Code_Control_System
＞Source Code Control System（SCCS）は、世界初のソースコードバージョン管理システム。
＞1972年、ベル研究所の Marc J. Rochkind が IBM System/370 上の OS/MVT 向けに開発した。
0907デフォルトの名無しさん2010/03/12(金) 23:03:18
SCCSって分散バージョン管理システムだったのか。
0908デフォルトの名無しさん2010/03/12(金) 23:20:42
>>907
該当段落は、分散なしのものから話を始めている。
0909デフォルトの名無しさん2010/03/12(金) 23:28:58
翻訳が駄目だってだけだよ
0910デフォルトの名無しさん2010/03/13(土) 11:39:31
>>905
＞ファイルやディレクトリの名前が変更されていたら、マージが失敗してしまいます。
マジ？
手元のでできないんだがリポジトリ古いせいかな…upgradeするか
0911デフォルトの名無しさん2010/03/13(土) 16:51:11
>>910
http://pc12.2ch.net/test/read.cgi/tech/1254838551/302-
0912デフォルトの名無しさん2010/03/13(土) 18:37:43
>>911
リネームしたほうをAとして、リネーム前に編集したほうをBとしてBをAにマージしたいのか。
もし、うまくいかないのなら、AをBにマージしてBからAにブランチの統合すればよくね？
0913デフォルトの名無しさん2010/03/19(金) 20:20:38
バイナリーファイルも差分で記録してくんないかな
ディスクたりなくなるかもしんないし
0914デフォルトの名無しさん2010/03/19(金) 20:28:10
subversionはバイナリー差分を圧縮してリポジトリに格納する。
0915デフォルトの名無しさん2010/03/19(金) 20:35:00
分散バージョン管理の中でバイナリーの差分とってくれるのは
monotone
だけってことで合ってる?

svnはwordの差分表示するアドオンなんてあるのね
0916デフォルトの名無しさん2010/03/19(金) 21:25:53
winmergeのプラグインにそんなのがあったようななかったような
0917デフォルトの名無しさん2010/03/19(金) 22:29:33
>>915
それは差分表示ソフトの問題であって、
Subversion以降の世代のバージョン管理システムは
バイナリの差分保存はどれもできるはずだ。
0918デフォルトの名無しさん2010/03/20(土) 08:28:26
>>917
そういうことじゃなくて
svnみたいに差分でリポジトリに保存しているって意味では？
hgもgitもbzrも差分では保存してないはずだし
0919デフォルトの名無しさん2010/03/20(土) 08:33:24
他は知らんけどbzrは一応差分。というかリポジトリ内部ではテキストファイルとバイナリファイルを分けてない。
0920デフォルトの名無しさん2010/03/20(土) 09:06:42
bzrは差分だったか、それは失礼した。聞いた情報だけで適当に言ってしまった
0921デフォルトの名無しさん2010/03/20(土) 11:16:12
hgも保存は差分と聞いたけど、バイナリかどうかは知らない。
0922デフォルトの名無しさん2010/03/21(日) 00:42:19
複数の svn リポジトリ間で同期を取る方法って、何か良いの無い？

なんで今の開発環境、svn リポジトリが３本もあるんだろう。
ブランチが３本じゃなくてリポジトリが３本……一体何があったんだろう。
0923デフォルトの名無しさん2010/03/21(日) 01:01:31
>>922
それはSubversionリポジトリの運用概念を理解できてないだけ。
Subversionの世代のリポジトリは、全世界で１個でいい。
git以降の分散系ではまた話が変わってくるだろうが。
0924デフォルトの名無しさん2010/03/21(日) 01:09:48
質問に答えてやれよ
0925デフォルトの名無しさん2010/03/21(日) 01:27:12
リポジトリ自体はSubversionのままで、クライアントをhgに切り替えればいいんじゃね。
ローカルのリポジトリがhgで中央がSubversionなら、適時マージかけて同期していくことは可能。
0926デフォルトの名無しさん2010/03/21(日) 10:15:11
>>922
どういう状況で分かれたのか知らないけど、別のリポジトリのリビジョンの範囲を指定してもマージはできるから、がんばってマージするんだ。
そして運用方法を見直したほうがいいぞ。
0927デフォルトの名無しさん2010/03/22(月) 13:07:48
>>922
一台をマスターにして、それにだけコミットするようにして、残りをスレーブにしてsvnsyncするしかないだろ…。

複数のリポジトリに好き勝手にコミットして同期したいなんて要望はsubversionでは狂気すぎる。
0928デフォルトの名無しさん2010/03/22(月) 14:16:16
>>922
それぞれのレポジトリを別のバージョン管理システムで管理すればおｋ
0929釣られてみる2010/03/22(月) 14:38:14
>>928
それは殆ど無意味。
0930デフォルトの名無しさん2010/03/22(月) 15:12:37
レポジトリ
0931デフォルトの名無しさん2010/03/22(月) 23:30:43
そんなの表記法の違いじゃ
0932デフォルトの名無しさん2010/03/23(火) 00:00:43
realのことレアルって言わないだろ
0933デフォルトの名無しさん2010/03/23(火) 00:04:57
でもmachineをミシンって言ったりするじゃん
0934デフォルトの名無しさん2010/03/23(火) 00:44:55
なに君は江戸時代の感覚を大事にしたいの？
0935デフォルトの名無しさん2010/03/23(火) 00:55:53
>>933>>934勉強になったｗ
0936デフォルトの名無しさん2010/03/23(火) 08:02:38
reportがレポートだったりリポートだったりするからどうでもいいよ。
0937デフォルトの名無しさん2010/03/23(火) 09:02:42
レーベルのラベルにレッテル貼り
0938デフォルトの名無しさん2010/03/23(火) 10:17:06
フォルダだったのがいつの間にかフォルダーになっちまったしな
0939デフォルトの名無しさん2010/03/23(火) 10:22:17
駅でホームをHomeと書いてあるのを見たときは頭を抱えた。
20年くらい前だが。
0940デフォルトの名無しさん2010/03/23(火) 11:29:24
ぷらっとHome という店は実在する
0941デフォルトの名無しさん2010/03/23(火) 11:53:18
アイロンのこともたまには思い出してあげてください
0942デフォルトの名無しさん2010/03/23(火) 12:46:56
HDDのことをハードと略す一般人は心中許せじ
0943デフォルトの名無しさん2010/03/23(火) 12:51:58
雑談する奴も許せないな
0944デフォルトの名無しさん2010/03/23(火) 15:31:02
USBメモリーがUSBだけで通じる電気店
0945デフォルトの名無しさん2010/03/23(火) 16:33:13
そもそも初期の携帯の略称は携電だった
0946デフォルトの名無しさん2010/03/23(火) 21:24:17
レム文
0947デフォルトの名無しさん2010/03/23(火) 21:36:34
レットしようぜ
0948デフォルトの名無しさん2010/03/24(水) 00:51:08
ちゃー
0949デフォルトの名無しさん2010/03/25(木) 03:07:12
$ svn update -r 929 1255241922.dat
$ svn commit -m "dokkaike" 1255241922.dat
0950デフォルトの名無しさん2010/03/25(木) 08:17:29
ヴァーチャー
0951デフォルトの名無しさん2010/03/25(木) 08:26:06
マイコン→パーコン→パソコン→マイコン
0952デフォルトの名無しさん2010/03/25(木) 08:27:04
ガラパゴスケータイをガラケーと略(ry
0953デフォルトの名無しさん2010/03/27(土) 21:18:15
コンフリクトの自動解消を一番賢くしてくれるのはどれ？
0954デフォルトの名無しさん2010/03/27(土) 22:49:51
コンフリクトを自動で解決してくれるのなんてあったか？
0955デフォルトの名無しさん2010/03/27(土) 22:55:27
そもそもマージ(自動)を捌ききれなかったのがコンフリクトでしょ。

で、コンフリクト解決ツールがいちばん充実してるのは…Tortoiseだったりしてw
0956デフォルトの名無しさん2010/03/28(日) 11:29:01
じゃあ自動マージが一番賢いのはどれ？
0957デフォルトの名無しさん2010/03/28(日) 13:24:22
バカなマージってあるか？
うまくいかないのは、大抵が利用者の理解不足によるミスだが。
0958デフォルトの名無しさん2010/03/28(日) 13:47:31
patchコマンドの不出来によるんじゃないの？
0959デフォルトの名無しさん2010/04/03(土) 00:40:07
リポジトリって1個でよかったのか

トータスSVNの右クリックに「ここにリポジトリ作成」みたいなのがあるから、きがるにプロジェクトごとに作るのかと思ってしまった

複数あると何か問題でもあるの？
個人でローカルで使ってるとそれをzipで固めて保存とかできるから便利かなと思ったけど。
0960デフォルトの名無しさん2010/04/03(土) 00:56:44
>>959
言っておくが、一プロジェクトに一つでいい、ってことだぞ
わかってるな
わかってるよな
0961デフォルトの名無しさん2010/04/03(土) 01:00:48
>>959
それであってると思うよ

>>922は、ひとつのプロジェクトで中央リポジトリがいくつもある、って状態
これはどうしようもない状態
0962デフォルトの名無しさん2010/04/03(土) 01:14:48
>>960
>>961
あ、1プロジェクトに1リポジトリで合ってたのね。良かった
1リポジトリに全プロジェクトに入れるのかと読み間違えた。レスありがとう

ついでに質問だけど、svnってtddな開発スタイルと相性悪いのかな？(頻繁にコミット) tddにもっとも適したバージョン管理ってどれだとおもう？
0963デフォルトの名無しさん2010/04/03(土) 01:31:56
TDD ＝ 頻繁なコミットってのもどうかと思うが、そう使いたいなら
ローカルコミット（＋あとでその部分を無視）できるシステムが必須だろうね。
分散型ならどれもそう変わらんのでは？
0964デフォルトの名無しさん2010/04/03(土) 11:09:15
>>962
1リポジトリに全プロジェクトを入れるのもアリ。

この場合、各プロジェクトはリポジトリの単なるサブディレクトリ。
/reporoot/project1/trunk, branches, tags
/reporoot/project2/trunk, branches, tags
のようになる。

管理は楽なんだろうけど、リビジョン番号がプロジェクトごとに独立せず、
同一リポジトリ内での通し番号になるのが好かん。
0965デフォルトの名無しさん2010/04/03(土) 13:02:57
>>964
> >>962
> 1リポジトリに全プロジェクトを入れるのもアリ。
>
> この場合、各プロジェクトはリポジトリの単なるサブディレクトリ。
> /reporoot/project1/trunk, branches, tags
> /reporoot/project2/trunk, branches, tags
> のようになる。

ああ、そうか、１リポジトリでまとめる場合各project(サブディレクトリ)毎にtrunk, branches, tagsを持たせればいいのか。

/reporoot/trunk/project1
/reporoot/trunk/project2

ってtrunk(branches, tags)の下にproject**を置いてた

>
> 管理は楽なんだろうけど、リビジョン番号がプロジェクトごとに独立せず、
> 同一リポジトリ内での通し番号になるのが好かん。
>

そうね、TortoiseSVNでリビジョングラフが変になるのが嫌いだ
0966デフォルトの名無しさん2010/04/04(日) 09:45:43
>>961
> >>922は、ひとつのプロジェクトで中央リポジトリがいくつもある、って状態
> これはどうしようもない状態

これをどうにかできるようにしたものが分散型って理解でいいのかな
中央リポジトリでの一元管理って、なんだかんだ言ってかなり有用だよな
0967デフォルトの名無しさん2010/04/04(日) 18:14:19
>>966
違うよ。全然違うよ。
0968デフォルトの名無しさん2010/04/06(火) 14:28:30
今年度は申請書(EXCELシート)書いて上司の判子もらわないと
svn commit すらできない職場で仕事することになりました。
ttp://d.hatena.ne.jp/SiroKuro/20100405/1270460603
0969デフォルトの名無しさん2010/04/06(火) 15:25:51
富士通のとある大規模システムやってたときがそんな感じだった。
しかもメディアはMOで、数台～十数台のPCに一個しかないので、MOに落とすの待ちやったあとに
ライブラリアンの前で行列みたいな感じだった。テスト中は地獄。
0970デフォルトの名無しさん2010/04/06(火) 15:29:44
それって何のメリットがあるの?
0971デフォルトの名無しさん2010/04/06(火) 18:14:57
いつのまにか動かないリポジトリにならない
0972デフォルトの名無しさん2010/04/06(火) 20:12:10
レポジトリを破壊する奴を全員放り出した方が生産性が上がる気がする
0973デフォルトの名無しさん2010/04/07(水) 06:47:04
そのあたり、subversionは使用経験が浅くてよくわからんのだけど、
CVS なら、

1.各人が勝手にコミット
2.ある時点でテスト担当がチェックアウトしてテスト実施
2-1.テストが失敗したら、当該ユニットの担当者に連絡
2-2.当該ユニットの担当者が修正してコミット
2-3. 2に戻る
3.テスト成功した時点で所定のタグを打つ
4. 1に戻って全体が完成するまで繰り返し。

みたいなことやってれば、「動かないリポジトリ」にはならないじゃん。
最悪、直前のバージョンタグ（ベースライン）まで戻ればいい。
そういう管理って subversion ではできないの？
0974デフォルトの名無しさん2010/04/07(水) 08:05:56
subversionは、branchesに分岐、修正、テスト、trunkにマージで問題なく安全なtrunkをリポジトリに作れるし。
0975デフォルトの名無しさん2010/04/07(水) 08:16:11
いつの間にか壊すような奴は何も考えずにtrunkにコミットコミットコミット！
0976デフォルトの名無しさん2010/04/07(水) 08:59:47
>>971 は運用が適当なだけなので本気にしてはいけない。
本当のメリットは、上司用の仕事を作れること。
0977デフォルトの名無しさん2010/04/07(水) 09:09:30
>>975
そのあたりはアクセス管理でなんとかならないの？

>>974
そのやり方だと、trunk の内容がテスト済みに保たれるだけだよね？
「ある時点のテスト済みプロジェクト全体」を取り出すにはどうすればいいの？
例えば、リリースファイルをビルド番号で管理していた場合に、
何世代か前のビルドに対応するプロジェクトのファイルのセットを取り出すみたいな。
0978デフォルトの名無しさん2010/04/07(水) 09:15:51
>>977
> そのやり方だと、trunk の内容がテスト済みに保たれるだけだよね？
trunkにテスト済みが保たれてればいつでもテスト済みプロジェクト全体が取り出せるやん。
0979デフォルトの名無しさん2010/04/07(水) 10:03:13
>>978
いや、だから、それは「最新の」テスト済みプロジェクト全体だけじゃないの？
以前のビルドに使ったプロジェクトのセットはどうやって識別するの？
0980デフォルトの名無しさん2010/04/07(水) 10:19:47
tags使えやタコ
0981デフォルトの名無しさん2010/04/07(水) 10:46:35
>>979
> リリースファイルをビルド番号で管理していた場合
だろ？
そこまで細かいことやってるんなら、その直近のtrunk出しておｋ、じゃないのか？
もしかして頭固い？
0982デフォルトの名無しさん2010/04/07(水) 10:49:49
そのあたりが subversuon はよくわからないんだな。

CVS　なら、「そういときはタグを打て」と言われたとき、
コマンドのリファレンスを調べれば、
大体該当する機能があってどうすればいいかはわかるんだけど、
subversion の場合、マニュアルを見てもそういう機能は見当たらないのに、
みんなあたりまえのように　trunk とか branches　とか、tags とかを
使う話をしてる。
例えば、tags を使えと言われて　svn コマンドのリファレンスを調べるんだけど、
それに対応するコマンドなりオプションなりは、 まったく見当たらない。
0983デフォルトの名無しさん2010/04/07(水) 10:54:03
>>979
もしかして>>979はバージョン管理システムの基本がわかってないんじゃなかろうか
過去の履歴は「全て」残ってるのが大前提のシステムだぜ？
「最新の」ものしか出てこないバージョン管理システムってあると思う？
# ひょっとしてCVSがそうなのか？

「ビルドの識別」には、それこそtags利用なりリビジョン番号のメモを取るなりすればいい
それは運用だけど、それが「できない」ものはVCSの名に値しないよ
0984デフォルトの名無しさん2010/04/07(水) 10:59:00
大規模システムってプログラマが数百人いて、各人が勝手にコミットとかしたら大変なことになる。
0985デフォルトの名無しさん2010/04/07(水) 11:01:01
>>981
「直近」という言葉の意味がよくわからない。
なぜ、「そのビルドをビルドした時点」ではダメなの？

例えば、CVS の場合、 ビルド100 を作るときに、
「B100」とタグを打って、「B100」でチェックアウトしてビルドしてテストしてリリースすれば、
そのあと、ビルドが200になろうが、300 になろうが、「B100」でチェックアウトすれば、
ビルド100をビルドした時点のファイルのセットが得られるよね？
これと同じことは subversion ではできないの？
「直近」というのは、どういうファイルを取り出すことを言っているの？
0986デフォルトの名無しさん2010/04/07(水) 11:10:44
>>985
直近は曖昧だったか。ダメじゃないよ。
その「ファイル」をコミットした時点でのビルド、っていう基点がわかってるなら、
それこそそのファイルをコミットしたリビジョン番号が、すなわちあんたのいうB100だ。
(ex. rev.9893、とかな)
リビジョン番号はファイルについているのではなく、リポジトリ（≒プロジェクト）全体での通し番号。

んで、それではわかりにくいので、慣習的にtagsっていうディレクトリをtrunkと同階層に掘って、
そこに「コピー」を作る。
このコピーは結局trunkのディレクトリのコピーなので、好きな名前を付けられる。B100でも何でも。
また、いくつでも好きなときに作れる。これがSubversionで言うところの tags
0987デフォルトの名無しさん2010/04/07(水) 11:22:52
>>986
なるほど、trunk とか tags ってのは慣習的に「そうやってる」って話なんだ。
リファレンス調べてもわからないはずだ。
それでわかりました、ありがとう。
0988デフォルトの名無しさん2010/04/07(水) 11:35:39
そのあたり、わかりやすく書いた半公式サイトがあったような気がしたが、今探したら見つからないな。
やっぱり流行ると、なんつったっけ、ゴミサイト率が上がるな
0989デフォルトの名無しさん2010/04/07(水) 12:24:38
>>988
TortoiseSVNのヘルプじゃね
0990デフォルトの名無しさん2010/04/07(水) 12:59:50
>>987
まあ逆に考えるんだ
SVNなら、リビジョン番号さえわかれば、タグがついてなくてもいつでも
全ファイルセットを取り出せると考えるんだ

タグがコピーって言ったって、別に全てのファイルをコピーしてるわけじゃないし
コミットさえ無ければ（恐ろしいことにこれは可能だが）、純粋にリビジョン番号を
保持しているだけみたいなもんだし。
0991デフォルトの名無しさん2010/04/07(水) 15:20:12
>>987
そうそう。
trunk、branches、tagsっていう名前を作るといいかもね
っていう感じ
0992デフォルトの名無しさん2010/04/07(水) 15:31:19
え？trunk、branches、tagsってSubversionのマニュアルに載ってないの？
「慣習として使っている」みたいな記述もなし？
0993デフォルトの名無しさん2010/04/07(水) 15:43:22
>>988
上平哲が訳して公開してたやつだと思うけど見つからない。
今は別の人が公開してるみたい。
www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork
0994デフォルトの名無しさん2010/04/07(水) 17:18:06
まあ未訳が多いからTortoiseSVNのほう見たほうがいいかもね
0995デフォルトの名無しさん2010/04/07(水) 18:26:13
「お約束」位のノリ
0996デフォルトの名無しさん2010/04/07(水) 19:43:37
>>992
あったよ。
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.planning.html#ftn.id494504
0997デフォルトの名無しさん2010/04/07(水) 19:54:10
projectname/trunkのタグをprojectname/tagsに入れるのは違和感ないんだが、
projectname/branchesのタグをprojectname/tagsに入れるのは違和感が有る。
かといって、projectname/branches/tagsを作るのもなぁという感じ。
どうやってる？
0998デフォルトの名無しさん2010/04/07(水) 20:00:29
↓次スレ
0999デフォルトの名無しさん2010/04/07(水) 20:09:59
つーか埋め立てるぞｺﾞﾙｧ
VSSで決まりだろｱﾌｫﾝﾀﾞﾗｰ
1000デフォルトの名無しさん2010/04/07(水) 20:50:10
1000ならVSS滅亡
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。