ClearCaseは使用する獣です。遅く、バギーで、高価です。 CCの使用に対処するために行ったいくつかのことは次のとおりです。
- チェックインするときは、常に良いコメントを入れてください。
- 共通の構成仕様を使用し、あまり頻繁に変更しないでください。
- VPNまたは低速のネットワーク接続でCCを使用しないでください。
- 起動時にCC Doctorのロードをオフにします。
- ファイルを別のディレクトリに移動しないでください。
- チェックインのファイルごとに少なくとも2分をスケジュールします。
- スナップショットビューは低速ですが、動的ビューは低速です。
- 予約済みのファイルとマージは苦痛であるため、頻繁に早期にチェックインする開発習慣を作成します。
- デフォルトでは、すべての開発者に未予約のファイルをチェックアウトさせます。
私たちはCCをわずか15年以上使用しています。多くの優れた機能があります。
すべての開発はブランチで行われます。今日は、いくつかの異なる変更セットのために、いくつかを作成しました。ブランチにチェックインしたときに、同僚に変更を確認してもらい、/ main/LATESTにマージしました。ブランチでの古いリリースであれば、それほど難しくありませんでした。
一時的なブランチからのマージは完全に自動化されていました。誰も私がチェックアウトしている間に作業したファイルを変更していませんでした。デフォルトではチェックアウトは予約（ロック）されていますが、後でいつでもチェックアウトを予約解除するか、チェックアウトを予約せずに作成できます。変更に数日かかる場合、一時ブランチとメインブランチの再同期は簡単で、通常は自動的に行われます。 mergetoolは問題ありません。私にとって最大の問題は、サーバーマシンがオフィス（または自宅）から1800マイルほど離れているため、その遠方のXが少し遅いことです（しかし、耐えられないほどではありません）。私はより良いマージツールを使用していませんが、他のグラフィカルなマージツールを使用していないので、それはあまり意味がありません。
ビュー（動的ビュー）は、セットアップでは高速です。スナップショットビューを使用したことはありませんが、Windowsでサポートできる場合は動作しません（私たちのチームはWindowsでスナップショットビューを使用しています。理由はわかりません）。複雑な分岐システムがありますが、主な開発は/ main/LATESTで行われ、リリース作業は分岐で行われます。 GAの後、リリース固有のブランチで保守作業が行われ、（中間バージョンを介して）/ main/LATESTにマージされます。
CCには優れた管理者が必要です-私たちには彼らがいて、そうすることで幸運です。
CCを使用するのは簡単ではありませんが、現時点では、CCを使用していない人にとってCCと同じくらい「git」は気が遠くなると思います。ただし、チェックアウト、変更、チェックイン、マージ、ブランチなど、基本はほとんど同じです。ディレクトリは分岐することができます-慎重に-確かにバージョン管理されています。それは非常に貴重です。
オフィスがいつでもCCから切り替わることはありません。
埋め込みバージョン番号-善か悪か
私が書いた：
私がCCで抱えている最大の問題は、バージョン番号がソースファイルに埋め込まれていないことです。gitにもある問題です。理由は半分しかわかりません。ただし、その追跡可能性を放棄するのが好きかどうかはわかりません。ですから、私は今でもほとんどの個人的な仕事にRCS（CVSでさえも）を使用しています。ある日、私はgitに切り替えるかもしれません-しかし、それは衝撃であり、（SCCSおよび）RCSの周りに構成されたリリースシステムを再構築するのに多くの作業が必要になります。
応答として、@ VonCは次のことに注意します。
私たちは常に、その実践を悪（メタデータ情報をデータに混ぜる）と見なし、「地獄を併合」しました。参照 Java file 内のClearcaseファイルバージョンを取得する方法。もちろん、RCSのトリガーを使用できます。キーワード置換（ Clearcaseマニュアル：チェックイントリガーの例 ） 適切なマージマネージャーを使用する場合 。
この議論によっていくつかの問題が明らかになり、それらはすべて混ざり合っています。私の見解は古風なものに近づいていますが、その背後にある理論的根拠があり、それらを書き留めるのに時間をかけます（人生によって台無しにされます-これを完了するにはいくつかの編集が必要な場合があります）。
バックグラウンド
1984年に、RCSがリリースされた頃（1983年、私は信じている）にSCCSを学びましたが、SCCSは私のマシンにあり、インターネットはせいぜい初期の段階でした。 90年代半ばにSCCSからRCSに移行しました。SCCSの日付形式では何年も2桁を使用しており、SCCSが時間内に普遍的に修正されるかどうかは不明でした。いくつかの点で、SCSほどRCSが好きではありませんが、いくつかの良い点があります。商業的には、私の雇用主は1995年半ばまでSCCSを使用していましたが、1994年初頭からAtria ClearCaseへの切り替えを開始し、個別の製品セットに1つずつ取り組みました。
トリガーを使用した初期ClearCase実験-マージヘル
私たちのプロジェクトは、CCでの経験がすでにあったときに、後で移行しました。その理由の1つは、チェックイントリガーを介してソースファイルにバージョン管理情報を埋め込んだことです。これはしばらく続きましたが、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と十分にマージしていませんが、拡張された表記と「縮小された」表記の両方を（拡張された素材のコンテンツに関係なく）同等のものとして扱った場合、マージできることに注意してください競合することなく行われ、マージの出力に短縮表記が残ります。これは、チェックイン後に結果ファイルが取得されるときに適切に展開されます。
ClearCaseの問題は、適切なマージマネージャーがないことです。
SCCSとRCSの説明で示したように、3方向のマージが正しい（縮小または編集可能な）形式でキーワードを処理して行われた場合、マージの競合はありません。
CCの問題（この観点から-明らかに、CCの実装者は同意しません）は、キーワードを処理するシステムが不足しているため、適切なマージマネージャーも不足していることです。
キーワードと適切なマージマネージャを処理するシステムがあれば、次のようになります。
- システムは、適切なマーカーでファイルにメタデータを自動的に埋め込みます。
- マージ時に、システムは、マーカーが異なるように変更されない限り、メタデータマーカーのある行が競合しないことを認識します-メタデータコンテンツを無視します。
この欠点は、メタデータマーカーを認識して特別に処理する特別な差分ツールが必要なこと、または差分ツールに供給されるファイルが正規化されることを必要とすることです（メタデータマーカーはニュートラル形式-$ Keyword $またはRCSおよびSCCS用語では％K％）。この少しの余分な作業が、それがサポートされない理由であると確信しています。これは、このような強力なシステムでは近視眼的であるといつも感じていました。 RCSまたはSCCS表記法への特定の添付ファイルはありません-SCCS表記法はいくつかの点で扱いやすいですが、本質的に同等です-そして、同等の表記法を使用できます。
ファイル内のメタデータがまだ良いと思う理由
私のソースコードは（雇用者のソースコードではなく）ソースコードの Aegis の外側に配布されるため、ソースコードにメタデータを含めるのが好きです。制御システム。つまり、それはほとんどがオープンソースです-私はそれをすべての人が利用できるようにします。誰かがファイル、特に変更したファイルの問題を報告した場合、どこから始めたのかを知ることが役立つと思います。それはソースファイルの元のメタデータによって表されます。
ここで、SCCSはRCSよりも利点があります。SCCSキーワードの拡張された形式は通常のテキストと区別できませんが、RCSキーワードはキーワードのように見え続けるため、他の人がマテリアルを自分のRCSリポジトリにインポートした場合、メタデータが置き換えられます私のメタデータ、同じ方法でSCCSで発生しない問題（他の人はメタデータを上書きする作業をしなければなりません）。
その結果、誰かが私のソースコードのチャンクを取り、それを変更したとしても、それがどのバージョンに基づいているのか推測するのではなく、それがどこから来たかを識別するのに十分なラベルが通常あります。そして、それにより、問題のどの部分が自分の作っているのか、どの部分が自分の作っているのかを簡単に確認できます。
さて、実際には、オープンソースの仕組みでは、人々はあなたが思うほどコードを移行しません。彼らはリリースされたバージョンにかなり密接に固執する傾向があります。単に次の公式リリースが行われるときに逸脱が高すぎるためです。
あなたの作品から生まれ、それ以来改訂されているソースコードの基本バージョンをどのように決定するのか、私にはわかりません。しかし、正しいバージョンを見つけることはそれを行うための鍵のようです。コードに指紋があれば、それはより簡単になります。
だから、それは私がソースファイルにバージョン情報を埋め込むのが好きな理由の中程度の要約です。それは大部分が歴史的です-SCCSとRCSは両方ともそれをしました、そして私は彼らがしたという事実が好きでした。 DVCSの時代に別れを告げられる何か、古代の遺物かもしれません。しかし、私はまだそれで完全に納得していません。ただし、リリース管理メカニズムの詳細を説明するためには、なぜ私がそうするのかを知るために、さらに多くのエッセイが必要になるかもしれません。
推論の1つの側面は、「stderr.c」や「stderr.h」などのキーファイルが、本質的にすべてのプログラムで使用されることです。それを使用するプログラムをリリースするとき、単に最新バージョンを使用していることを確認します-旧バージョンを必要とするインターフェースの変更がない限り。私はしばらくの間その問題を抱えていませんでした（2003年に体系的な名前変更を行いました;それはいくつかの一時的な頭痛の種を引き起こしましたが、Perlスクリプトにより名前変更をかなり簡単に実装することができました）。そのコードを使用するプログラムの数はわかりません-100から200の間のどこかが妥当な推測です。今年の一連の変更（バージョン9.xシリーズ）はまだやや推測的なものです。私はそれらを保持するかどうか最終的に決定していません。また、これらは実装の内部にあり、外部インターフェイスに影響を与えないため、まだ決心する必要はありません。 gitを使用してそれを処理する方法がわかりません。ソフトウェアをビルドする前にインストールする必要のあるライブラリにライブラリコードをビルドしたくありません。これはクライアントにとって面倒です。そのため、各プログラムは引き続きライブラリコードのコピー（別の種類の厄介なもの）で配布されますが、ライブラリ全体ではなく、プログラムが必要とするライブラリコードのみが配布されます。そして、使用するライブラリ関数をプログラムごとに選択します。したがって、サブツリー全体をエクスポートすることはありません。実際、ライブラリコードの最後の変更を対象としたコミットは、通常、プログラムの最後の変更を対象としたコミットとは完全に無関係です。 gitがライブラリ用に1つのリポジトリを使用し、それを使用するプログラム用に別のリポジトリを使用するのか、それとも共通の大きなリポジトリを使用するのかさえもわかりません。そして、これを理解するまではgitに移行しません。
OK-十分なウィタリング。私に役立つもの必ずしもすべての人のためではありません。 VCSに特別な要求はしませんが、ファイルに埋め込まれたバージョンメタデータが必要であり、CCとGitおよび（と思う）SVNには問題があります。それはおそらく私が問題を抱えていることを意味します-失われた過去へのハングアップ。しかし、私は過去が提供するものを大切にしています。 （私のコードの大部分は分岐していないので、私はそれで逃げることができます。分岐がどれほどの違いをもたらすかはわかりません。）
Ericのソース管理HOWTO は、ツールに依存しない優れたガイドです。
ClearCaseの上でgitを使用する方法！
私は6年間の大半をクリアケースで作業しましたが、通常は許容範囲内でした。一定の学習曲線がありますが、癖に慣れると、スムーズに作業できます。自分がやっていることを知っている非常に有能なCC管理者は、些細なセットアップ以外には不可欠です。持っていない限り、人々は問題にぶつかり、すぐに「ClearCase」問題について話し合うことになります。その後、経営陣は、関係するすべての人にとって時間の無駄だけを引き起こす他の何かに切り替えることによって介入する必要があります。 CCは悪い製品ではありません。理解が不十分な場合があります。
ここに私が重要だと思ったいくつかの概念があります。これらのいくつかは、CCのみ指向ではありません-
- チェックアウトは、通常のCVSのようなチェックアウトの概念とは異なります。チェックアウトするとき、チェックインするまでファイルをロックします。
- ファイルの移動に問題はありません。実際、これは問題なく機能します。
- バージョンツリーは、ファイルに何が起こっているかを理解するために不可欠です。アクティブなファイルは非常に乱雑になる可能性がありますが、それらを見ることに慣れると、非常に便利なツールになります。
- どのような状況でも動的ビューを使用しないでください。それはそれだけの価値はありません。
- 新しいブランチ、ストリーム、またはプロジェクトを作成する前に、作成したものが本当にあなたに最適なものであることを管理者にアドバイスしてください。新しいコードベースを開始するときは、事前に計画して、最初からストリームとプロジェクトのレイアウトを取得してください。可能であれば、後で変更するのは本当に頭痛の種です。
- ユーザーの特権を微調整し、一般的なイベントのトリガーを設定して、一般的な間違いを防ぎ、ポリシーを適用します。サーバーは非常に構成しやすく、発生した問題のほとんどはおそらく合理的な解決策です。
- 基本的な概念から高度な操作に至るまで、開発者に何かを教育します。 cleartoolを使用して問題の内容を把握できるパワーユーザーは、管理者の負荷を軽減します。
- 宙ぶらりんのストリームやビューを残さないでください。開発者がプロジェクトを離れるとき、自分のマシンで持っていたすべてのビューを削除し、プライベートストリームをすべて削除する誰かがいます。サーバーをクリーンにしないと、...サーバーが汚れ、時間が経つにつれて遅くなります。すべてのストリームとビューで「すべてのチェックアウトを見つける」を実行すると、もはや存在しない人々によってチェックアウトされたファイルが表示されないはずです。
- 最近の変更と競合するコードを配信する際に人々が「統合ストリームを壊す」ことを避けるために、子ブランチに「常に配信前にリベース」ポリシーを義務付けます。
- 継続的な統合 -各開発者またはチームがそれぞれのブランチで作業している間、統合ストリームが停滞しないようにします。安定した変更を提供しない場合、Xごとに1回、全員が少なくとも最新の統合ベースラインにリベースする必要があります。これは実際、特に大規模プロジェクトでは非常に困難ですが、他の選択肢は「統合地獄」であり、月末には3日間何もしません。
私の意見では、分岐およびマージは、ソース管理システムで最も重要な概念です（もちろん、バージョン管理自体の次にあります）。
それがどのように行われるかを理解したら（Clearcaseは非常にうまく機能し、ブランチとして小さな変更を加えてマージするまで、RCSやCVSで行ったことはありません）、あなたはあなたの人生を見つけるでしょうはるかに簡単になります。
どういうわけか話題外ですが、ClearCaseに満足している開発者はほとんど知りません。洗練された機能が必要だと言われましたが、svnとgitのユーザーとしては、gitやSubversionで見逃しているものを考えることはできません。それはClearCaseについて知っておくべきことです-ほとんどの開発者はSubversionまたはgitのような単純なもので作業することを本当に喜んでいます（はい、gitでも把握しやすいです）、そしてClearCaseで最も簡単なタスクを完了する方法を知った後でも、私は持っていましたClearCaseが絶えず感じるのは、私ではなく、私に対してです。
ClearcaseとSVNの両方を使用して、中規模から大規模のプロジェクトに数多く取り組んできました。どちらも優れたツールですが、それらを使用するチームには文書化されたプロセスが必要です。バージョン管理システムの使用方法を説明するプロセスを作成します。
1）バージョン管理システムのベストプラクティスドキュメントを検索または作成します。 Subversionの場合 の1つです。Clearcaseプロセスに合わせて調整してください。すべての開発者は同じゲームプランに従う必要があります。
基本的に、「常に分岐する」か「分岐しない」かを決定します。
決して分岐スキーム：
- Never Branchスキームは、チェックアウト中にファイルがロックされ、チェックイン中に利用可能になるSourceSafeの使用方法です。このスキームは、小規模（1〜2人の開発者）のチームプロジェクトには適しています。
常にブランチスキーム：
- Always branchスキームは、開発者がバグ修正または機能追加ごとにブランチを作成することを意味します。このスキームは、より大きなプロジェクト、Clearcaseの/ main/LATESTまたはSVNの/ trunkに許可される変更を管理するリード（buildmeister）を持つプロジェクトに必要です。
- Always branchスキームは、ビルドを壊すことを恐れずに頻繁にチェックインできることを意味します。ビルドを中断する唯一の機会は、バグ修正または機能が完了し、それを/ main/LATESTにマージした後にのみです。
「必要なときに分岐」は妥協であり、多くのプロジェクトに最適です。
2）Clearcase（およびSubversion）を使用すると、マージを学習する必要があります。マージは友人です。 Clearcaseのマージ機能の使用方法、または Beyond Compare またはemacs-diffなどのツールの使用方法を学びます。プロジェクトが適切にモジュール化されている場合（多くの小さな分離ファイル）、マージ中の競合が少なくなる（またはまったくない）メリットがあります。
3）お楽しみください。
ClearCaseを使用している場合は、ClearCaseに付属のUCMとコンポジットコンポーネントを使用していることを確認してください。
すべてのブランチ/マージが楽になります。私は、99.9％のデルタを自動的に解決するディレクトリ名の変更、ファイル名の変更など、数万件の変更を伴う6か月間実行される主要な再編成ブランチについて話しています。
また、動的ビューではなく、スナップショットビューのみを使用します。スナップショットビューは、ネットワークドライブから同じソースツリーをドラッグアンドドロップ（Windows）するよりも速くロードされます。
私がUCMについて持っている唯一の不満は、歴史がコンポーネントにまたがることができないということです。コンポーネントを複数の新しいコンポーネントに分割すると、各新しいコンポーネントは/ main/0から始まります。
何度も役立つ非常に便利なコマンドcleardescribeがあります。ラベルとブランチの詳細を取得するために使用できます。構文は次のとおりです。
cleardescribe lbtype:<LABELNAME>@\<VOB-NAME>
cleardescribe brtype:<BRANCHNAME>@\<VOB-NAME>
具体的には、これにより、どのブランチにどのラベルが適用され、どのブランチが問題のブランチの親ブランチであるかがわかります。
プロジェクトにバージョン管理ツールをどのように実装するかは、プロジェクトの規模と範囲、チームの以前の経験に依存します。 ClearCaseは、開発者の大規模プロジェクトやプロジェクトの規模に適した素晴らしいツールです。ブランチの管理は、バージョン管理ツールを使用する際の非常に重要な見通しの1つです。分岐してマージすることなく、プロジェクトのライフサイクル中のケーキウォークです。しかし、それをロックして素晴らしい並列開発を可能にするので、なぜマージするのを避けられません。