私は常に「マージ」方法を使用するバージョン管理に Subversion または CVS を使用してきました。私の友人の 1 人が、Perforce と、その変更リストとチェックアウト方法がいかに優れているかを絶賛しています。
その多くは経験と個人的な好みによるものだと確信していますが、バージョン管理のどの方法がより効率的に作業できるかについて調査が行われたかどうか疑問に思っていましたか?
編集：明確にするために、PerforceとSVNの両方でロックとマージが許可されていることを知っていますが、SVNはリベラルな編集とマージ方法を「推奨」しますが、私が理解しているように、Perforceはチェックアウトチェックイン方法を推奨しています。
マージはより効率的です。同じファイルへの変更が同時に行われることが一般的であるという単純な理由から、マージを使用すると、そこから回復できます。対照的に、シングルチェックアウトはその少しの余分な作業を防ぎますが、スケジューリングの大幅な非効率性を犠牲にしてそうします。通常、2つの変更を同じファイルにマージするには短時間（たとえば数分）かかりますが、ファイルに変更を加えるにはかなりの時間がかかり（たとえば数時間または数日）、ファイルの編集にアクセスできなくなります非常に非効率的です。
Perforceはチェックアウト方法を強制せず、同時チェックアウト（マージと同等）を許可することに注意してください。
正直なところ、それは開発者の規律に依存すると思います。
私は個人的な仕事にSubversionを使用しており、いくつかの仕事で使用しています。私がSubversionで気に入っているのは、誰かを追い詰めて、なぜ彼らが何かに取り組んでいるのか、そして私が何かの仕事をしても大丈夫かどうかを尋ねる必要がないことです。問題は、誰かが何かに取り組み始めることを決定し、しばらくの間それをチェックインしないときに起こります。これにより、チェックアウトとチェックインの間にいくつかの変更が加えられるため、マージが困難になる可能性があります。
私は現在Perforceを使用していますが、何らかの理由でSVNの方が好きです。PERFORCEは間違いなく、マージの競合が発生することをより正確に示してくれます。また、マージを解決するのに役立つ組み込みツールもあります。同じ問題があり、誰かが長期間にわたって大量の変更を行うと、マージがより困難になります。
基本的に、どちらのモデルでも、変更を頻繁にチェックインする必要があります。多数のチェックインを行うと、マージが必要になる可能性が低くなります。私は物事をあまりにも頻繁にチェックアウトし続けることに罪を犯しています。個人的には、SVNの値札がPERFORCEと比較して不足しているものを補っているように感じます。私はまだそれらの違いを見つけていません。
前回の評価では、Perforce は分岐のサポートと分岐間の変更の統合で Subversion を打ち負かしました。Subversion では、この欠点を修正する作業が進行中でしたが、まだチェックしていません。
Perforce では、ファイルを分岐すると、Perforce はそのファイルがどこから来たのか、どのリビジョンが 2 つのバージョンに「統合」されたかを「記憶」します。また、リポジトリ内のストレージの最適化もいくつか行われているため、誰かがブランチに変更を加えるまでブランチ コピーは実際には実現されず、(私の理解が正しければ) ベース コピーに対して差分が使用されます。ブランチ。
Perforce によるブランチ間の関係の追跡は、大きな資産です。Subversion がこれを実装している場合は、お知らせください。
おそらく、PerforceではなくSource Safeを意味していましたか？Perforceはマージをサポートしており、実際には、名前付きマージが追加されるSVN 1.5まではSVNよりも優れたマージサポートを備えていました（Perforceが常に持っていた変更リストもあり、SVNを使用するショップに移動するのは非常に残念ですが、 1.5がもう少し時間がテストされるまでアップグレードします。）
SVNとPerforceの両方でロックされたチェックアウトを実行できるため、必要に応じて「マージされていない」モデルを実行できますが、バージョン管理を使用してバイナリを管理することを除けば、これはあまり使用されません。
とにかく、あなたの質問に対する簡単な答えは、「複数の開発者が関与するときはいつでも、モデルのマージがはるかに優れている」ということです。
私が正しく理解していれば、PERFORCEはチェックアウトされていないすべてのファイルを読み取り専用にします。これは、MicrosoftTFSおよびVSSでの動作に似ています。一方、Subversionは読み取り専用属性を設定しません。IMO、Subversion方式は、ファイルを変更するためにソース管理クライアントを気にする必要がないため、より簡単です。先に進み、無謀な放棄で変更し、準備ができたらディスク上で変更されたものをサーバーと比較します。チェックインをする。
すべてのファイルが読み取り専用の場合、ファイルを常に変更し、保存を試み、読み取り専用であることを発見してから、ソース管理クライアントにアクセスしてチェックアウトする必要があります。ソース管理クライアントがエディターに統合されている場合はそれほど悪くはありませんが、バージョン管理下のソースコードではないものを保存している場合、これはオプションではないことがよくあります。
私の理解が正しければ、Perforce はチェックアウトされていないすべてのファイルを読み取り専用にします。
これはデフォルトの動作にすぎません。必要に応じて、頻繁に変更されるファイルを読み書き可能に設定できます。ファイル修飾子の完全なリストについては、こちらを参照してください。
また、私の環境では、Eclipse とPerforce Pluginを使用しています。このプラグインを使用すると、ファイルを編集するとすぐに編集用のファイルが開きます。
調査についてはよくわかりませんが、ここに1つのデータポイントがあります。
私のチームは、主に快適さのためにPVCS（チェックアウト）を選択しました。マージに関する疑問とSubversionのようなツールの認識の欠如が間違いなくそれに貢献しました。
ここでの質問を理解できるかどうかはわかりません。マージを完全にサポートしていない最新のソース管理システム（Visual SourceSafe以外）を認識していません。
私は間違いなくマージ方法論を好みます。
Visual Sourcesafe (願わくば二度と)、CVS、subversion、および bzr を使用しました。ビジュアル ソース セーフは、「編集前にチェックアウトする」方法を強制するため、面倒な場合があります。CVS と Subversion は歴史的にマージを受け入れるのが得意ではありませんでしたが、Subversion 1.5 ではそれが改善されたと聞いています。
最初から頻繁なマージを念頭に置いて設計された VCS を使用することをお勧めします。bzr は私がこれを行うために使用したものですが、他の主要な分散型 vcs システム (git および mercurial) も同様です。
しかし、最終的には、この特定の分野に関する研究については知りません。一般に、プログラミングの効率に関する調査はほとんど行われていませんが、Peoplewareは注目に値する例外の 1 つです。
正直なところ、質問がよくわかりません。しかし、Perforce の効率性と、ファイルを非同期的に変更する複数の人を処理し、編集のマージを処理する能力を保証できます。
Perforce では、あなたも変更しているファイルを誰かがチェックインすると、次にサーバーから同期する (つまり、最新のファイルを取得する) ときに、解決が必要な変更があることが通知されます。これをいつ行うかは、あなた次第です。ファイルを「解決」すると、ローカル バージョンにマージされます。ツールはこれに適しています。
いつ実行するかを選択できることが重要です。タスクに直接関係のない更新 (バグ修正など) を取得できるように同期している可能性があります。作業しているのと同じファイルに変更すると、影響があります。続けて、ビルドとテストを行い、その後、自分の時間でファイルを解決します。
もう 1 つのケースは、最初に更新されたファイルに同期せずに編集内容を送信した場合です。この場合、Perforce は送信を阻止し、解決する必要があるファイルにフラグを立てます。この段階で賢明な開発者であれば、マージを行い、変更を Perforce に戻す前に再コンパイルおよび/またはテストを行います。
これについて私が気に入っているのは、明示的に処理されていない変更を中央サーバーに送信するのを非常に困難にしようとするため、ビルドが壊れる可能性が最小限に抑えられることです. 解決プロセスは簡単でオーバーヘッドが非常に少ないため、効率性の問題はまったくありません。
Perforce は、変更がどのように反映されるかを選択および制御できることを非常に明確に示しており、編集のマージを管理するための優れたツールでこれをバックアップします。個人的には、選択と選択を簡単に実行できる力が好きです。Doubtless Subversion にも独自の代替手段があります。
おそらく、あなたが慣れ親しんでいることに帰着すると思います-重大または測定可能な効率の問題はないと思います。