#2 および/または #3
#1単一リポジトリ、ロックされたアクセス - 最近はめったに使用されないため、言及する価値はありません。
#2単一リポジトリ、同時アクセス - VCS または CVCS (Centralized Version Control System) と呼ばれるものは、今でも広く使用されています。
#3分散型 - 他のシステムが開発者に課している多くの人為的な障壁が取り除かれるため、次の大きな課題です。
まず、あなたの質問/懸念事項に答えます:
1.商業的に受け入れられるかどうかは、組織とその開発者によって異なります。管理者が使用されているソフトウェアの責任者であり、実際の証拠がほとんどない保守的な決定を強硬に行う傾向がある場合、Microsoft が提供するものは何でもデフォルトにする可能性があります。その場合は、頑張ってください。MS のバージョン管理 (具体的には SourceSafe) について聞いたことがあるのは悪いことばかりで、MS に DVCS オプションがまだあるかどうかはわかりません。
OTOH、開発者チームがツールの選択を担当している場合 (またはマネージャーが心を開いている場合)、おそらく git または mercurial が適しています。git は非常に複雑なため、順応するのが面倒です。mercurial は CVCS から非常に簡単に移行できます。ワークフローの感触を掴むために tortoisehg GUI クライアントをダウンロードしてください。両方とも完全に安定しており、生産の準備が整っています。Mercurial と Subversion は、Sourceforge.net と Google Code で使用されており、どちらも何千ものプロジェクトをホストしています。彼らが持っている可能性のあるバグは、知っているか、すでに解決済みです。
2.「この時代、独自のバージョン管理システムを展開することは、時間とエネルギーのばかばかしい無駄です」と言うとき、私は開発者全体を代弁していると確信しています。
確かに、小型でアプリケーションに適合する特別な目的のバージョン管理システムを作成することはおそらく可能です。ただし、決定する前に、事業にかかるすべての時間と労力を考慮してください。言うまでもなく、バージョン管理システムのコードをバージョン管理下に置く必要があります。言っ途切れる...
3.いいえ、実際には両方を一緒に使用できます。多くの人が CVCS (通常はサブバージョン) を使用して組織全体のレベルでバージョンを一元管理し、DVCS を使用して小規模なグループまたは個別にローカルで開発しています (Microsoft のエンジニアが開発者サブグループで秘密裏に git を使用しているという話さえあります)。DVCS はファイル システムでは隠しフォルダーと無視ファイルにすぎないため、すべての情報を CVCS 無視ファイルに簡単に追加して、情報が中央リポジトリで追跡されないようにすることができます。必要に応じて、両方の利点を活用できます。
DVCS にコミットするときに、DVCS のコミット履歴を CVCS に転送する方法さえあると思います。ただし、理由がなかったので、正確な方法はわかりません。
4.間違いなく＃2および/または＃3。
すでに CVCS が導入されており、それを使用することが期待されている場合は、両方と言います。
Subversion はおそらくすべてを実行できますが、問題は、CVCS のすべてのバージョン履歴がサーバーに保持されることです。IE、ネットワークに直接アクセスできない場合、コミットまたは更新できません。一部の開発者にとってはこれで問題ありませんが、ほとんどの開発者は移動中であり、作業が必要なときに常にネットワーク接続を見つけることができるとは限りません。これの悪い点は、コミットが引きずり出され、トランク開発ブランチとさらに同期していないソースで作業することになります。Subversion (または一般的には CVCS) は、ブランチの処理が苦手なことで有名です。つまり、2 人の開発者がメインラインの 2 つの異なるブランチでアイデアをテストしていて、それらをマージして戻すことにした場合、事態は悪化します。ブランチでは、DVCS の方がはるかに優れています。
CVCS が導入されていない場合は、DCVCS のみを使用してください。
DCVS は、リポジトリのリモート クローンをデポジット ポイントとして機能させることができるため、すべてを行うことができます。ワークフローの違いは、CVCS にコミットすると、問題がなければリモート リポジトリに直接移動することです。DCVS でコミットすると、変更がない場合はローカル リポジトリにコミットされます。次に、一連の変更をリリースする準備ができたら、コミットをリモートにプッシュ (または Mercurial で同期) します。
DCVS 内のリポジトリはすべて同じであるため、場所に関係なく、他のリポジトリからプッシュ/プルできます。最初は頭を包み込むのは少し難しいですが、いくつかの明確な利点があります. まず、プロジェクトの履歴をどこにでも常に持ち歩いているため、中央サーバーがダウンしても、すべての開発者がそのバックアップ コピーを持ち歩いているので、大したことではありません。第二に、開発者がいつでも無制限にコミットできるようにすることは非常に有益です。開発者がコミットすればするほど、バージョン履歴が詳細になり、コードをロールバックする必要がある場合に問題をより早く見つけることができます。
あなたが説明しているものを実装するには。必要な場所にスターター リポジトリを作成します。必要なのはネットワーク アクセスだけです。
初期ファイルをプロジェクト フォルダーにコピーし、コミットします。
ファイルで作業しているすべての人に、リポジトリの独自のコピーを複製してもらいます。
プログラムで更新を行う必要がある場合は、変更を中央リポジトリからプルする必要があるかどうかを確認するか、必要に応じてコマンドラインを使用して新しい変更をコミットおよびプッシュする必要があるかどうかを確認できます。
ソース管理下のフォルダー内のテキスト ファイルにシリアル化されたデータを書き込める限り、問題はありません。コミット/プッシュ時に手動で競合を解決する必要がありますが、それはどのバージョン管理システムでも予想されることです。
リモート リポジトリとローカル リポジトリの間で競合がほとんどまたはまったくないことを確認したい場合は、コミットする前にローカル コピーを常にプルさせます。そうすれば、競合が発生した場合でもローカルで処理できます。
それだけです。