私は常に、「マージ」方法論を使用するバージョン管理用にSubversionまたはCVSを使用しました。私の友人の一人は、PERFORCEについて賞賛しています。変更リストとチェックアウト方法については、どれほど素晴らしいですか？より効率的なバージョン管理方法は何ですか：チェックアウトまたはマージ？
私は確かに&の個人的な好みを体験することができますが、どのバージョン管理方法がより効率的であるかについての研究が行われているのでしょうか？
EDIT：は、私は両方のPERFORCE & SVNを知っ&マージをロックできますが、私はそれを理解するよう、PERFORCEのチェックアウト、チェックインの方法を奨励する一方、SVNは、リベラル編集&マージ方法「を奨励」、明確にするため。
正直私はそれが開発者の規律に依存すると思います。
私は個人的な作業にSubversionを使用しています。私はいくつかの仕事でそれを使用しています。 Subversionについて私が気に入っているのは、誰かを捜して、何かに取り組んでいる理由を尋ねたり、何か作業をしても問題ないかどうかを質問したりする必要はありません。誰かが何かに取り組むことを決めてしばらくそれをチェックしないと問題が起こります。これにより、チェックアウトとチェックインの間にいくつかの変更が加えられるため、マージが困難になります。
私はPerforceを現在使用しています。何らかの理由で私はSVNがより好きです。 Perforceは、マージ競合が発生する可能性があることをより明確に示してくれます。また、マージを解決するためのツールも組み込まれています。同じ問題があります。長い間に誰かが大きな変更を加えた場合、マージはもっと難しくなります。
基本的に両方のモデルで、頻繁に変更をチェックインする必要があります。多数のチェックインを行うと、マージが必要になる可能性が低くなります。私はあまりにも頻繁にあまりにも頻繁にチェックアウトされたものを保つことの有罪です。個人的に私はSVNの値札がPERFORCEに比べて欠けているものを補うように感じます。私はまだそれらの違いを発見していない。
マージが効率的です。単純な理由から、同じファイルへの変更が同時に頻繁に起こる傾向があり、マージではそれを元に戻すことができます。対照的に、単一のチェックアウトは、余分な作業を少しでも防ぎますが、スケジューリングの巨大な非効率性を犠牲にして行います。通常、2つの変更を同じファイル（たとえば分）にマージするのに少し時間がかかりますが、ファイルを変更するにはかなりの時間（例えば数時間または数日）がかかります。巨大な非効率性です。
PERFORCEはチェックアウト方法を強制しないので、コンカレント・チェックアウト（マージと同じ）が可能です。
研究についてはわかりませんが、ここでは1つのデータポイントがあります。
私のチームは主に快適性のためにPVCS（チェックアウト）を選択しました。 Subversionのようなツールのマージと認識の欠如についての疑問は、それに確かに貢献しました。
私はここでの質問をよく理解していません。マージを完全にサポートしていない現代のソース管理システム（Visual SourceSafe以外）は認識していません。
おそらく、あなたはPERFORCEではなくSource Safeを意味していましたか？ PERFORCEはマージをサポートしています。実際には、名前付きマージが追加されたSVN 1.5（PERFORCEはいつも持っていた変更リストとSVNを使用していたショップにはかなり間違いがありますが、あなたが望むならば、 "unmerged"モデルを実行することができるので、SVNとPerforceの両方があなたにロックされたチェックアウトをさせることができます。バージョン管理でバイナリを管理すると、私はこれをあまり利用していません。
とにかく、あなたの質問に対する簡単な答えは、「マージモデルは複数の開発者が関わっているときはいつでも優れています」ということです。
私が正しく理解していれば、チェックされていないすべてのファイルが読み取り専用になります。これは、Microsoft TFSとVSSの動作に似ています。一方、Subversionは読み取り専用属性を設定しません。 IMOでは、ファイルを変更するためにソース管理クライアントを気にする必要がないため、Subversionメソッドが簡単になります。準備ができたら、無意味な放棄で変更し、ディスク上で変更された内容をサーバーと比較しますチェックインする
すべてのファイルが読み取り専用の場合、ファイルを常に変更して保存しようとすると、読み取り専用であることがわかり、ソースコントロールクライアントにチェックインしてチェックアウトする必要があります。ソース管理クライアントがエディタに統合されていればそれほど悪くないが、バージョン管理下にあるソースコードではないものを保存する場合、これはオプションではないことが多い。
私が正しく理解している場合、PERFORCEはチェックアウトされていないすべてのファイルを読み取り専用にします。
これはデフォルト動作です。必要に応じて頻繁に変更されるファイルを読み書き可能に設定することができます。ファイル修飾子の全リストhereを参照してください。
私の環境では、Perforce PluginのEclipseを使用しています。このプラグインを使用すると、ファイルを編集するとすぐに編集用のファイルが開きます。
私は間違いなくマージ方法をお勧めします。
私は、Visual Sourcesafe（うまくいけないことですが）、CVS、subversion、bzrを使用しました。 Visual SourceSafeは、「編集前のチェックアウト」手法を適用し、苦痛を伴う可能性があります。 CVSとSubversionは、歴史的にマージを受け入れる上で大したことではありませんでしたが、Subversion 1.5がそれを改善したと聞いています。
最初から頻繁にマージされるように設計されたVCSの使用をお勧めします。 bzrは私がこれをしたものですが、他の主要な分散vcsシステム（gitとmercurial）もそうです。
しかし、最終的に私はこの特定の分野に関する研究について知らない。一般に、プログラミングの効率性についての研究はほとんどなく、Peoplewareが注目すべき例外の1つです。
最後の評価では、Perforceは分岐のサポートとブランチ間の変更の統合でサブバージョンを打ち負かしました。この短期間の問題を改善するためにSubversionで作業が進められましたが、確認のために戻っていません。
PERFORCEでは、ファイルをブランチすると、PERFORCEはそれがどこに由来し、どのリビジョンが2つのバージョンに「統合」されているかを「記憶」します。リポジトリにはいくつかのストレージの最適化機能があり、ブランチの変更が実際には起こらないようにしてから、（正しく理解すれば）ベースコピーに対してdiffを使用します。ブランチ。
PERFORCEのブランチ間の関係の追跡は大きな資産です。 Subversionがこれを実装していれば、頭をアップしてください。
正直言って、私は実際に質問をしません。しかし、私は、PERFORCEの効率性と、複数の人物が非常にファイルを修正し、編集のマージを処理する能力を保証することができます。
修正中のファイルをチェックインすると、次にサーバーから同期する（最新のファイルを取得する）と解決が必要な変更があることが通知されます。これをいつ行うかは、あなた次第です。ファイルを "解決"すると、ローカルバージョンにマージされ、ツールはこれに適しています。
あなたがそれをするときに選択することが重要です - 同期している可能性がありますので、あなたの仕事に直接関連しないアップデートを得ることができます（bugfix、say）。その段階では、あなたが作業している同じファイルへの他の人の変更があなたに影響を与えるかどうかを調べます。だからあなたの上にあなたのビルド&テストを行い、その後、あなたはあなた自身の時間にファイルを解決します。
もう1つのケースは、更新されたファイルに最初に同期しなくても編集内容を送信する場合です。この場合、PERFORCEは送信を防ぎ、ファイルを解決するフラグを立てます。この段階で賢明な開発者があれば、マージを行い、再コンパイルおよび/またはテストを行ってから、変更をPERFORCEに戻します。
私がこれについて気に入っているのは、明示的に処理されていない変更を中央サーバに戻すことをやめさせて、ビルドを中断する可能性を最小限に抑えることです。解決プロセスは簡単で非常に低いオーバーヘッドなので、効率の問題はまったくありません。
PERFORCEは、変更を伝播する方法を選択して制御することを非常に明示しており、編集のマージを管理する優れたツールを使ってこれをバックアップします。個人的に私は選択肢と選択肢を簡単に行使できる力が好きです。間違いなくSubversionには独自の選択肢があります。
私はおそらくあなたが慣れているものになると思います。私は、重要で測定可能な効率の問題はないと思います。
私はSubversion 1.5がマージトラッキングを持っていると信じています。 –