ノート:バージョン管理システム
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)
版管理におけるロック方式は、複数のファイルが互いに関連し合っている場合に問題が生じます。つまり、単一のファイルをロックして安全に編集しているつもりでも、他人が別の関連するファイルを正規にロックすることができ、これらのファイルに独立した修正が施される可能性があります。これをロック方式で完全に排除するためには、関連するファイルをすべて同時にロックする必要があります。これは、実質的に管理対象のファイルを全てロックすることになります（完全に独立したファイルがシステム内に存在するでしょうか？）。このような操作は、個人や少人数では可能でしょうが、多人数では破綻します。もちろん上の方がおっしゃる通り、完全なロックを使わず、ファイル単体のロックを用いて、その他の依存性の整合は人間系で解決することもできます。これを自動化したものが（理想的な）版管理システムだと思います。ちなみに、マージ方式であっても全く人間系が介在しないわけではありません。やるべきことはロック方式と変わりありません。ただ、システムが自動的にサポートしてくれる範囲が広いだけなのです。--118.243.92.227 2009年2月15日 (日) 20:09 (UTC)
「ロック、ロック解除」方式、「コピー、マージ」方式について
[編集]「ロック、ロック解除」方式に対して「コピー、マージ」方式としていますが、「ロック、ロック解除」であっても、バージョン管理システムからはコピーしてくるのには変わりはないと思います（移動してロックを実現しているわけではないでしょう）。ですので適切ではないような気がします。 「排他方式」、「マージ方式」などのほうが良いかも知れません。いかがでしょうか？--Thumbpull 2008年2月21日 (木) 15:35 (UTC)
統合提案
[編集]チェックインとチェックアウトを本記事へ統合し、跡地は曖昧さ回避とすることを提案いたします。現状、両記事ともスタブであり、かつ細切れのままでは記事が成長しにくいと考えます（ポイントはこの2つをVCSがどう捌くかであり、単独では書けることがあまりないように思います）。--Yukida-R 2009年7月9日 (木) 14:43 (UTC)
- 特に反対意見は出ませんでしたので、実施しました。--Yukida-R 2009年8月1日 (土) 09:49 (UTC)
「分散型バージョン管理システム」の統合提案
[編集]最近作成された「分散型バージョン管理システム」を「バージョン管理システム」に統合することを提案します。集中型リポジトリのものと分散型リポジトリのものがあることを、本記事で解説する方が読者の理解への助けとなるでしょう。--iwaim 2010年11月15日 (月) 14:17 (UTC)
2020年11月14日におこなわれた差し戻し（リバート）の是非についてです。
- 出典つき新規記述の取り消し: Refタグつき記述の除去 参照
- 理由のない全面取り消し: Help:以前の版にページを戻す方法 参照
上記2点に基づき、投稿リバートは良い方法ではないと考えます。 改善点を加筆する形で修正していただければと思います。 --Tarepan（会話） 2020年11月14日 (土) 20:33 (UTC)