バージョン管理システムについて語るスレ2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2008/07/08(火) 21:38:48関連スレ
CVS 1.3 [UNIX板]
http://pc11.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://pc11.2ch.net/test/read.cgi/tech/1113141518/
Subversion r9 [プログラム板]
http://pc11.2ch.net/test/read.cgi/tech/1202086238/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
git スレッド [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1197798039/
前スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
0002デフォルトの名無しさん
2008/07/08(火) 21:40:35http://www.selenic.com/mercurial/wiki/
darcs
http://www.darcs.net/
git
http://git.or.cz/
Bazaar
http://bazaar-vcs.org/
GNU arch
http://www.gnu.org/software/gnu-arch/index.html
0003デフォルトの名無しさん
2008/07/09(水) 08:20:520004デフォルトの名無しさん
2008/07/09(水) 19:44:13archはもう開発されてないらしいから、代わりにmonotoneを入れてはどうだろうか。
前スレではあんまり話題になってなかったけど。
あと、CVSやSVNも>>2に含めていいんでない？
0005デフォルトの名無しさん
2008/07/09(水) 20:52:510006デフォルトの名無しさん
2008/07/09(水) 21:55:340007デフォルトの名無しさん
2008/07/10(木) 00:06:530008デフォルトの名無しさん
2008/07/10(木) 17:05:12http://ximbiot.com/cvs/cvshome/
Subversion
http://subversion.tigris.org/
monotone
http://www.monotone.ca/
Visual SourceSafe
http://www.microsoft.com/japan/msdn/ssafe/
0009デフォルトの名無しさん
2008/07/10(木) 19:30:290010デフォルトの名無しさん
2008/07/11(金) 14:49:03気がついたら分散型マンセーなのか
0011デフォルトの名無しさん
2008/07/11(金) 15:42:152年前だとちょうどこれから普及するの確定といった感じだったかな
2年位前の状況に似てるかもしれないけど
Subversionと違って分散型はこれできまりというのがないから普及しないかも
Mercurialは使っていて楽だと思ったけど
プラットフォーム依存しちゃうのがなんとかならないのかな
WindowsでMS932、LinuxでUTF8、EUCというデフォルトエンコーディングの違いがつらい
分散だと特に各自のプラットフォームが統一されないほうが自然だし
Subversionのようにソースもリソースもドキュメントも何でもかんでもつっこむという考え方はやめたほうがいいかな
0012デフォルトの名無しさん
2008/07/11(金) 22:37:440013デフォルトの名無しさん
2008/07/11(金) 22:46:49デフォルトエンコーディングってのは、ログメッセージのこと？
よく分からないが、Gitはそのまんま入ってるような気がする。
いっしょに使う人たちが決めればいいんじゃないのかな？
0014デフォルトの名無しさん
2008/07/11(金) 23:40:27NTはOS内部では積極的にUTF16つかってたけど 表面的にはずっとSJISだよ
0015デフォルトの名無しさん
2008/07/12(土) 01:26:45Windowsの入出力インタフェースは各国の糞ローカルエンコーディングに
ほぼ固定されてるようなもので、そんなに運用で融通が利くものではないよ。
UTF-8に統一とか、今更無理ですからｗ
糞デフォルトエンコーディングと内部的なワイドキャラクタセットとの
変換APIだけは完備されてるから、デフォルトエンコードを使う限り、
Windows上のツールは意識してエンコーディング設定とかしなくても
トラブル無く動くようになってることが多い。
だからそれに合わせてるSubversionみたいな態度は正しいと思う。
このあたりはMercurialの中の人も追従して欲しいものだが･･･
0016デフォルトの名無しさん
2008/07/12(土) 01:33:30思ってたけど、違うんかいな
0017デフォルトの名無しさん
2008/07/12(土) 01:49:49そういえばSubversionはロケールに合わせて変換して表示してくれるね。
みんなでUTF-8で書きましょう、てことにすればOKのような気もするが、
フロントエンドで対応するのもそう難しくはないだろうから、そのうちどうにかなるんじゃないかな。
0018デフォルトの名無しさん
2008/07/12(土) 02:29:490019デフォルトの名無しさん
2008/07/12(土) 05:29:470020デフォルトの名無しさん
2008/07/12(土) 11:54:310021デフォルトの名無しさん
2008/07/12(土) 13:11:410022デフォルトの名無しさん
2008/07/12(土) 13:42:34002320
2008/07/12(土) 14:06:510024デフォルトの名無しさん
2008/07/12(土) 16:16:37Mercurialは今日び(ry なことが結構ある気がする
ので気に入らない・・・
0025デフォルトの名無しさん
2008/07/12(土) 16:35:35> Subversionのようにソースもリソースもドキュメントも何でもかんでもつっこむという考え方はやめたほうがいいかな
何となく Word とか Excel のバイナリファイル突っ込んでもうれしくなさそうなイメージ
Mercurial は
0026デフォルトの名無しさん
2008/07/12(土) 20:31:540027デフォルトの名無しさん
2008/07/13(日) 03:47:54ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html
を読んでいるんですが、最初からわかりませんでした。
引用：
> git はファイル集合の履歴を格納するツールとして非常によく考えられたツールです。
> git は履歴を圧縮した集合として格納し、プロジェクトの内容を相互に関連した
> スナップショットとして格納します。
> git ではこれらのバージョンを コミット と呼びます。
> それらのスナップショットは必ずしもすべてが古いものから最新のものに単線で
> 並んでいるとは限りません；その代り、開発ラインが並行して進むことがあります
> (これは ブランチ といいます)。ブランチは分岐し統合されます。
ここで質問なんですが、Gitでいうコミットとスナップショットとは何をさすんでしょうか。
この文章からでは分かりませんでした。
0028デフォルトの名無しさん
2008/07/13(日) 09:17:33スナップショットはgit commitしたときに保存されるファイル・ディレクトリの内容
コミットはそれに対するポインタとコミットログとその他の付加情報をまとめたもの
0029デフォルトの名無しさん
2008/07/13(日) 14:42:50ありがとうございます。
スナップショットは、changesetとは別物でしょうか。
ここで、changesetはファイルの差分の集合です(この説明であってますよね?)。
0030デフォルトの名無しさん
2008/07/13(日) 17:16:42hgは差分じゃないとやだ、ってことでフォークしたんじゃなかったっけか。
0031デフォルトの名無しさん
2008/07/14(月) 11:11:20公式ドキュメントだったかでは、意味がないと言い切ってるし。
0032デフォルトの名無しさん
2008/07/14(月) 13:38:49ttp://gihyo.jp/dev/feature/01/mercurial/0006
ここでちょうどブランチが出てきてるけど、ブランチとトランク(？)を
行き来するよりもう一つ独自修正用の clone 作っとけば済む話だと思うんだけどねー。
わからん。
0033デフォルトの名無しさん
2008/07/14(月) 14:22:46ディスク容量を抑えられる
0034デフォルトの名無しさん
2008/07/14(月) 16:20:50なるへそ。
しばらくいじってたらちょっとした発見。
小さな複数のプロジェクトをまとめて一つのリポジトリで管理する場合
clone するよりも有効かもしれない。
0035デフォルトの名無しさん
2008/07/14(月) 16:37:24Gitの場合は最近はデフォでハードリンクするようになってる。
0036デフォルトの名無しさん
2008/07/14(月) 18:17:21聞きたかったのは、hgでサーバ上に中央リポジトリを用意して共同開発をする場合に
複数のバージョンを平行開発する場合は、中央リポジトリを平行開発の分だけ
用意(clone)しないといけないのかってことなんだが。
branchを使えば1つのリポジトリ内でも分岐を作れるのね。
003729
2008/07/15(火) 01:46:45ありがとうございます。
Gitは、ファイルをまるごと保存しているということでしょうか。
ということは、Gitはchangesetは保存しておらず、差分はスナップショットから計算するということでしょうか。
たしかに .git/objects 以下にそれらしいのがあるんですが、これは差分じゃなくてファイルそのままということでしょうか。
0038デフォルトの名無しさん
2008/07/15(火) 06:43:570039デフォルトの名無しさん
2008/07/15(火) 08:33:44ロバスト、堅牢性だな。
コミットの影響範囲を小さくし、ファイルシステムが不安定だったとしてもレポジトリ全体の破綻を食い止める。
0040デフォルトの名無しさん
2008/07/15(火) 08:42:47共通(基本)部分はどうやって管理するつもり？
0041デフォルトの名無しさん
2008/07/15(火) 09:42:45ファイルそのまま。
ただしファイルの件が増えるとパフォーマンスの面で問題が出るらしく、
packフォーマットという形式も採用されている。これは差分というよりいくつかのコミットを
１つのファイルにまとめて圧縮しているみたい。違ってたらすまん。
詳細はこのへん。
http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/technical/pack-format.txt;hb=HEAD
0042デフォルトの名無しさん
2008/07/16(水) 12:34:54SSH_ORIGINAL_COMMAND を hg で始まるか調べて実行するスクリプト
書くしかないでしょうかね。
0043デフォルトの名無しさん
2008/07/16(水) 13:02:02GitでホスティングするのにGitosisってのがあるんだけど、
これPythonなので、hgにも応用はしやすい気がする。
004442
2008/07/16(水) 13:15:31Mercurial のキー認証を使ってのアクセスでコマンドを hg に限定したい場合、
↓
SSHのキー認証を使ってのリモートアクセスで、コマンドを hg に限定したい場合、
ですね。
Git も Python も興味なっそんぐだなぁ…。それだったらシェルスクリプトでも書くかなあ。
0045デフォルトの名無しさん
2008/07/17(木) 01:35:45ローカルリポジトリで作業中は、ちょっと修正したらガンガンコミット。
ひと段落着いて、ビルド通って、テスト通って、ドキュメントの整合取ったら、
作業開始から完了までのpatchを取る。
んで、中央リポジトリからpullして、tipをそっちに移して、patchを当てて、
まじめなコメントとともにcommit+push。
そーすると、手元でやった粒度が細かすぎるログを中央に送らずに済む。
0046デフォルトの名無しさん
2008/07/17(木) 02:31:18リポジト作らなくてもいいし
ちょっと別名コピーして取っとく代わりに
004743
2008/07/17(木) 03:15:39説明が足りなかったかも知れない。
GitosisもSSH_ORIGINAL_COMMANDでSSH経由でgitコマンドしか実行できないようにする、
というやり方をしているので、参考になるかもしれない、ということです。
hgと同じPythonだしね。
まあシェルスクリプトで自作しても同じような感じにはなると思うけども。
004844
2008/07/17(木) 04:26:36いや、ちゃんとそのニュアンスで伝わっておりましたよ。
Git も Python も興味なっそんぐなんで、取ってきてまで見る気しない
ということで…。
0049デフォルトの名無しさん
2008/07/17(木) 11:21:13hg専用のSSHアカウントつくってauthorized_keysのcommand=で制限すれば
いいんちゃうの？
hg-ssh使って。
0050デフォルトの名無しさん
2008/07/18(金) 00:42:24hgってpushするときに送るチェンジセットを選べない（だよね？）から、ローカルで開発しているデレクトリ以外にマスタから
pullしてパッチあてて、ci+pushするだよね？
0051デフォルトの名無しさん
2008/07/19(土) 01:45:540052デフォルトの名無しさん
2008/07/19(土) 04:35:07たとえばファームなんかは一つのプロジェクトは小さいから、チップ単位で
カテゴリ(＝リポジトリ)とするのはそんなに不自然なことじゃないと思う。
細かい単位で別けないのは、 status 見るのが面倒になるから(Tortoise Hg 使用前提)。
そこで一つのプロジェクトで分岐したいとき、ブランチの出番じゃないかとなるわけだけど、
皆さんはどういう管理をしてるのかな。
0053デフォルトの名無しさん
2008/07/22(火) 09:11:00…と思ったら、カウント増えねーな。なんだよ。
さて、入れてみようかね。
0054デフォルトの名無しさん
2008/07/22(火) 11:23:230055デフォルトの名無しさん
2008/07/22(火) 18:15:54どうやったらできるの？
0056デフォルトの名無しさん
2008/07/22(火) 22:55:37style
0057デフォルトの名無しさん
2008/07/24(木) 16:13:56あと誰か彼等にcursesの存在を教えてやってください。Windowsじゃカラー表示できないよ。
あと5年くらいはSubversionかな……。
0058デフォルトの名無しさん
2008/07/25(金) 15:56:56Tortoise シリーズにそれは許されないんだろうな。
まあまだ 0.4 未満だしな。
0059デフォルトの名無しさん
2008/07/26(土) 01:56:25レポジトリが大きくなってしまったので、サブディレクトリ毎に
レポジトリを分割したいのですが。履歴も引き継ぎたい。
ぱっとググってみたけどそれらしいのは見つからず。
0060デフォルトの名無しさん
2008/07/28(月) 10:35:50まだ現状では細かいプロジェクトを効率よく管理する方法はみたことないし、思いつかないねえ。
履歴を残す必要があるなら、clone して、不要なディレクトリ消していく、ぐらい？
この辺、CVS はツリーの好きなところから取ってこれるし、modules ファイルを駆使すれば
ある程度好きなように組み合わせられる。気軽に update -d ができなくなるけど。
これがあるから、なかなか CVS 捨てられないんだよね。
簡単に CVS 捨ててしまう人は modules ファイル使ってないんじゃないの？
006159
2008/07/28(月) 21:23:14やはりなさそうですか。clone&削除では不要な履歴が残って
気持ち悪そうです。
SVNから移行しようかと使い始めてみましたが、それなりに
痒い所に手が届かない所が見えてきてちょっとガッカリ。
0062デフォルトの名無しさん
2008/07/30(水) 12:30:12initial pullが遅すぎるっていう弱点はあるけど、
使い方分かりやすいし署名もできるのに。
0063デフォルトの名無しさん
2008/07/30(水) 16:46:41他の物より優れてる点を挙げろ
0064デフォルトの名無しさん
2008/07/31(木) 00:24:360065デフォルトの名無しさん
2008/07/31(木) 01:20:36リポジトリがすぐに壊れる
0066デフォルトの名無しさん
2008/07/31(木) 09:21:44それは SQLite使ってるから?
monotoneは最初のpullがとんでもなく遅いという弱点があって、
それを避けるためにpidgin はデータベースを配布してる。
そこで単一ファイルの SQLiteが便利ってことかもしれない。
0067デフォルトの名無しさん
2008/07/31(木) 09:55:33SQLiteのDBってそんなに弱かったっけ？
今は日本語のファイル名をみつけた瞬間エラーになってくれるのにちょっと困ってる
0068デフォルトの名無しさん
2008/07/31(木) 10:01:02例えば、commit, checkoutあたりは名前が違っても、どんなVCSにも同じ働きのコマンドがあるだろうし、
VCSを使ったアプリケーションで共通規格を基準に作れば、企画に沿ったVCSであれば
どんなソフトでも使えて便利だと思うんだけど・・・。
もしかして、海外でだれかやってるかな？
0069デフォルトの名無しさん
2008/07/31(木) 10:20:40逆にユーザインタフェースはどうでもいいから、コミットオブジェクトとマージポイントの
互換性が取れるようになって欲しいな。
git使ってるんだが、Subversionとやり取りすると疲れる…。
0070デフォルトの名無しさん
2008/07/31(木) 11:17:30EmacsやEclipseは一応複数のバージョン管理システムに対して
統一的な操作を提供しようとしてる
0071デフォルトの名無しさん
2008/07/31(木) 21:16:12そう言う UI 作ればいいだけなんだろうけど、そもそも複数のバージョン
管理システムを併用することってあまり無いと思うが。
0072デフォルトの名無しさん
2008/08/02(土) 01:47:02仕事を外部に丸投げしたら/しようとしたら、違うシステム使ってた場合とか。
0073デフォルトの名無しさん
2008/08/02(土) 09:43:52納入してもらうからバージョン管理システムなんか関係ないだろ。
逆に派遣とかで色々な職場を渡り歩くような状況だとありうるのかもしれ
ないけど、その場合バージョン管理システムなんかより開発環境の差異の
方が大きそうだし。
そもそも、バージョン管理システムで日常的に使うのは「チェックアウト」
「チェックイン」「状態表示」「差分表示」「ログ表示」ぐらいだろうから、
ちょっと使ってりゃ覚えると思うが。
0074デフォルトの名無しさん
2008/08/02(土) 12:28:19うちはシステム部分だけで、デザインなんかは別の会社がやるから、
元請けのsvn介してやり取りしてるな。メールうざいし。
文言変更だとかはテスト部隊がやるし、設計関係のドキュメントも別の会社の人が
アップデートするから、中央リポジトリが無いとやってられない。
完成したコードを納品ってのは、１０年前はよくやったけど（その前に実機で試験しに
ソース持って出かけてったり）、最近はそんな悠長なシステムはやってないな。
>>71
人によってはSubversionが一番使い慣れてるとか、hgが良いとか、Gitが好きとか、
いろいろあると思うが、ようはそれらの間ですっきりマージさえできれば、
誰が何を使ってやってようが問題ないわけで、、、どうにかなって欲しいなぁ。
0075デフォルトの名無しさん
2008/08/02(土) 13:00:14特にプレステとかサターンの案件だと
自分の周りだけかもしれんが
0076デフォルトの名無しさん
2008/08/02(土) 13:43:32それは、作業外注みたいなイメージで >>73 の派遣みたいな感じだろ。
悠長な仕事かどうかより 10年前よりお前さんの会社の立場が弱くなっ
てるだけだと思う。
0077デフォルトの名無しさん
2008/08/02(土) 14:52:02システム部分しかやりたくないし、開発に専念したいから、自社で作って、
リモートでコミットして納品してるだけ。
会社の立場が弱かったら常駐させられるんじゃない？
ちなみに１０年前は別の会社だった。制御系が多かったから仕様書だけあれば
それでよかったが、今はWebやってるからどうしてもデザインと合わせないと
いけないし、クライアントからの雑多な変更も多い。
まあ会社の立場とかはどうでもいいんだけど、
ようはどれだけ他の組織とコラボしないといけないか、ということだ。
自分の周囲の人たちだけで完結するんなら、１つのバージョン管理システムを強制すれば
悩みはないだろうが、もっと自由になりたいんだよな。
007877
2008/08/02(土) 15:01:03こっちからは納品日にいっきに客先にマージするんだが、
ここのマージがけっこう苦しいことがあってね。。。
svkでどうにか凌いでるが…Subversionキツいっす…
0079デフォルトの名無しさん
2008/08/02(土) 18:12:11git-svn 使えば svn との同期以外は git側で処理できるから楽なんじゃね？
何故 svk？
0080デフォルトの名無しさん
2008/08/02(土) 18:43:41いや、君が現状に満足してるなら別にいいんだけど。
0081デフォルトの名無しさん
2008/08/02(土) 20:20:56git-svnは使ってるけど、svn側に常にrebaseしてあげないといけないのが痛い。
公開してるGitリポジトリはrebaseできないんで（すると使ってる人全員に影響が出る）
けっきょく個々人はgit-svn、svnから先のマージはsvk使ってる。
Subversion同士でマージするのはsvk賢いよ。重いし、たまにマージうまくいかないが。。。
git-svnもsvkみたいにsvnプロパティでマージポイントの情報を残したりとか、
それかsvn1.5のmerge trackingでどうにかなったりとかするのを期待してるかんじ。
0082デフォルトの名無しさん
2008/08/02(土) 21:07:02いいだけのような気がするが。
0083デフォルトの名無しさん
2008/08/02(土) 22:13:36branchってGitのbranchのこと？ git-svnの話？
0084デフォルトの名無しさん
2008/08/03(日) 13:04:290085デフォルトの名無しさん
2008/08/03(日) 13:45:310086デフォルトの名無しさん
2008/08/03(日) 16:55:310087デフォルトの名無しさん
2008/08/04(月) 09:25:400088デフォルトの名無しさん
2008/08/04(月) 15:31:39書籍じゃないけどこれは?
Mercurialではじめる分散構成管理
ttp://gihyo.jp/dev/feature/01/mercurial
0089デフォルトの名無しさん
2008/08/04(月) 16:27:59たまに目から鱗なコマンドがあったりするけど。
公式ドキュメントで不完全だと言い切ってるから、当分本も期待できそうにないんじゃないかな。
細かいプロジェクトをどう管理するかという話題にはこれといった回答はないし。
Mercurial は <x> できますか？
ttp://www.selenic.com/mercurial/wiki/index.cgi/JapaneseFAQ
0090デフォルトの名無しさん
2008/08/04(月) 19:55:330091デフォルトの名無しさん
2008/08/04(月) 23:31:34どうカスなのか教えてくれ。
0092デフォルトの名無しさん
2008/08/04(月) 23:43:510093デフォルトの名無しさん
2008/08/05(火) 02:41:200094デフォルトの名無しさん
2008/08/05(火) 03:02:58アホな管理の仕方してても
後から挽回しやすいと気軽に使えるよね。
cvsの頃はディレクトリ関係でいつも気を使ってた。
0095デフォルトの名無しさん
2008/08/05(火) 05:31:49もうちょっとしたら日本語訳でるかな。
0096デフォルトの名無しさん
2008/08/05(火) 13:12:340097デフォルトの名無しさん
2008/08/05(火) 18:03:560098デフォルトの名無しさん
2008/08/05(火) 22:25:350099名無し募集中。。。
2008/08/06(水) 09:55:500100デフォルトの名無しさん
2008/08/06(水) 12:37:00>>96
まだネタに使えるほど堕ちてはおらんぞ。
0101デフォルトの名無しさん
2008/08/06(水) 15:20:27最後にまとめてSubversionのリポジトリにコミットという使い方をしたいんだけど
（Gitでのブランチや小刻みなコミットはSubversionのリポジトリに上げたくない）
どうしたらうまくいくんだろう
git-svnはそういう用途じゃないよね？
■ このスレッドは過去ログ倉庫に格納されています