共有ライブラリの分岐およびバージョン管理戦略
これらの 投稿は関連しているように見えますが、私の脳は溶け始めています：P 私の雇用主はソース管理の使用を開始しました。主に、彼らがより多くの開発者を雇う前に、「リポジトリ」は主に自宅で働く孤独な開発者のハードドライブだったからです。彼が書いた.NETコードはすべてまとめてチェックインされ、多くの重複した（読み取り：コピーアンドペースト）機能があります。現時点では、SCMシステムは栄光のバックアップです。 重複したコードの一部を共有ライブラリに引き込みたいです。元のリポジトリはそのままにしておき、何も壊さないようにします。必要に応じて既存のコードを移動および/またはリファクタリングできます。それで、ライブラリを含む新しいコードのためだけにリポジトリを設定しました。 私の問題は、過度のプロセスに悩まされることなくライブラリをバージョン管理することを中心にしています。ソリューションが生産性に影響を与え始めた場合、うまく落ちます。 私の強迫観念での理想的な解決策は、ライブラリを個別にビルドし、各依存プロジェクトを意図的に選択した互換性のあるバージョンに対してビルドすることです。そのようにして、どのクライアントがどのライブラリのどのバージョンを持っているか、バグをより確実に再現でき、製品とライブラリの独立したリリースブランチを維持でき、共有コードを変更するときに互いのプロジェクトを壊さないようにできます。 これにより、特に自宅で働く開発者にとっては、ライブラリの更新が面倒になります。少なくとも当初は（最終的に）共通部分をまとめると、ライブラリが急速に変化することを期待しています。私はこれを完全に考えすぎている可能性が高く、最新のライブラリコミットに対してすべてを構築するだけで構いませんが、少なくとも一部のコンポーネントを個別にバージョン管理する必要があると判断した日には備えたいと思います配布されました。一部のライブラリをGACにインストールする必要があるという事実により、バージョン管理は特に重要になります。 だから私の質問は：私は何が欠けているのですか？1つのソリューションに固執しているように感じますが、現在、変更をよりスムーズにするバリエーションを見つけようとしています。以前、この種の問題を解決するためにどのような戦略を使用しましたか？この質問はあちこちにあることを理解しています。不確実な点を整理し、明確にするために最善を尽くします。 そして、私はMercurialを使いたいと思っていますが、私たちはすでに集中型商用SCM（Vault）にお金を費やしており、切り替えはオプションではありません。また、ここでの問題は、バージョン管理ツールの選択よりも深くなると思います。