65

すべての開発者が知っておくべき Clearcase バージョン管理システムの中心的な概念は何ですか?

4

7 に答える 7

144

コアコンセプト？

  • 集中型（複製）VCS：ClearCaseは、集中型VCSワールド（1つまたは複数の「集中型」リポジトリまたはVOBS-バージョンオブジェクトベース-すべての開発者がコミットするためにアクセスする必要があります）と分散型VCSワールドの中間にあります。
    ただし、「複製」モードもサポートしているため、離れたサイト（MultiSite ClearCase）でリポジトリを複製し、デルタを送信し、所有権を管理できます。（ただし、それに付随するライセンス料は非常に高額です）
    これは真の「分散型」モデルではありません。並列同時進化が許可されていないためです。ブランチは1つのVOBまたは別のVOBでマスターされます。マスターVOBにチェックインできるのは、そこでマスターされているブランチのマスターVOBのみですが、任意のレプリカの任意のブランチへの読み取り専用アクセス権があります。

  • 線形バージョンストレージ：各ファイルとディレクトリには線形履歴があります。ファイルの履歴がコミットにリンクされたディレクトリの1つにリンクされているDAVGCS（有向非巡回グラフ）のように、それらの間に直接的な関係はありません。
    つまり、

    • 2つのコミットを比較する場合、すべてのファイルとディレクトリのリストを比較してデルタを見つける必要があります。これは、コミットがファイルまたはディレクトリ間でアトミックではないため、を構成するすべてのファイルに対するすべての変更に単一の名前がないことを意味します。論理デルタ。

    • これは、マージが履歴探索を通じて共通のベースコントリビューター（常に共通の祖先と同じであるとは限らない）を見つける必要があることも意味します（次のポイントを参照）。

      （Gitはそのスペクトルの反対側にあり、分散型であり、DAG指向です。

      • グラフのノードが別のコミットのノードと同じ「id」を持っている場合、それ以上調べる必要はありません。すべてのサブグラフが同一であることが保証されます。
      • 2つのブランチのマージは、実際にはDAG内の2つのノードのコンテンツのマージです。再帰的で、共通の祖先を見つけるのに非常に迅速です）

代替テキストhttp://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.hlp.doc/cc_main/images/merg_base_contrib.gif

  • 3方向マージ：2つのバージョンをマージするには、ClearCaseは線形履歴で共通ベースのコントリビューターを見つける必要があります。これは、複雑なバージョンツリー（ブランチ/サブブランチ/サブサブ/ブランチなど）ではかなり長くなる可能性があります。基本的なClearCaseマージコマンドはファイルまたはディレクトリをマージしますが、再帰的ではありません。単一のファイル、またはファイルのない単一のディレクトリにのみ影響します（ct findmerge再帰的です）

  • ファイル中心（他の最近のVCSよりリポジトリ中心とは対照的）：つまり、コミットは「変更されたファイルのセット」ではなく、ファイルごとに行われます。トランザクションはファイルレベルで行われます。複数のファイルのコミットはアトミックではありません。
    （他のほとんどすべての最新ツールは「リポジトリ中心」であり、アトミックコミットトランザクションがありますが、RCS、SCCS、CVS、および他のほとんどの古いシステムなどの第1世代システムにはその機能がありません。）

  • id-managed：各ファイルとディレクトリには一意のIDがあります。つまり、自由に名前を変更できます。IDは「要素」に残っているため、履歴は変更されません。さらに、ディレクトリはその履歴でファイルの追加/抑制を検出します。ファイルが「削除」されると（rmname）、それは認識されません。ディレクトリのみが通知され、削除されたファイルを含まないサブ要素のリストとともに、その履歴に新しいバージョンが作成されます。

（同じサイズとコンテンツの2つのファイルを作成すると、Gitで同じID（SHA1キー）が取得され、Gitリポジトリに1回だけ保存されます！ClearCaseではそうではありません。
さらに、同じ2つのファイルの場合パスと名前は2つの異なるブランチで作成され、IDが異なるということは、これら2つのファイルがマージされないことを意味します。これらは「邪悪な双子」と呼ばれます）

  • ブランチは第一級市民です：ほとんどのVCSは、ブランチとタグを同じものと見なします：新しい線形履歴が成長できる履歴内の単一のポイント（ブランチ）または説明が添付されている場所（タグ）。
    ブランチがバージョン番号を参照する方法であるClearCaseの場合はそうではありません。バージョン番号は、0（ClearCaseで参照されている）から1、2、3などで始まります。各ブランチには、バージョン番号の新しいリスト（0、1、2、3）を含めることができます。
    これは、バージョン番号が一意で常に増加している（SVNのリビジョンのように）、または単に一意である（GitのSHA1キーのように）他のシステムとは異なります。

  • path-accessed：ファイル/ディレクトリの特定のバージョンにアクセスするには、その拡張パス（ブランチとバージョンで構成される）を知っている必要があります。これは「拡張パス名」と呼ばれますmyFile@@/main/subBranch/Version。

（Gitはid --SHA1ベース-：バージョン[またはコミット]、ツリー[またはディレクトリのバージョン]およびblob [またはファイルのバージョン、またはファイルのコンテンツのバージョン]を介してすべてを参照します。これは「id-accessed」または「id-referenced」です
。ClearCaseの場合、idは「要素」（バージョンに関係なく、ディレクトリまたはファイル）を参照します。）

  • ペシミスティックロックとオプティミスティックロックの両方:(ClearCaseの予約済みまたは未予約のチェックアウト）：ペシミスティックロック（予約済みチェックアウト）でさえ、他のユーザーがそのファイルをチェックアウトできるため（「予約なしモード」でも）、真のペシミスティックロックではありません。変更しますが、最初のユーザーがファイルをコミットする（チェックインする）か、リクエストをキャンセルするまで待つ必要があります。次に、同じファイルのチェックアウトバージョンをマージします。
    （注：「予約済み」チェックアウトは、所有者または管理者のいずれかによって、ロックを解除して予約解除することができます）

  • 安価な分岐：分岐によってすべてのファイルのコピーがトリガーされるわけではありません。実際には何もトリガーされません。チェックアウトされていないファイルは元のブランチに残ります。変更されたファイルのみが、宣言されたブランチに新しいバージョンが保存されます。

  • フラットファイルストレージ：VOBは、単純なファイルを使用して独自の形式で保存されます。これは、簡単なクエリ言語を備えたデータベースではありません。

  • ローカルまたはネットワークワークスペースへのアクセス：

    • ローカルワークスペースは、ハードドライブへのチェックアウト（スナップショットビューの「更新」）を介して行われます。
    • ネットワークワークスペースは動的ビューを介しており、バージョン管理されたファイルと、ネットワークを介したディレクトリアクセス（ローカルコピーなし、インスタントアクセス）とローカルファイル（チェックアウトされたファイルまたはプライベートファイル）を組み合わせます。遠隔（バージョン管理済み）ファイルとローカル（プライベート）ファイルの組み合わせにより、動的ビューを従来のハードドライブのように見せることができます（実際には、「書き込まれた」ファイルはすべて、関連付けられたビューストレージに保存されます）。

  • 一元化された強制送還ストレージ：[表示]ストレージは、一部のデータを保持し、中央参照との通信を回避するためにあります。
    ワークスペースには次のものを含めることができます。

    • 散在するストレージ：あちこちの.svnサブディレクトリのように
    • 一元化されたストレージ：ClearCaseのビューストレージと同様に、ビューによって表示されるファイルに関する情報が含まれ、そのストレージはビューに固有のものです。
    • デポートされたストレージ：ストレージはビュー/ワークスペース自体の一部ではありませんが、コンピューターの別の場所に配置することも、LAN/WANの外部に配置することもできます。

（Git自体には「ストレージ」はありません。.git実際にはすべてのリポジトリです！）

  • メタデータ指向：任意の「キー値」をファイルまたはディレクトリに添付できますが、その2つのデータ自体は履歴に記録されません。値が変更されると、古い値が上書きされます。

（メカニズムは実際にはSVNの「プロパティ」システムよりも弱いことを意味します。SVNではプロパティに履歴があります。
もう一方の端のGitはメタデータにあまり熱心ではありません）

  • システムベースの保護：ファイル/ディレクトリまたはリポジトリに関連付けられている所有者と権利は、基盤となるシステムの権利管理に基づいています。ClearCaseには適用可能なアカウントはなく、ユーザーのグループはWindowsまたはUnixの既存のグループに直接基づいています（これは、WindowsクライアントとUnix VOBサーバーを使用する異種環境では非常に困難です！）

（SVNは「サーバーベース」の保護に似ており、Apacheサーバーは最初のレベルの保護を取得できますが、より細かい権利を得るにはフックを使用して完了する必要があります
。Gitには直接の権利管理がなく、フックで制御する必要があります。リポジトリ間のプッシュまたはプル中）

  • 使用可能なフック：ClearCaseアクションは、トリガーと呼ばれるフックのターゲットにすることができます。これは、前操作または後操作にすることができます。

  • CLI管理：cleartoolは、すべてのアクションを実行できるコマンドラインインターフェイスです。

于 2009-03-14T11:10:07.893 に答える
19

ClearCase は非常に使いやすいです。遅く、バグが多く、高価です。CCの使用に対処するために私が行ったことのいくつかは次のとおりです。

  1. チェックインするときは、常に良いコメントを入力してください。
  2. 一般的な構成仕様を使用し、頻繁に変更しないでください。
  3. VPN または低速のネットワーク接続で CC を使用しないでください。
  4. 起動時に CC Doctor の読み込みをオフにします。
  5. ファイルを別のディレクトリに移動しないでください。
  6. ファイルごとに少なくとも 2 分のチェックイン時間をスケジュールします。
  7. スナップショット ビューは低速ですが、動的ビューは低速です。
  8. 予約済みのファイルとマージは面倒なので、開発の習慣として早期に頻繁にチェックインしてください。
  9. デフォルトでは、すべての開発者が予約されていないファイルをチェックアウトします。
于 2009-03-14T00:01:32.963 に答える
16

私たちは CC を 15 年以上使用しています。多くの優れた機能があります。

すべての開発はブランチで行われます。今日、いくつかの異なる変更セットのために、いくつかを作成しました。ブランチにチェックインしたとき、同僚に変更を確認してもらい、/main/LATEST にマージして戻しました。ブランチの古いリリースの場合は、それほど難しくはありませんでした。

私の一時ブランチからのマージは完全に自動化されていました。私がファイルをチェックアウトしている間、誰も私が作業していたファイルを変更していませんでした。デフォルトではチェックアウトは予約 (ロック) されていますが、後でいつでもチェックアウトの予約を解除したり、未予約のチェックアウトを作成したりできます。変更に数日かかる場合、一時ブランチとメイン ブランチの再同期は簡単で、通常は自動的に行われます。マージツールは問題ありません。私にとっての最大の問題は、私のサーバー マシンが私のオフィス (または自宅) から 1800 マイルほど離れていることです。より優れたマージツールを使用したことはありませんが、他のグラフィカルなマージツールを使用したことがないため、あまり意味がないかもしれません。

ビュー (動的ビュー) はセットアップで高速です。私はスナップショット ビューを使用したことはありませんが、できる限り Windows で作業していません (私たちのチームは Windows でスナップショット ビューを使用していますが、その理由はわかりません)。複雑な分岐システムがありますが、メインの開発は /main/LATEST で行い、リリース作業は分岐で行います。GA 後、リリース固有のブランチでメンテナンス作業が行われ、(中間バージョンを介して) /main/LATEST にマージされます。

CC には確かに優れた管理者が必要です。

CC を使用するのは簡単ではありませんが、現時点では、「git」は CC を使用したことがない人にとっては気が遠くなるようなものだと思います。しかし、チェックアウト、変更、チェックイン、マージ、ブランチなどの基本はほとんど同じです。ディレクトリは (慎重に) 分岐することができ、確実にバージョン管理されています。それはかけがえのないものです。

オフィスが CC から切り替わる様子は見られません。

埋め込まれたバージョン番号 - 善か悪か?

私が書いた：

私が CC で抱えている最大の問題は、バージョン番号がソース ファイルに埋め込まれていないことです。これは、git にも問題があることです。理由は半分わかります。ただし、その追跡可能性を放棄するのが好きかどうかはわかりません。そのため、私は今でもほとんどの個人的な作業に RCS (CVS でさえも) を使用しています。ある日、私は git に切り替えるかもしれませんが、それは衝撃であり、(SCCS と) RCS を中心に構成されたリリース システムを再構築するために多くの作業が必要になるでしょう。

それに応じて、@VonC は次のように述べています。

私たちは常にその行為を悪 (メタデータ情報をデータに混ぜること) と考え、「マージ地獄」を導入しました。Java ファイル内の Clearcase ファイル バージョンを取得する方法も参照してください。もちろん、適切なマージ マネージャーを使用すれば、RCS キーワード置換のトリガーを使用できます ( Clearcase マニュアル: Checkin Trigger Example ) 。

この議論によっていくつかの問題が明らかになり、それらはすべて混ざり合っています。私の見解は時代遅れに近いものですが、その背後には理論的根拠があり、時間をかけてそれらを書き留めます (人生で台無しにされました - これを完了するには、いくつかの編集が必要になる場合があります)。

バックグラウンド

私が SCCS を学んだのは 1984 年、RCS がリリースされた頃 (1983 年だったと思います) ですが、SCCS は私のマシンにあり、インターネットはせいぜい初期の段階でした。SCCS の日付形式は 2 桁の年を使用し、SCCS が普遍的に時間的に固定されるかどうかが明確ではなかったため、90 年代半ばに、しぶしぶ SCCS から RCS に移行しました (固定されていました)。いくつかの点で、RCS は SCCS ほど好きではありませんが、いくつかの良い点があります。商業的には、私の雇用主は 1995 年半ばまで SCCS を使用していましたが、1994 年初頭から Atria ClearCase に切り替え始め、一度に個別の製品セットに取り組みました。

トリガーを使用した初期の ClearCase 実験 - そして Merge Hell

私たちのプロジェクトは、CC の経験がすでにある程度あった後で移行しました。せっかくなので、チェックイン トリガーを介してソース ファイルにバージョン管理情報を埋め込みました。VonC が述べているように、これはマージ地獄につながるため、これはしばらく続きましたが、ほんのしばらくの間でした。問題は、タグ /main/branch1/N を持つバージョンが共通のベース バージョン /main/B から /main/M とマージされる場合、ファイルの抽出されたバージョンには、各バージョンで編集された単一の行が含まれることです -紛争。そして、その競合は自動的に処理されるのではなく、手動で解決する必要があります。

現在、SCCS には ID キーワードがあります。ID キーワードには、編集中のファイル用と編集されていないファイル用の 2 つの形式があります。

Edit         Non-Edit
%I%          9.13
%E%          06/03/09
%Z%          @(#)
%M%          s.stderr.c

編集可能なバージョンの SCCS ファイル (%x% 表記を使用) の 3 方向のマージを試みた場合、メタデータを含む行で競合は発生しません。ただし、これらの行のメタデータを変更しない限り (たとえば、US-スタイル %D% 日付から英国スタイル %E% 日付へ - SCCS は ISO スタイルの 2009-03-15 日付を標準としてサポートしていません。)

RCS にもキーワード メカニズムがあり、キーワードにも 2 つの形式がありますが、1 つはまだ RCS に挿入されていないファイル用で、もう 1 つは次のようなファイル用です。

Original       After insertion
$Revision$     $Revision: 9.13 $
$Date$         $Date: 2009/03/06 06:52:26 $
$RCSfile$      $RCSfile: stderr.c,v $

違いは、キーワードに続く「$」と「:」、スペース、テキスト、スペース、そして最後に「$」です。私は RCS とのマージを十分に行っていないため、RCS がキーワード情報をどう処理するかを確認していませんが、(拡張された素材の内容に関係なく) 拡張表記と「縮小」表記の両方を同等に扱った場合、マージは可能であることに注意してください。チェックイン後に結果のファイルが取得されると、適切に展開されます。

ClearCase の問題は、適切なマージ マネージャーがないことです。

SCCS と RCS の説明で示したように、正しい (短縮または編集可能な) 形式でキーワードを処理して 3 方向のマージが行われる場合、マージの競合は発生しません。

CC の問題点 (この観点からすると - CC の実装者は明らかに同意していません) は、キーワードを処理するシステムが欠けているため、適切なマージ マネージャーも欠けていることです。

キーワードを処理するシステムと適切なマージ マネージャーがあれば、次のようになります。

  • システムは、適切なマーカーでメタデータをファイルに自動的に埋め込みます。
  • マージ時に、システムは、マーカーが別の方法で変更されない限り、メタデータ マーカーを含む行が競合しないことを認識し、メタデータ コンテンツを無視します。

これの欠点は、メタデータ マーカーを認識して特別に処理する特別な差分ツールが必要であるか、差分ツールに供給されるファイルを正規化する必要があることです (メタデータ マーカーは中立的な形式に縮小されます - $Keyword$ またはRCS および SCCS 用語では %K%)。このちょっとした余分な作業が、サポートされていない理由だと確信しています。これほど強力なシステムでは近視眼的であると常に感じていました。私は、RCS や SCCS 表記法に特にこだわりはありません。SCCS 表記法の方がいくつかの点で扱いやすいですが、本質的に同等です。また、同等の表記法を使用することもできます。

ファイル内のメタデータが優れていると思う理由

私のソース コード (私の雇用主のソース コードとは対照的に) は、ソース コード管理システムの庇護の外に配布されているため、ソース コードにメタデータを含めるのが好きです。つまり、ほとんどがオープン ソースです。すべてのユーザーが利用できるようにしています。誰かがファイル、特に変更したファイルの問題を報告した場合、どこから始めたかを知ることが役立つと思います。それは、ソース ファイルの元のメタデータによって表されます。

ここで、SCCS には RCS よりも利点があります。SCCS キーワードの拡張形式は通常のテキストと見分けがつきませんが、RCS キーワードは引き続きキーワードのように見えます。これは、SCCS では同じように発生しない問題です (他の人がメタデータを上書きする作業を行う必要があります)。

したがって、誰かが私のソース コードのチャンクを取得して変更したとしても、通常、それがどのバージョンに基づいているかを推測するのではなく、それがどこから来たのかを特定するのに十分なラベルが含まれています。そしてそれは、問題のどの部分が私が作ったもので、どの部分が彼らが作ったものなのかをより簡単に理解できるようにします.

さて、実際には、オープンソースの仕組みでは、人々はあなたが思っているほどコードを移行しません。次の公式リリースが作成されたときに逸脱するとコストがかかりすぎるという理由だけで、彼らはリリースされたバージョンにかなり厳密に固執する傾向があります.

あなたの作品に由来し、その後改訂されたソース コードの一部のベース バージョンをどのように判断すればよいのかわかりません。ただし、正しいバージョンを見つけることがそれを行うための鍵と思われます。コードにフィンガープリントがあれば、より簡単になる可能性があります。

以上が、私がソース ファイルにバージョン情報を埋め込むのが好きな理由の適度な要約です。それは大部分が歴史的なものです - SCCS と RCS の両方がそれを行いました。DVCSの時代に別れを告げるべき古代の遺物かもしれません。しかし、私はまだそれについて完全に確信しているわけではありません。しかし、私のリリース管理メカニズムの内外を説明して、なぜ私がそうしているのかを理解するには、さらに多くのエッセイが必要になるかもしれません。

推論の 1 つの側面は、'stderr.c' や 'stderr.h' などの主要なファイルが、基本的にすべてのプログラムで使用されているということです。それを使用するプログラムをリリースするときは、バックバージョンを必要とするインターフェイスの変更がない限り、最新バージョンであることを確認するだけです。しばらくの間、その問題は発生していません (2003 年に体系的な名前の変更を行いました。これにより、いくつかの移行の頭痛の種が発生しましたが、Perl スクリプトを使用すると、名前の変更を非常に簡単に実装できました)。そのコードを使用するプログラムの数はわかりません。100 から 200 の間のどこかが公正な推測です。今年の一連の変更 (バージョン 9.x シリーズ) は、まだいくらか推測的なものです。私はそれらを保持するかどうかを最終的に決定していません。それらは実装の内部にもあり、外部インターフェイスには影響しません。まだ決心する必要はありません。gitを使用してそれを処理する方法がわかりません。ソフトウェアをビルドする前にインストールしなければならないライブラリに、ライブラリ コードをビルドしたくありません。これは、クライアントにとって負担が大きすぎます。したがって、各プログラムは引き続きライブラリ コードのコピーと共に配布されますが (別の種類の厄介な問題です)、ライブラリ全体ではなく、プログラムが必要とするライブラリ コードのみが配布されます。そして、どのライブラリ関数を使用するかをプログラムごとに選択します。したがって、サブツリー全体をエクスポートすることはありません。実際、ライブラリ コードの最後の変更をカバーしたコミットは、通常、プログラムの最後の変更をカバーしたコミットとはまったく無関係です。git がライブラリ用に 1 つのリポジトリを使用し、それを使用するプログラム用に別のリポジトリを使用する必要があるのか​​、それとも共通のより大きなリポジトリを使用する必要があるのか​​さえわかりません。

OK - 十分にうんざりしています。私が持っているものは私のために働きます。必ずしもすべての人に当てはまるわけではありません。VCS に特別な要求をするわけではありませんが、ファイルにバージョン メタデータを埋め込む必要があり、CC と Git と (私が思うに) SVN には問題があります。それはおそらく私が問題を抱えていることを意味します-失われた過去のハングアップ. しかし、私は過去が提供しなければならないものを大切にしています。(私のコードのほとんどは分岐されていないので、私はそれを回避できます。分岐によってどれだけの違いが生じるかわかりません。)

于 2009-03-14T05:07:03.930 に答える
4

私は約 6 年間 clearcase を使用してきましたが、一般的には許容できるものでした。一定の学習曲線がありますが、癖に慣れると、ほとんどスムーズに作業できます。自分が何をしているかを知っている非常に有能な CC 管理者は、些細な設定以外には不可欠です。あなたがそれを持っていない限り、人々は問題に遭遇し、すぐに「ClearCase」の問題について話題になるでしょう。その後、経営陣は他のものに切り替えることで介入する必要があり、関係者全員の時間を無駄にするだけです. CC は悪い製品ではありませんが、よく理解されていないことがあります。

私が重要だと思ったいくつかの概念を次に示します。これらのいくつかは、完全に CC のみを指向しているわけではありません。

  • チェックアウトは、通常の CVS に似たチェックアウトの概念とは異なります。チェックアウトすると、チェックインするまでファイルがロックされます。
  • ファイルの移動には問題ありません。実際、これは問題なく動作します。
  • バージョン ツリーは、ファイルに何が起こっているかを理解するために不可欠です。アクティブなファイルでは非常に乱雑になる可能性がありますが、それらを見ることに慣れると、非常に便利なツールになり、SVN などの他のソース管理ツールに (ある程度) 欠けているものになります。
  • どのような状況でも動的ビューを使用しないでください。それはそれだけの価値はありません。
  • 新しいブランチ、ストリーム、またはプロジェクトを作成する前に、管理者にアドバイスして、作成したものが本当に最適なものであることを確認してください。新しいコードベースを開始するときは、事前に計画して、最初からストリームとプロジェクトのレイアウトを正しく取得してください。後で変更することは、可能であれば本当に頭痛の種です。
  • ユーザーの権限を微調整し、一般的なイベントのトリガーを設定して、よくある間違いを防止したり、ポリシーを適用したりします。サーバーは非常に構成可能であり、遭遇するほとんどの問題にはおそらく妥当な解決策があります。
  • 基本的な概念から高度な操作まで、開発者を教育します。cleartool を使用して問題の原因を特定できるパワー ユーザーは、管理者の負担を軽減します。
  • ぶら下がっているストリームとビューを放置しないでください。開発者がプロ​​ジェクトを離れるときは、自分のマシンにあったすべてのビューを削除し、すべてのプライベート ストリームを削除する人が必要です。サーバーをクリーンに保たないと、サーバーが汚れ、時間の経過とともに遅くなります。すべてのストリームとビューで「すべてのチェックアウトを検索」を実行すると、存在しない人によってチェックアウトされたファイルは表示されません。
  • 最近の変更と競合するコードを配信するときに、人々が「統合ストリームを壊す」ことを避けるために、子ブランチに「配信前に常にリベースする」ポリシーを義務付けます。
  • 継続的インテグレーション- 各開発者またはチームが独自のブランチで作業している間、インテグレーション ストリームを停滞させないでください。X回ごとに1回、安定した変更を提供しない場合、全員が少なくとも最新の統合ベースラインにリベースする必要があることを義務付けます。特に大規模なプロジェクトでは、これを行うのは非常に困難ですが、もう 1 つの選択肢は「統合地獄」であり、月末に 3 日間誰も何もしません。
于 2009-03-14T00:35:38.293 に答える
4

ClearCase の上で git を使用する方法!

于 2009-03-14T04:51:13.903 に答える
1

私は、ClearcaseとSVNの両方を使用して、多くの中規模から大規模のプロジェクトに成功して取り組んできました。どちらも優れたツールですが、それらを使用するチームには文書化されたプロセスが必要です。バージョン管理システムの使用方法を説明するプロセスを作成します。

1）バージョン管理システムのベストプラクティスドキュメントを見つけるか作成します。これがSubversion用のものです。Clearcaseプロセスに適合させてください。すべての開発者は、同じゲームプランを順守する必要があります。

基本的に、「常に分岐する」か「分岐しない」かを決定します。

決して分岐しないスキーム：

  • 分岐しないスキームは、ファイルがチェックアウト中にロックされ、チェックイン中に使用可能になる場合にSourceSafeが使用するスキームです。このスキームは、小規模（1人または2人の開発者）のチームプロジェクトに適しています。

常に分岐スキーム：

  • 常にブランチスキームとは、開発者がバグ修正または機能追加ごとにブランチを作成することを意味します。このスキームは、大規模なプロジェクト、Clearcaseの/ main /LATESTまたはSVNの/trunkに許可される変更を管理するリード（buildmeister）を持つプロジェクトに必要です。
  • 常に分岐するスキームは、ビルドを壊すことを恐れずに頻繁にチェックインできることを意味します。ビルドを中断する唯一の機会は、バグ修正または機能が完了し、それを/ main/LATESTにマージした後でのみです。

「必要に応じて分岐する」は妥協案であり、多くのプロジェクトに最適です。

2）Clearcase（およびSubversion）を使用する場合は、マージする方法を学ぶ必要があります。マージは友達です。Clearcaseのマージ機能の使用方法、またはBeyondCompareやemacs-diffなどのツールの使用方法を学びます。プロジェクトが適切にモジュール化されている場合（多くの小さな分離ファイル）、マージ中の競合が少ない（またはない）というメリットがあります。

3）お楽しみください。

于 2009-03-14T02:27:39.180 に答える
1

ClearCase を使用している場合は、付属の UCM と複合コンポーネントを必ず使用してください。

これにより、すべての分岐/マージが簡単になります。私は、デルタの 99.9% を自動的に解決するディレクトリの名前変更、ファイルの名前変更などを含む、6 か月間実行される主要な再編成ブランチについて話しています。

また、動的ビューではなく、SnapShot ビューのみを使用します。スナップショット ビューは、ネットワーク ドライブから同じソース ツリーをドラッグ アンド ドロップ (Windows) するよりも速くロードされます。

UCM について私が持っている唯一の不満は、履歴がコンポーネントにまたがることができないということです。コンポーネントを複数の新しいコンポーネントに分割すると、新しいコンポーネントはそれぞれ /main/0 から始まります。

于 2011-01-05T20:05:01.533 に答える