ノート:バージョン管理システム

出典: フリー百科事典『ウィキペディア（Wikipedia）』

220.210.143.163がコミットをリリースに変更し、チェックアウトをユニットテストに変更していますが。そのように変更する理由がわかりません。 ユニットテストといえばJUnitなどを用いたソフトウェアのテストと混同すると思いますが。 そこだけもとに戻しませんか？hsz 2007年1月16日 (火) 07:46 (UTC)

賛成します。少し調べてみたのですが、「リリース」や「ユニットテスト」と呼ぶシステムが存在するのかすら確かめることができませんでした。--mft 2007年1月20日 (土) 05:04 (UTC)

[編集] 新規に「バージョン」を作ってはどうでしょう

現在「バージョン」は、このページ（バージョン管理システム）へリダイレクトされていますが、バージョンはバージョンで別の項目を作った方がよいのではないかと思います。

[編集] 説明が適切ではないと思います

「ロック、ロック解除」方式はグループ開発でも広く利用されています。 事実、私の経験(約９年)で利用したものの８割位は「ロック、ロック解除」方式でした（グループ開発です）。 ですので、グループ開発に対しての向き不向きで分けるのは適切ではないと思います。 そもそも個人利用であればロック機能は不要であり、適している理由にはなりません。 どうやらオープンソース開発のような不特定多数の開発を前提に説明されているようです。 システム開発会社のように特定多数の組織された開発現場であれば、ロックされたままになった場合は「ロック解除してね」 と言えば済むことです、もしくは管理者がロックを解除します（普通の運用方法です）。

通常、システム開発会社などでは、担当を割り振って開発を行います。 その場合、グループ開発だとしても同じソースを複数の人が同時に編集するようなことはあまり発生しません。 つまりロックしたとしても問題は発生しません。逆に、ロックが不要とも言えます。

では、なぜロックが必要なのでしょうか？、以下に１例を示します。

Ａさんは、担当するソースの修正し、単体テストを行い、テストがOKであったのでソースをコミットします。 このコミットまでに、同じソースをＢさんが編集したらどうなるでしょうか？ Ｂさんは自分の変更部分に対するテストを行っているから、Ａさんの編集したソースにマージしてコミットすれば問題ないでしょうか？ マージされたあとのテストが絶対に必要となります。 ではそのテストは、Ａさん、Ｂさんのどちらが行うべきでしょうか？ テストの押し付け合いになるかもしれません、テストされないかも知れません。 こういう問題を避けるため、編集をシーケンシャルに行うようにするためにはロックが有効です。--Thumbpull 2008年2月21日 (木) 15:29 (UTC)

もう１例上げます。

編集対象が容易にマージできない画像ファイルなどのようなバイナリファイルの場合はどうでしょうか。Aさん、Bさんが同時に編集し、Aさんが先にコミットした場合、Bさんが行った編集は無駄になってしまいます。Bさんは最新バージョンを取得して再度同じ編集をしてコミットしなければなりません。もしその前にCさんがコミットしたら．．．。 そんなのはお互いにコミニュケーションをとって編集するようにすれば良いじゃないの？、という意見もあるでしょう。もちろんそれが前提です、そのうえでさらにロック機能を使い、システム的に完全に衝突を防止するのです。--Thumbpull 2008年2月22日 (金) 11:57 (UTC)

[編集] 「ロック、ロック解除」方式、「コピー、マージ」方式について

「ロック、ロック解除」方式に対して「コピー、マージ」方式としていますが、「ロック、ロック解除」であっても、バージョン管理システムからはコピーしてくるのには変わりはないと思います（移動してロックを実現しているわけではないでしょう）。ですので適切ではないような気がします。 「排他方式」、「マージ方式」などのほうが良いかも知れません。いかがでしょうか？--Thumbpull 2008年2月21日 (木) 15:35 (UTC)