ClearCaseの利点/欠点
現在、IBM Rational ClearCaseの習得に苦労しているため、専門家の意見を聞きたいと思います。
SubversionやGitのような他のバージョン管理システムと比較した場合の利点/欠点に特に興味があります。
コストはかなり明らかな欠点です。ライセンス費用だけでなく、ClearCaseの第一人者の給与の費用もかかります。 ClearCaseを使用していることを知っているほとんどすべての会社には、手に負えない獣を飼いならすことだけを目的とする人が少なくとも1人いるようです。
フルタイムの乳母を必要とするほど複雑であるという事実も心配です。
システムの絶対的な悪夢。 VSSに戻れたらいいなと思った！（気にしないmodernSubversionやGitのようなソース管理システム！ ）
- slooooowです。
- dynamicビューを使用し、ネットワークがダウンすると、ソースの作業コピーにアクセスできませんになります。修正するにはsit and waitしかできません。
- snapshotビューを使用すると、常に競合および「ハイジャックされた」ファイルに遭遇するように見えるため、作業コピーのファイルはソースリポジトリとまったく同じになることはありません。
- 大規模な更新または配信操作を試みるたびに常に[〜＃〜] fails [〜＃〜 ]何らかの理由で、ClearCaseの第一人者がそれを理解するのに数時間/日を費やす必要があります。そうそう、あなたはmust専用のフルタイムClearCaseの第一人者が必要です！
- 失敗すると、しばしばロールバックできません操作であるため、進行中の操作にとどまり、開発者はブロックされますになります。
- Pretty（？）アイコンを過ぎて見ると、GUIは非常に貧弱です-完全なファイルパスを表示するためにウィンドウのサイズを変更できないなどのことです！
- 彼らのsupportスタッフは何も修正することを非常に嫌がります。最初の応答は常に「これは仕様による」および「回避できますか？」です。彼らが最終的に修正を提供する場合（多くの議論の後）、それは最も差し迫った問題に対する最も基本的な修正です。
基本的に、それは遅く、複雑で、地獄のように信頼できません。ああ、私はとんでもないくらい高い？彼らがおそらくそれを売ることができる唯一の方法は、その製品を一度も使ったことのない意思決定者と話すことです！世界中のどの開発者もそれを購入することはないと確信しています。
アトミックコミットとチェンジセットは、ClearCaseに対する最大の不満です。バグ修正またはリファクタリングの一環として5つのファイルをチェックインするとします。その後、何かが台無しになったことが発見され、元に戻す必要があります。それらがどの5つのファイルであり、それぞれのバージョンがどのバージョンである必要があるかを見つけてください。しかし、一歩後退しましょう。これらの5つのファイルの編集が終了したので、コミットします。最初の4つは問題ありません。最後の1つは大規模なマージが必要です。他の4つのファイルは既にチェックインされています。最後のファイルで必要な変更を完了するのを待ちません。誰も更新しないか、動的ビューを使用していないことを期待しています。継続的統合ビルドサーバーも失敗します。
チェックインする必要のあるファイルで完全な新しいディレクトリを作成することもありますが、完了するまでチェックインしたくない場合があります。それは早いですし、すべてがまだ不安定です。だから、すぐに削除するかもしれないことをチェックしてください。 OK、今のところ大丈夫です。ここでチェックインします。新しく作成したフォルダーをソース管理に追加します。 ClearCaseは再帰的ではないため、singleフォルダーのみがチェックインされます。SVNを使用すると、そのフォルダーとその下のすべてが選択に応じて追加されます。開発者はすべてを追加することを忘れないでください。そうしないと、多くのファイルが失われます。
ClearCaseはファイルとフォルダーを所有しているため、最初にチェックアウトしていない限り、何も変更できません。 Eclipseプラグインは、ここで多くの迷惑を取り除きます。最初にチェックアウトするのを忘れていたことがわかるように、viでファイルを開いて簡単な変更を加えた回数を説明することはできません。チェックアウトも再帰的ではありません。
変更セットがないと、更新が非常に遅くなる可能性があります。スナップショットビューで更新すると、変更されたファイルだけでなく、すべてのファイルが更新されます。 20,000以上のファイルを含むプロジェクトに取り組みました。仕事用のマシンにリモート接続し、更新を開始してから、仕事に向かいます。コーヒーを得る;それが終わっている間に私の机に行きます。それは誇張のように聞こえるかもしれませんが、悲しいことにそうではありません。
動的ビューは、非常に小さなチームに属さない限りひどいものです。もしそうなら、なぜClearCaseを持っているのでしょうか？誰かが他のすべての人の意見を壊したファイルをチェックインしたため、無数の人々の意見がうんざりしているのを見てきました。独自のビューで競合を常に更新およびマージする必要があります。そのように、変更はあなただけに影響します。動的ビューの場合、プッシュアップする前にマージダウンすることはできません。あなたはただコミットして希望します。
コストはおそらく大きな懸念ではないことはわかっていますが、会社のためにお金を稼ぐ開発者は、楽しいイベントや新しい機器のいずれかで5万ドルから1万ドル（一般的な追加であるClearQuestライセンスによって異なります）椅子、モニターなど）。 IBMは、ClearCaseを継続するためのスタッフを配置することをお勧めします。物事がクラッシュしたり燃えたりしないようにするのではなく、それらの人々を再利用して会社の収益を上げてみませんか？
切り替えをしないと聞いたいくつかの理由：
- 学習には時間とお金がかかります
- SVNまたはMercurialの学習には1日もかかりません。 ClearCaseのみが、管理者と開発者の特定の比率を提案しています。
- 移行は苦痛になります
- これがツールが存在する理由です： cc2svn
- それほど簡単ではありません with Mercurial
- セキュリティ
- SVN AFAIKには既知の大きな穴はありません。開発チームは、見つかったものをすぐに修正することに専念しています。国防総省はSVNで問題ないようです。
- その後、実質的な生産性の向上はありません
- 変更セットなしでバグを追跡しようとすると、永遠に時間がかかります。バグが見えなくなるまでロールバックできるのが大好きです。 ClearCaseではできません。
- マルチサイト
- WANdiscoはその問題を解決します。しかし、無料ではありません。
ClearCaseが他のファイルよりも優れているのは、個々のファイルを分岐し、他のファイルを別のブランチと同じトラックに保持することだけです。
Clearcaseで行ったことはすべて、常にhardのようです。一方、他のシステムではそのような印象は一度もありません（CVSを除く）。
SVN、CVS、Clearcase、およびMercurialを使用しました。
ここに挙げた多くの理由から、CCからGitに移行しているところです。 CCや他の商用ソース管理システムから離れる理由を1つ追加したいと思います。
重要なビジネスデータはClearCaseの人質です。それを手に入れることはできません。
重要なビジネスデータは、コード、バージョン履歴、およびコミットコメントなどのすべてのメタデータ、誰がいつチェックインしたかです。
すべてのソフトウェアの耐用年数は限られています。コード、バグ、顧客データなど、重要なビジネスデータを飲み込む新しいシステムを導入するときは、常に自問する必要があります。データを再度取得する方法を教えてください。その質問に答えられない場合、そのシステムを導入すべきではありません。
移行すると、ほとんどの履歴とすべてのメタデータが失われました。基本的に、リリースされたバージョンに対応する履歴のみがありますが、顧客の要求に応じて行われた変更に関する情報は失われます（顧客サポートおよびバグチケットシステムにそのデータがあるため、完全に失われることはありませんが、ソースコードはなくなりました）。
これは、私たちにとって短期間から中期の迷惑と問題の間のどこかになります。数年後には、それはもはや重要ではありませんが、おそらく1〜3年は重要になります。
（CCを他のSCMに移行するための商用ツールがありますが、それらは私たちのニーズに十分であるとは見なされませんでした。実行可能だったとは思いません。
学んだ教訓は次のとおりです。重要なビジネスデータを独自のシステムに委ねないでください。
Everything ClearCaseのあらゆる能力に関連して経験したことは、非効率的で、く、過度に複雑で、遅く、混乱し、高価で不便です。
それはただ間違っているだけのマネージャーやエンジニアを引き付けるようです。
くそー、IBM、およびRationalには、そのようなくだらない製品を販売するための素晴らしい営業スタッフが必要です。
ClearCaseでの私の経験は大惨事でしたが、2番目のDonの声明では、常駐の専門家が必要であると述べています。私はCVSや他のバージョン管理システムの経験があり、概念に精通していましたが、ClearCaseのドキュメントは理解できないため、何度か助けを求めました。さまざまな専門家が実際にcdを壊しましたになるまで矛盾したアドバイスをくれました。つまり、UNIXシェルでClearCaseコマンドを発行した後、「cd」コマンドがエラーメッセージで失敗しました。
バージョン管理システムの基本的なタスクは本当に簡単です。正直なところ、他のユーザーとうまく機能するファイルスキームを使用して、6個のコマンドで十分だと思います。 ClearCaseは、マーケティング担当役員が意図的に地獄を複雑にして、製品を洗練された強力なものにするための結果のように見えます。シンプル、安全、信頼できる方法で動作するように設定できると聞いたことがありますが、やはり専門家のサービスが必要です-箱から出してすぐに使える電動アーミーナイフのようなものです。
アトミックコミットなし
ファイルをチェックインすると、アトミックコミットはサポートされないため、特定の状態に戻すことは非常に困難です。複数のファイルをチェックインする場合、各ファイルはチェックイン自体ではなく、新しいリビジョン（CVSと同様）を取得します。これは重要な機能だと思います。単一のファイルを元に戻したいのではなく、コミットアクション（タスクをマップする必要がある）を完了したいからです。 ClearCaseでは、ラベルを使用して特定の状態にのみ戻すことができます。実際には、チェックインごとにClearCaseラベルを使用するのはやり過ぎであり、実行されません。
クラッピーなユーザーインターフェース
ClearCase ExplorerのGUIは単なる冗談です。使い勝手が悪く、見苦しい。頻繁に必要となるさまざまな機能は提供されていません（たとえば、成果物に再帰的にチェックインする）。 cygwinで使用されるコマンドラインツールcleartoolははるかに優れていますが、ソース管理に新しいファイル/フォルダーを再帰的に追加するなど、まだ利用できないものがあります。これを回避するために50行のコードの長いスクリプトを読んだ場合、頭を笑わなければなりません。
高い管理努力
ClearCaseビーストの管理は、明白または軽量とはほど遠い（CVS、Subversion、Gitなどの他のscmシステムとは異なります）。 ClearCaseの専任の専門家を何人か配置して、実行し続けることを期待してください。
恐ろしいパフォーマンス
SCMツールとのインターフェイス中に開発者を待たせることほど悪いことはありません。これは、ハンドブレーキを有効にして運転するようなものです。それはあなたの脳を遅くし、あなたの仕事も遅くします。スナップショットビューに新しいファイルを取得するには、10Kアーティファクトで約30分かかります。同じ量の更新（アーティファクトが変更されていない）には、約5分かかります。多くのことを実験し、異なる最新のビュー間をジャンプすることは、多くの待機を意味します。ファイルで作業していて、ファイルをチェックインまたは更新する場合はさらに悪化します。チェックアウト、チェックイン、ソース管理サイクルへの追加には約10〜15秒かかりますが、これは明らかに悪夢です。タイプやメソッドの名前変更や移動をリファクタリングしているとき、非常に迷惑になります（多くのファイルが影響を受ける可能性があります）。
分散開発のサポートの欠如
今日、ソフトウェア開発はしばしば分散したものです（開発者は世界中に同じ製品/プロジェクトに取り組んでいます）。 ClearCaseはオフライン作業にはあまり適していないため、明確にこれには適していません。チェックアウト（ファイル/フォルダーを編集する前のアクション）を行うには、ネットワークに接続している必要があります。ここでは、Hijackオプションを使用できますが、これは機能としての回避策です（基本的にはファイルシステムでファイルをロック解除するだけです）。開発サイトがClearCaseサーバーから遠く離れている場合、チェックイン/チェックアウトの遅延が劇的に増加するため、まったく使用できなくなります。 ClearCase Multisite（scm DBレプリカテクノロジー）を使用するなどの回避策がありますが、追加料金を支払う必要があり、管理するのは簡単ではありません。
代替としてのGit
オープンソースの大ファン+サポーターですが、私はまだ良いソフトウェアにお金を払っても構わないと思っています。しかし、IBMのモンスターClearCaseを見ると、ここにはお金を投資しません。これらの欠点はすべて議論されており、さらにIBMは製品を大幅に改善するためにお金を投資していません。最近、Gitのscmを見てみましたが、これは特にClearCaseが大きな強みを持っている分岐+マージ機能で非常に良く見えます。
http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-stay-away-from-clearcase/ から取得した情報
おそらく史上最悪のソフトウェア。私は合理的なものを使用する会社では働きません。ダイナミックビルドでは、CCが完全にクラッシュし、ワークステーションを頻繁に再起動します。ソース管理に何かをプッシュし、CCがそれが最善を尽くすとクラッシュするとどうなりますか？あなたのコードはlost + foundに入れられ、おそらくどこかにバックアップされていますか？いいえ、それは永遠に消えます。そのため、この巨大な高価なソフトウェアを使用するというひどい状況に陥った場合、すべての複製を保管してください。 Rational/IBM良い仕事です。ソース管理、信頼性の最も重要な部分をキャプチャする方法。ゆっくりと死にます。
ClearCaseの欠点-ここで最も詳細な投稿への追加。
マージツールは価値がありません。それはかろうじてあなたを助けます、あなたがした決定を覚えていません、ただ栄光の差分。
マージツールは、マージが必要な場合に確認するためにディレクトリをチェックアウトする必要があります。その少し狂気。
私は仕事でBitKeeperを使用します（Gitを想定します）。競合があったとしても2つのリポジトリをマージするのはコマンドラインでも非常に簡単でユーザーフレンドリーです。 。
すべてのGUIツールには大量のレイテンシが必要です。ファイルで何ができるかを確認するには、高速接続が必要です。そのため、自宅で作業しているファイルでClearCaseツールを右クリックすると、ネットワーク要件が非常に大きいため、高速インターネットを使用して1〜2分かかる場合があります。
チームとビュー仕様が異なる場合、誰かがリポジトリまたはチェックインを完全に台無しにする可能性があります。だれもブランチをチェックアウトできないというのは、非常に正気です。ふさわしいものを提供する適切なビュー仕様が必要です。全体のコンセプトは素晴らしく、柔軟性がありますが、99％の時間は多くの痛みをもたらします。 CCツールはUTF-8を受け入れないため、Microsoft Outlook経由で仕様をメールで送信できないため、コピーして貼り付けることはできません。
私は絶対に何もしない CCについて言ってうれしいです。私は2つの会社で2年間それを使用し、ずっと幸せな気持ちでそれを落としました。また、自宅で自分のプロジェクトを試してみることも不可能なので、自宅でSVNまたはGitを習得し、職場でClearCaseの苦労を強いられます。 CCを自発的に使ったことのある人は誰もいません。職場の一部のマネージャーがCCが救いへの道であると決定し、全員がそれに移行することを強制したため、彼らはそれを使用するだけです。実際、私の最後の会社はCVSからClearCaseに移行し、1年後にClearCaseからSVNに移行しました。それは嫌いだった。
ClearCaseは、ノーと言うことの1つではありません。アリがはびこっている家に住んでいるようなものです。各アリはせいぜいマイナーな不便さですが、侵入はあなたを怒らせます。
ここでいくつかのコメントを実際の投稿に統合しようとしています。いくつかの点を除いて、一方が他方より優れていることを説得するために、私は本当にここにいるわけではありません。
- GitとClearCaseを比較している場合、ニーズをより明確に定義する必要があることを敬意を表して提出します。ClearCaseを「良い」理由で検討している場合、gitはおそらく方程式に含まれていません-信頼するにはあまりにも新しいですエンタープライズレベルのソース管理用、imo。
- ClearCaseは、他のシステムにはないバージョン管理スペースに多くの概念を導入しているため、非常に困難で混乱を招く可能性があります。特にあなたが持っている唯一の経験がドキュメントを読むことである場合、ここの少数の人々の場合のようです。
- ClearCaseは、LANを使用していないVOB=サーバー。多くの複製（マルチサイト）VOBサーバーをリモート開発者に近づけるために使用しますが、リモートサイトが単一の開発者である場合、これは必ずしも実用的ではありません。
- ファイルのバージョン管理またはリポジトリのバージョン管理が必要ですか？これは非常に重要な質問であり、ツールのセット全体を除外する必要があるため、作業が簡単になります。リポジトリのバージョン管理には多くの利点があります（また、いくつかのポスターが主張しているように「新しい」ものではありません-Perforceのような商用ツールは12年以上存在し、Perforceの前でもリポジトリのバージョン管理を行っていたツールがあるかもしれません）それは万能薬ではありません。
- ソース管理システムを十分に大規模にインストールすると、支援が必要になります。ツールを検討するときは、あなたを助ける人を見つけるのがどれほど簡単かを考える必要があります（経験のある求職者、または問題に対処するためにすぐにそこにいるコンサルタント）。メンテナンスフリーのSCMシステムなどはありません。システムが1つあると仮定すると、「多すぎる」管理が必要なシステムを選択するよりも多くの問題が発生します。
- 「動的ビュー」がいかに悪いかを語る人々にあまり注意を払わないでください。使用しているツールに関係なく、悪いSCMポリシーは悪いです。構成管理のポリシーとプラクティスは、選択したツールとは別にする必要があります。賢明な分岐とマージのポリシーを定義しない限り、ツールがコードベース全体を破壊するのを止めるツールはありません。開発者が/ mainに直接コミットすることが賢明なアイデアであると誰かが提案した場合、その会話から離れることをお勧めします。
ClearCaseは素晴らしいツールですが、複雑なツールです。これを回避する方法はありません-「簡易インストール」モードはありません。 :-)技術的な観点から、gitまたはSVNができることはClearCaseができないことはありません（ただし、オープンソースプロジェクトは既に存在する新しい分類法を発明する傾向があるため、用語が異なる場合が多いですが）設計に応じて、特定のシステムの/ harder。 ClearCaseの「スナップショット」ビューは、SVNまたはCVSからリポジトリをチェックアウトした場合と基本的に同じものです。これは、マシン上のソースコードのローカルコピーであり、バージョン履歴をクエリするツールの中央サーバーにポインターが戻ります。作成されたClearCaseサーバーへのネットワーク接続なしでこれらのビューを操作できます。また、別のブランチで作業するために移動するときにリポジトリ全体を再度ダウンロードしないように「リサイクル」できます。例。 「ダイナミックビュー」は、基本的にClearCaseの発明であり、LANの標準動作モードです。これらはSVNリポジトリをチェックアウトするのと同じように見えますが、変更を加えるまで実際にはファイルをコピーしません。この方法では、ビューはすぐに使用可能になりますが、メインのクリアケースサーバーが使用できない場合は明らかに使用できず、高遅延接続での作業には不向きです。また、作成されたサーバーにアクセスできる任意のマシンにネットワークドライブとしてマウントできるという便利さもあるため、Windowsワークステーションが停止した場合、別のワークステーションにログオンしてビューをマウントし、すべてのファイルはVOBサーバー（このブランチで変更していないファイルの場合）またはview_server（作成または変更したばかりのファイルの場合）このビュー）。
また、これは独自の段落に値します。..clearmergeは、入場料だけの価値があります。私の人生でこれまで使用した中で最高のマージツールです。私は、高品質のマージツールが不足しているためにSCMの多くの悪い慣行が開発されたと確信しています。そのため、CVSユーザーはブランチを適切に使用することを学んだことがなく、ブランチングのこの恐怖は特に正当な理由で今日にまで広がっています。
わかりましたが、ClearCaseを使用しない理由を探している場合、見つけるのは難しくありませんが、それは間違った方法だと思います。本当に、ClearCaseを使用しない理由ではなく、ClearCaseを使用する正当な理由を考え出す必要があります。 ClearCaseがツールにとって多すぎる、またはジョブにとって複雑すぎるツールであると想定して、SCMの状況に陥り、それを使用することを奨励する状況があるかどうかを確認する必要があります。 IBMまたはRationalのロゴを所有することは正当な理由ではありません。:-)
以下のすべてのステートメントに「はい」と言うことができない限り、ClearCaseを検討しません。
- 50人以上の開発者が同じコードベースで作業している、または最終的にはそうするでしょう。
- これらの開発者のほとんどは、中央に配置されているか、中央の場所への高スループットで低遅延の接続を持っています。
- SCMポリシーのセットがあり、ClearCaseを使用してそれらのポリシーを実施する方法を特定できます（実際には、あらゆるツールでこれを考慮する必要があります）
- お金は本当に対象ではありません
私の経験は、CC、CVS、SVNによってほとんど制限されています。原則として、CCは技術的に有能であり、エンタープライズ対応であり、最新のVCSと機能的に匹敵します。しかし、それはいくつかの欠陥を持っているため、あらゆる人向けの環境では使用できません。プロセス指向の環境の場合は、おそらくより適切ですが、そのような環境自体が適切であるとは思いませんが。たぶん、軍事用、宇宙用、または医療用ソフトウェアでは、私は知りません。とにかく、これらのドメインに対しても、適切でさらに使いやすいツールがあると思います。
CCは、技術的に優れたVCSであることに加えて、いくつかの顕著な利点があります。
- 動的ビュー
- 素敵なバージョンツリー
- トリガー
- 名前変更を含む適切なマージバージョン管理
私の意見では、それらの使用は最後のものを除いて制限されています。そして、彼らは欠陥を補償しません。動的ビュー理論的には素晴らしいが、実際には常に利用できるとは限らない。バージョンツリーは他のVCSではあまり使用されませんが、CCではブランチの急増により必要になります（6を参照）。私が知っているように、トリガーは非常に詳細で能力がありますが、ほとんどの実用的なタスクにはSVNフックで十分だと思います。そして、主にユーザビリティに関係する欠点について：
- メインユーザーグループの使いやすさという意味で、CCは完全に失敗します：開発者向け。そして、それが、エンタープライズであろうとなかろうと、どんな環境でも決して使用されるべきではないと思う主な理由です。それが無料であったとしても、開発者の時間を無駄にし、彼らを苛立たせることで、それでもあなたの会社のお金を吸うでしょう。この点は、で構成されています。
- 厳密なロックアプローチによる「チェックアウトチェックイン」-複数の開発者向けの単一の開発ブランチを持つリポジトリ組織では、非生産的、リファクタリング、危険であり、危険です。一方、厳密なロックの利点は無視できます。
- 悪いパフォーマンスと高負荷
- マルチサイトなしでは効果的にリモートで使用できません（2が原因）。マルチサイトも高価です。 ClearCase Remoteクライアントは非常に制限されています。
cleartool（バージョン7.1より前）さえも持たず、動的ビューのみを残します。 - オフラインではほとんど使用できません。動的ビューは機能しません。スナップショットビューは、リポジトリへのアクセスなしではチェックアウトできないため、事実上読み取り専用です（1を参照）。ハイジャックは貧弱な選択肢であり、実際、CCがハイジャックされたファイルに対する責任を放棄することを意味します。また、CCでは、オフライン時に以前のリビジョンとの違いを表示できません。 SVNは、オフラインであっても以前のリビジョンとの違いを示すことができます。
- 特にUCMを使用した非常に複雑なモデル：VOB、PVOB、プロジェクト、ストリーム、ブランチ、ビュー、配信、更新、ロード、復元、リベース、マージ、ベースライン、チェックイン、チェックアウト。この概念の半分は余分なものであり、付加価値はありませんが、技術的および概念的な複雑さを増すと思います。 CCに関する基本的なことすら理解している開発者はほとんどいません。
- 枝の増殖。たとえば、多くの場合、リポジトリは開発者ごとのストリームで編成されます（1のため）。 SVNや他のほとんどのVCSでは意味がありません。
- リポジトリ全体のリビジョンはありません。さて、ベースラインと呼ばれる、理解できるような改訂版があります。しかし、ファイルリビジョンが表示され、そのファイルリビジョンの瞬間にリポジトリのスナップショットを取得したい場合、いくつかの問題が発生します。スナップショットビューを作成するには、構成仕様を使用してブラックマジックを実行する必要があります。または、動的ビューが利用可能な場合は、何らかの方法で見つける必要があります。
- 安っぽいユーザーGUI。バージョンツリーは、ニースであっても平凡な使いやすさを備えています。マージツールは残念です。その他の「機能」：サイズ変更できないウィンドウ、一部の場所でのインクリメンタル検索の欠如、マウス中心のインターフェース、1995スタイルのルックアンドフィール、クライアントとプロジェクトエクスプローラー間で分散される奇妙なワークフローなど。
- CCは、まれで膨大なチェックインを引き起こします。ご存知のように、チェックインはsmallで頻繁に行う必要があります。しかし、開発者は通常、CC、ハイジャックファイルとの追加のやり取りを控え、ローカルVCSで、またはVCSをまったく使用せずに作業します（残念ながら多くの場合）。そして、2週間の開発の後、20個のファイルを追加して別の20個のファイルに影響を与える複雑な機能のコミットを開始します。ファイルをハイジャックし、レポからのすべての新しい変更を手動でマージし、すべての競合と不一致を解決する必要があるため、1〜2日続きます。そのプロセスの間、コードはコンパイルできません。これは、いくつかのファイルが正常にチェックインされ、他のファイルはチェックインされないためです。そしてその後、別の2つのファイルをCCに追加するのを忘れたため、コンパイルできません。
- とても高いです
- インフラストラクチャの点で非常に複雑で、専任の管理者が必要です
ClearCaseは、外部から見ると非常に強力なようです。しかし、実際には、基本的なワークフローに使用する必要があるコマンドとオプションの数が非常に多いため、これらはいくつかのエイリアスまたはスクリプトの背後に隠れており、Visual Sourceの使いやすさでCVSよりも強力ではないものになります安全。また、スクリプトで許可されているよりも少し複雑なことをしたいときはいつでも、おなかが痛くなります。
これをGitと比較してください。Gitは外部からは複雑に思えますが、1週間作業すると、完全にコントロールできるようになります。リポジトリモデルは理解しやすく、信じられないほど強力です。簡単に理解できるので、実際には毎日のワークフローの表面の下を掘り下げるのが楽しいです。
たとえば、スナップショットビューでファイルの非HEADバージョンを表示するだけの簡単なタスクを見つけるのに2、3時間かかりましたが、最終的には 完全なハック でした。楽しい種類のハックでもありません。
しかし、Gitでは、一部の変更のみを対話的にコミットする方法（および残りを後で使用する方法など）のように見える一見複雑なタスクを理解することはとても楽しかったし、VCSによってコードを整理し、履歴はVCSの使用方法の偶然ではなく、私に合った方法で履歴を作成します。 「Gitは、「必要がある」と言う必要がないことを意味します」 。
私の仕事では、ClearCase内であっても、あらゆる種類の軽量タスクにGitを使用しています。たとえば、TDDを実行し、多数のテストに合格してリファクタリングしようとするたびにGitにコミットします。最終的にタスクが完了したら、ClearCaseにチェックインします。Gitを使用すると、変更内容を正確に確認できます。 ClearCaseを取得して、いくつかのファイルの差分を生成するようにしてください-それはできません！ Googleを使用して、この問題を回避しようとしたさまざまなハックを見つけてください。これは、バージョン管理がすぐにできることであり、簡単なはずです！ CVSにはこれが何十年もありました！
- 安全な環境で管理する悪夢
- 時代遅れの技術
- 直感的でないGUI
- 高価な
- リソースモンスター
- マイクロソフトへの売り切れ
私の考えでは？それがある唯一の理由は？宗教的にRUPをフォローしている場合。
サポートはひどいです。チケットは何年も開いています。 Eclipseの第一人者は、Javaファイルを分解することで、Eclipseプラグインのバグを約30分でローカルに修正しました。しかし、チケットはまだレベル1のサポートを過ぎていません。それをこっそり閉じたり、「最新バージョンを試す」ために私たちにそれをpingするために（彼らが自分で試すことができる複製レシピを送ったとしても）。
はしけポールに触れないでください。
パフォーマンス。
ClearCaseは強力で安定しています（IFが適切に管理され、監視されています）が、速度が遅くなります。時々地質。
動的なビューのビューは、ビルド時間が非常に長くなります。スナップショットビューは、更新（大規模プロジェクトの昼休み）またはチェックアウト（その日の家に帰る）に時間がかかる場合があります。
開発者は、作業を行う前にクリアケースを見つけるのに半分の時間を費やし、それがわかったら、gitをローカルにインストールし、必要に応じてクリアケースリポジトリにのみプッシュします。
専用のClearcase管理者を採用する必要があります。
ツールセットにはSVNを、スケーリング/ワークフローにはGitをお勧めします。また、可能な限りCCを避けることをお勧めします。 （お金を数えることはありませんが、フルタイムの管理者を必要とするのは使用するのが非常に苦痛であるという事実は冗談です）
私は最近、同様の状況に立ち向かう必要がありました。たぶん、あなたは私の話から学ぶことができます。
私が新しく割り当てられたチームは、複雑でエラーが発生しやすい方法でヘビーウェイトツールを使用していました。私は最初に、選択したツールとプロセスでそれらを販売しようとしました。この試みは惨めに失敗しました。私は、簡単で効果的な環境よりも、このような負担の大きい環境を選択することに驚いた。彼らは懲らしめられたいと思い、痛みを伴うプロセスを使うことは彼らに懲らしめられたと感じたことが判明しました。奇妙に聞こえますが、本当です。他にも多くの誤解がありました。彼らが何を求めているかを理解した後、実際には同じツールスイート（Serena）を使い続けましたが、その構成方法を大幅に変更しました。
あなたへの私のアドバイスは、あなたのチームにとって何が重要かを理解することです。 ClearCaseをリッピングしても、興味を持って話さない限りどこにも行きません。また、彼らが代替を使用したくない理由を見つけてください。基本的に小さな要件を収集し、ツールの選択をニーズに合わせます。あなたのオプションによっては、誰が知っているかによって、Clear Caseが結局最良のオプションになるかもしれません。
私は完全にClearCaseに反対ではありません（利点があります）が、欠点を列挙します。
- ライセンスの制限-ライセンスサーバーにアクセスできないため、自宅で簡単に仕事をすることはできません。ラップトップでスナップショットビューを使用しても、ライセンスを取得できないため、トリックをする必要があります。特別なリモートクライアントがありますが、独自の多くの制限をミックスに追加します
- ライセンスの制限-あまりにも多くの座席しか移動できないため、誰も使用できません。
- 古くなったUnixツール-ClearCaseはUnixシステム上で最適に動作するように見えますが、GUIツールはそこまで悪いです。 ClearCaseのWindows/Unix統合は、あらゆる種類の苦痛をもたらします。
- アトミックチェックインなし
バージョン7.1 CCの新しいバージョンの時点で、必要に応じて機能としてアトミックチェックインが提供されます。個人的に私は本当にそれを望んでいないだろうが、どうやら一部の人々はそれを「不可欠な機能」として見ている。巨大なバージョンのように一度に1つの大きなバルクが必要になることはありません。もう一度...必要な場合は、オンにします。
だから...もはや議論ではありません。
過去4年間、ClearQuest（DR Tracking/change request system）と統合されたUCM ClearCaseを50人以上の開発者と共に使用しました。私たちには、35,000を超えるDRと変更要求を処理する数千を超えるストリームを含む50以上のUCMプロジェクトがあります。この期間中に、公式に600を超える統合配信を行い、同時に最大6つの開発およびリリース作業を行いました。
私は、通常の配信/マージおよび統合ビルドを実行できるバックアップを持つメインのCM/ClearCase担当者です。ネットワークとサーバーはITチームによってサポートされています。私が言えることは、この巨大な開発努力のCM側からは事実上問題がなく、決してショーストッパーではなかったことです。プロジェクト管理者からの要求に応じて新しいプロジェクト（ブランチ）が作成されるたびに、基本的なものと簡単な手順だけでトレーニングされた開発者が彼らに与えられました。
適切なCM/IT/ClearCase/Process/Managementサポートがないため、ClearCaseについて不満を述べた開発者が多すぎます。開発者は、SCMではなく開発に集中するか、ツールの専門家である必要があります。大規模なソフトウェア開発では、予算の少なくとも5〜7％をCMとツールのサポートに費やす必要があります。
ClearCaseは、その上で別のバージョン管理システムも使用したい場合に完全に使用できます。個人的には、CCのMercurial ontopを使用すると非常にうまく機能します。
私にとって最大の欠点は、パフォーマンス（特に、VOBがマルチサイトまたはオフサイトである場合）と、潜在的に長時間のダウンタイムの両方です。
あなたが私と同じで、大企業の一部として比較的小規模なオフィスで働いている場合（オンサイトITなし）、Clearcaseサーバーがダウンすると、非生産性の労働時間の適切な部分だけでなく、適切な人材を獲得できます修正する。
要するに、あなたがやっていることのために本当に必要な場合にのみ使用し、それを維持するための巨額のIT予算があることを確認してください。
LinuxでVOBからJDKを実行します。
試してください、LD_PRELOAD変数で遊ぶ必要があります（私は知っています！）
「専用の人が必要」「複雑です」などのポイント.
ここで問題を見つけることの中心的な問題は、組織で構成管理を実行するかどうかを定義する必要があることです（バージョン管理ではありません）。構成管理はプロジェクト管理に似ています。ツールがなくてもプロジェクト管理を実行でき、ツールがなくても構成管理を実行できます。多くの人々はこれを理解するのに苦労しており、多くの人々はConfiguration Managementはソフトウェアのソースまたは何かをバージョン管理するツールに等しいと考えています......（したがって、subversionsまたは他のVERSION管理システムとの比較）
ClearCaseは、構成管理環境ERGOで使用するために構築されたソリューションです。構成マネージャーがあります（「プロジェクトマネージャーがいる」のように）。
だから...あなたがツールを管理するために献身的な人がいるという認識にある場合、私は何か非常に間違っていると思います。私の考えでは、構成管理を行う専任の人がいて、エンドユーザーのパースペクティブから、ツールに問題がある場合にのみ表示されますが、これは彼の仕事の1％に過ぎません。
そのため、他のソフトウェアプロジェクトのように、必要なことは要件に戻り、組織が構成管理で何を望んでいるかについて要件のリストをまとめます。そして、他のソフトウェアプロジェクトと同様に、特定の要件について他のユーザー（管理など）に完全に同意しないユーザー（開発者など）がいます。私がここで読んだいくつかの反応に重要な私見があります。
そして、要件の組織リストと構成マネージャーが混在している場合、IMHO ....選択はかなり明確です（www.cmcrossroads.comのフォーラムも参照してください）
ClearCaseは、Subversionやgitなどのバージョン管理下でソースを入力するエンドユーザー専用のツールではありません。これは、構成マネージャーが成熟した構成管理ツールを本当に必要としている理由のわずか1％です。
そして...開発者が適切なプロジェクト管理ツールまたは適切なCRMシステムを選択するのと同じように、CMシステムを選択することは決してないはずです。開発者は、ツールの機能の特定の部分のエンドユーザーです。