[過去ﾛｸﾞ] バージョン管理システムについて語るスレ3 (1001ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
848(1): 2009/04/28(火)13:14 AAS
レスでまとめ作ると後で探すの面倒だから、
適当なwikiのページ借りてまとめ作ったらどうだろうか？
849(1): 2009/04/28(火)13:15 AAS
誰かatwikiで借りてきてください
850(1): 2009/04/28(火)13:24 AAS
当然、Wikipediaへの転載は禁止、と
851: 2009/04/28(火)13:39 AAS
>>850
http://www5a.biglobe.ne.jp/~shinotan/miru.JPG
852(1): 2009/04/28(火)14:23 AAS
>>794
darcsは？
windowsで動くdarcsのバイナリがみつかんない
自分でコンパイルなんてしてらんないんだけど
853: 2009/04/28(火)14:37 AAS
>>852
hg, git, bzr と違って人気ないじゃん。
俺はこの3つですら使いこなせてないから、もうこれ以上増やさないでくれ。
854: 2009/04/28(火)14:40 AAS
ブラウザの話題でもいるよね、こういう「俺が使えるもの以外は淘汰されろ」って奴。
855(2): 2009/04/28(火)14:44 AAS
>>838
http://q.hatena.ne.jp/1237792736
CVS強すぎｗｗ
856(1): 2009/04/28(火)14:46 AAS
>855
RCSとか、もう化石になってると思ったのに。
857: 2009/04/28(火)14:50 AAS
うちは今CVSからsvnに移行中だ
全員一斉に切り替えなきゃならんからめんどい・・・
858: 2009/04/28(火)15:05 AAS
darcsの利点
http://www.jmuk.org/diary/2007/12/01/0
859: 2009/04/28(火)15:05 AAS
>>856
はてなにはポイント乞食がいるので最初の選択肢と最後の選択肢は信用できない。
わけもわからずに最初(または最後)の選択肢を選んで投票するバカをうまく排除しないと
有意な結果が得られない。
860: 2009/04/28(火)15:11 AAS
>>855
CVSは過去の資産（リポジトリ）がたくさん残っているのだと思う。
自分はdump, restore, dumpfilterのおかげでメインはSubversionを使ってる。
リポジトリをメンテナンスできるのは強い。
最近はSubversionでチェックアウトして手元ではMercurialで管理してる。
.svnと.hgが同じディレクトリに仲良く共存してるｗ
861: 2009/04/28(火)15:50 AAS
仲が良いかは些か疑問だが。
862(1): 2009/04/28(火)16:59 AAS
>>794
多ブランチがなにをいいたいのかさっぱりわからんのだが
ひとつのリポジトリに複数の関連のないプロジェクトをいれられるかどうかという話なら git でもできる
mkdir project; cd project; git init; echo pu > 1.txt; git add 1.txt; git commit -m '1'; cd ..
mkdir another; cd another; git init; echo pe > 2.txt; git add 2.txt; git commit -m '2'; cd ..
cd project; git remote add another ../another; git remote update; git checkout another another/master;
git remote rm another; cd ..; rm -rf another
こうしとけば project のリポジトリに master と another のまったく別のプロジェクトが同居してる状態になる
あとは git checkout でいくらでも移動できる
git remote つかわなくてもできそうだな...
863: 2009/04/28(火)17:00 AAS
おっと git checkout の際に -b が必要だな
864(1): 794 2009/04/28(火)17:59 AAS
>>862
repos/
+proj1/
| + trunk/
| + branches/
| | + maint/
+ proj2/
こんな感じで、リポジトリの中にサブディレクトリを作ってサブプロジェクトや
ブランチを放り込む方式をsvnではよく使うじゃん。それのこと。
changesetはbranchじゃなくてrepositoryで管理するから、同一repository内の
別のbranchに同一のchangesetをpushしたらきちんと同一部分が検出されて、
pushの転送量やサーバーのHDD使用量を節約できる。
言い方がまずかったと >>820 で反省して、 >>822 では削除したからもう許して。
865(1): 2009/04/28(火)19:43 AAS
>>864
できるできないという視点でいったら、
そういう運用できない管理システムなんてないのでは？
もちろん効率や使い勝手などを鑑みれば
現実的でない運用になるシステムもあるだろうけど。
そもそも、少なくとも分散VCSなら、
そういう運用をする必要性が感じられない。
Subversionは、その方法でしかブランチができないというだけで、
そこに合わせる必要性はないと思うけども。
866(1): 794 2009/04/28(火)21:25 AAS
>>865
うん、そうだね。大して重要じゃないよね。
clone リモート/abranch ローカル
ローカル作業
clone ローカル リモート/newbranch (転送はローカル作業分だけ)
ってするだけでnewbranchが自動でabranchと関連づけられるとか、
Tracで特別な設定なしで複数サブプロジェクトを管理できるかとか、
そーゆーこと考えてたんだけど、どうでも良いよね。
>>822 では削除したからもう許して。
867(1): 2009/04/28(火)21:51 AAS
仮にディレクトリ＝ブランチの運用したとして、
そういう操作ができてしまうのは危険な気がするけど・・・
hgしか使ったことないけど、たぶんどの分散VCSでも、
トランザクションと、トランザクションの転送は分けて考えてるよね。
Tracについては、複数リポジトリの対応待ちだな。
上下前次1-新書関写板覧索設栞歴
あと 134 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.010s