チェックインかどうかは、クリアケースのUCMで優先されますか？

Question

ビルドシステムでは、ビルドが終了すると、アセンブリもチェックインされます。しかし、私たちがUCMに移ったとき、建築家はこの意見を分かち合いました。コンパイルされたアセンブリとmsiのチェックインをサポートしていた人はほとんどいませんでした。

私たちがチェックインしていたときに、シンボリックリンクを行うだけで大きな利点が得られました。さらに、チェックインが完了すると、コピーの代わりにbinとrelease folderからエントリが削除されます。それは私たちの多くを助けた。毎日、人々は夜間ビルドによる最新のアセンブリチェックインで作業することができました。今、彼らはそれをすることができません。彼らは、Nightlyをdllをいくつかの共通の場所にコピーしたいと思っています。

毎日チェックインしているために、私たちのリポジトリは大量になります。

私は最良の選択肢が何か分かりません。

あなたはどの方法が良いと思いますか？ UCM/Clearcaseのアセンブリをチェックインする方が良いでしょうか？

Answer 1

実際には、すべてのビルド出力をソース管理下に置いてはいけません。しかし、期限が切れるまで、それらを共通の場所に置かなければなりません。このプラクティスの背後にある哲学は：

1. バイナリを追加するとリポジトリサイズが大きくなります。
2. 夜間ビルドで作成されたアセンブリの古いバージョン（2年前）は役に立たない。一方、古いバージョンのソースコードとその履歴は、常に有用です。
3. ビルド結果に加えて、通常、ソフトウェア製品は第三者のコンポーネントに依存しています。これらの第三者コンポーネントは通常進化しており、新しいバージョンは通常リリースされます。ソースコントロールにビルド結果を残しておけば、サードパーティコンポーネントの正しいバージョンを別の場所に保存する必要があります。 ClearCaseの中にチェックインアセンブリに対する

Answer 2

もう一つの理由は、クリーンアップの欠如が可能機能です：あなたはない簡単rmver一部のバージョンあなたは、潜在的のVOBレポを損なうことなく、必要ない場合がありますすることができます。

これは、メタデータとハイパーリンクがバージョンに追加されるUCMで特に当てはまります。これにより、他のオブジェクト（UCMベースラインなど）の整合性に非常に危険なものが削除されます。 ないバージョニングバイナリの他、より一般的な、理由から

、「Is it good practice to store framework runtimes under source control?」とhsalimiさんanswerを参照してください。