1

〜10人の開発者のグループがあります。内部テストSWのみを作成する人。これまで、すべての開発はアドホックであり、Mercurialを独自の方法で使用している開発者はわずか数人でした。残りの人々は、これまでバージョン管理を使用していません（私は知っています）。構成管理も、過去には少しアドホックでした。現在、親会社は私たちがより構造化されることを望んでいます。現在、親会社が企業のClearCaseサーバーに接続するまで（数か月後）、Mercurialですべてのコードを強制的に制御するプロセスにあります。

このフォーラムの誰かに、MercurialとClearCaseの両方での構成管理に至るまでの開発をカバーする実証済みのプロセス/ワークフローについて説明してもらいたいと思います。

私たちは両方のツール（MercurialとClearCase）の経験がありますが、これらのツールの周りのプロセスの設定についてはあまり経験がありません。したがって、実証済みのプロセスをここで説明できれば、それを出発点として使用して、開発用の独自のプロセスを定義し、構成管理の統合も行います。

クリアケースの使用は必須であるため、クリアケースの短所を説明する必要はありません。

どんな助けでも大歓迎です。ありがとう。

4

1 に答える 1

0

サーバーの箇条書きはありません。実際には、CVCS（Centralized VCS）であるClearCaseをどのように使用するかによって異なります。
CVCSとDVCSの違いについて詳しく説明しました。

このような統合がうまく機能する（または少なくとも「それほど悪くない」）のは、DVCSとClearCaseUCMの間だけです。

現在のMercurialリポジトリが「コンポーネント」の概念に基づいて編成されている場合（「ClearCaseUCM-コンポーネントを使用したベストプラクティス」を参照してください。これは、コンポーネントとは何かを説明し、すべてのソース管理ツールに適用されます）。次のマッピングは簡単です。

one DVCS repo <=> one ClearCase UCM Component

これにより、次のことを定義できます。

  • 明確なインポート手順（に基づくclearfsimport）
  • MercurialタグとClearCaseUCMベースライン間の明確な一致（ベースのClearCaseタグまたは「ラベル」はファイルごとに適用されるため、このラベルはDVCSリビジョンをモデル化するための優れたツールではありません。DVCSタグはすべてを参照しますリポジトリであり、上記のリポジトリ内のファイルのサブセットではありません。）
  • 明確な依存関係管理（MercurialサブリポジトリとClearCase UCM複合ベースライン）
于 2012-04-12T05:46:13.780 に答える