私は現在IBMRationalClearCaseの学習に苦労しているので、専門家の意見を聞きたいと思います。
SubversionやGitのような他のバージョン管理システムと比較した場合の長所/短所に特に興味があります。
77096 次
31 に答える
110
ClearCaseとGitの良い比較は、私のSOの回答で見つけることができます：
「すべての開発者が知っておくべき基本的なClearCaseの概念は何ですか？」、いくつかの大きな違い（およびClearCaseのいくつかの欠点）を示しています
ファイル中心の操作
ClearCaseの最も重要な欠点は、古い「ファイル中心」のアプローチです（SVN、Git、Perforceのような「リポジトリ
中心」とは対照的です...）
。つまり、各チェックアウトまたはチェックインはファイルごとに行われます。操作のアトミック性はファイルレベルです。これを非常に冗長なプロトコルと、開発者ワークステーションとVOBサーバーの間に潜在的に複数のノードがあるネットワークと
組み合わせると、かなり低速で非効率的なファイルサーバー（ClearCaseがコアになります）になってしまう可能性があります。
ファイルごとの操作とは、次のことを意味します。遅い再帰操作（再帰チェックアウトや再帰的な「ソース管理への追加」などclearfsimport）。
そのおしゃべりなプロトコルの副作用を軽減するには、高速LANが必須です。
一元化されたVCS
考慮すべきもう1つの側面は、一元化された側面です（マルチサイトで複製されたVOB機能を使用して「分散」できますが）
ネットワークがVOBへのアクセスを許可しない場合、開発者は次のことができます。
- スナップショットビュー内で引き続き機能します（ただし、ハイジャックされたファイルのみ）
- 動的ビューを使用している場合は、ネットワークの復元を待ちます
高価な分散VCSオプション
Vobを複製することで、分散VCS機能を利用できます。
だが：
- アクセスするには特別な種類のライセンスが必要です。
- そのライセンスは高価であり、通常のライセンスのコストに追加されます
- 複製されたvob（admin vob、admin pvob、...）を使用するすべてのvobも複製する必要があります（つまり、分散開発に直接関係しない一部のプロジェクトでは、マルチサイトライセンスを支払う必要があります...）
古くて使い勝手が悪いGUI
- GUIは非常に古く、実用的ではありません（90年代半ばのMFCの外観、完全に同期したGUI、つまり、他の場所をクリックする前に更新を待つ必要があります）：ベースラインを参照するとき、特に1つをすばやく探すことはできません。
- UnixのGUIはWindowsのGUIとまったく同じではありません（最新の7.1バージョンの方が優れていますが、まだありません）
- インストールプロセスは非常に複雑です（ただし、CC7.1によって導入された最新のインストーラーマネージャーは、WindowsまたはUnixで一貫性のあるGUIになり、手順が簡素化されます）
- 唯一の真のリッチアプリケーションは、CCRC（リモートクライアント）用にのみ開発されています。
UCMの不整合と一貫性
「ClearCaseの機能を活用する方法」で説明したように、動的ビューは優れています（ディスクにコピーせずにネットワーク経由でデータを表示する方法）が、主な機能はUCMのままです。複雑なワークフローを持つ大きなプロジェクト。
その面でのいくつかの欠点：
- コンポーネント間の依存関係は、1つよりも深い深度では適切に管理されていません（「寄生虫ベースライン」のバグのため）
- CM Crossroadsに記載されているように、UCMにはまだ一貫性と不整合があります。
BaseClearCaseによる制限付きポリシー
UCMを使用せずにClearCaseを使用するということは、次のポリシーを定義する必要があることを意味します。
- ブランチを作成します（そうしないと、誰でも任意のブランチを作成でき、マージワークフローの悪夢でそれらのガジロンになってしまいます）
- ラベルを付ける（そうでない場合は、一部のファイルにラベルを付けるのを忘れたり、想定外の場所にラベルを付けたり、あるバージョンから別のバージョンにラベルを「移動」（gasp）したりします。少なくともUCMベースラインは移動できません）
- チェンジセットを定義します。ChangeSetは、UCMアクティビティでのみ存在します。Base ClearCaseを使用すると、巧妙な"
cleartool find"リクエストに削減されます。
アプリケーションの権利はありません
ClearCaseの権利管理は、完全にシステムの権利に基づいて構築されています。
つまり、ユーザーを正しいシステムグループに登録する必要があります。これは、ユーザーが適切に登録するためにITサービスへのチケットを入力する必要がある場合に必ずしも簡単に行うことができるとは限りません。それに異種環境
（Windowsのユーザー、Unixのサーバー）
を追加すると、WindowsだけでなくUnixにもユーザーを登録する必要があります。（同じログイン/グループ名で）。2つの世界の間に何らかのLDAP対応を配置しない限り（Centrifyなど）
高度なAPIはありません
- CLIのみが完了します（ "
cleartool"はClearCaseコマンドラインインターフェイスです）。つまり、（Perlまたは他の言語の）スクリプトは、これらのcleartoolコマンドの出力の解析で構成されます） - ClearCase Automation Library（CAL） は存在しますが、かなり制限されています
- Java APIは存在しますが、CCRCクライアントのWebビュー専用です。
ストレージを簡単に一元化/バックアップできない
ビューストレージは、SubVersionの「.svn」と同等ですが、SubVersionワークスペースのすべてのディレクトリに多数の.svnがあるのではなく、ビューごとに1つの「ビューストレージ」しかない点が異なります。それはいいです。
悪い点は、ビュー内の各操作（単純な " ls"、チェックアウト、チェックなど）によって、ビューサーバーを管理するview_serverプロセスへのネットワーク要求がトリガーされることです。
2つのオプション：
- ワークステーションでビューストレージを宣言します。スケーラビリティに優れており、LANに負担をかけることなく、必要な数のビューを使用できます。すべての通信はワークステーションで直接行われます。しかし、そのマシンがあなたの上で死ぬと、あなたはあなたの見解を失います。
- 集中型サーバーでビューストレージを宣言します。つまり、すべてのview_serverプロセスがそこで作成され、すべてのユーザーによるビューでのすべての操作がそのサーバーと通信する必要があります。インフラストラクチャが「適切」（特別な高速LAN、専用サーバー、常時監視）であれば実行できますが、実際には、LANはこのモードをサポートしません。
最初のモードとは、進行中の作業（プライベートファイルまたはチェックアウトされたファイル）を自分でバックアップする必要があることを意味します
。2番目のモードとは、ワークステーションが使用できなくなる可能性があることを意味します。スナップショットビューのファイル）
動的ビューに関するサイドディスカッション：
「動的ビュー」の側面に追加すると、1つの利点（動的）と1つの欠点（動的）があります。動的ビューは、小さなチーム間で小さな
開発
をすばやく共有するための単純な環境を設定するのに最適です。小さな開発作業の場合、動的ビューは、2人または3人の開発者が常に連絡を取り合い、コミットが中断したときに即座に確認するのに役立ちます。他のビューで何か。
より複雑な開発作業の場合は、スナップショットビューによって提供される人為的な「分離」が望ましいです（スナップショットビューを更新（または「更新」）したときにのみ変更が表示されます）
実際の分岐した開発作業またはコースでは、真のコード分離を実現するためにブランチが必要です（マージはある時点で必要になります。これは、ClearCaseがファイルごとにゆっくりではありますが、非常にうまく処理します）
重要なのは、正しい理由で両方を使用できるということです。
注：小さなチームとは、「小さなプロジェクト」を意味するものではありません。ClearCaseは大規模なプロジェクトに最適ですが、動的ビューを使用する場合は、ブランチごとに小さな開発作業を分離するために「タスクブランチ」を設定する必要があります。つまり、「小さなチーム」（大きなチームのサブセット）です。 ）効率的に作業でき、メンバー間で作業をすばやく共有できます。
全員が何かをしている「メイン」ブランチで動的ビューを使用すると、関係のない「ビルドブレーク」が発生する可能性があるため、チェックインすると「殺され」ます。現在の開発努力
では、動的ビューの使用法が不十分になり、他の使用法を忘れてしまいます。
- スナップショットビューに加えて、データにアクセスするための追加の方法。つまり、ファイルを「表示」するだけの優れたツールです（たとえば、動的ビューを使用して、必要なものが表示されるまで構成仕様を微調整し、それらをコピーして選択することができます）。通常のスナップショットビューへのルール）
- マージを行うための側面図：スナップショットビューを使用しますが、マージの場合は、動的な「姉妹ビュー」（「同じ構成仕様」の場合は「姉妹」）を使用して、次の理由でマージが失敗するのを防ぐことができます。チェックアウトされたファイル（現在スナップショットビューで作業しているファイル）、またはスナップショットビューが完全に最新ではないため。マージが完了したら、通常のスナップショットビューを更新して、作業を再開します。
すべての（チェックアウトされていない）ファイルはネットワーク経由で読み取られるため、動的ビューで直接開発することが常に最良のオプションであるとは限りません。
つまり、IDEに必要なdll、jar、またはexeはネットワーク経由でアクセスされるため、コンパイルプロセスが大幅に遅くなる可能性があります。
可能な解決策：
- すべてが含まれる1つのスナップショットビュー
- dll、jar、またはexeが含まれるスナップショットビュー（5分ごとに変更されないファイル：1日1回の更新）、およびソースのみが表示される動的ビュー。
于 2009-07-02T14:39:21.920 に答える
35
コストはかなり明らかな欠点です。ライセンスコストだけでなく、ClearCaseの第一人者の給与のコストも。ClearCaseを使用していることを私が知っているほとんどすべての会社には、手に負えない獣を飼いならすことが唯一の目的である人が少なくとも1人いるようです。
フルタイムの乳母を必要とするほど複雑であるという事実も心配です。
于 2009-07-02T14:13:57.807 に答える
27
システムの絶対的な悪夢。VSSに戻れたらいいなと思いました！（SubversionやGitのような最新のソース管理システムは気にしないでください！）
- それはslooooowです。
- 動的ビューを使用していてネットワークがダウンした場合、ソースの作業コピーにアクセスできません。座って修正されるのを待つ以外に何もできません。
- スナップショットビューを使用すると、常に競合や「ハイジャック」されたファイルが発生するように見えるため、作業コピー内のファイルがソースリポジトリ内のファイルとまったく同じになることはありません。
- 大規模な更新または配信操作を試みると、何らかの理由で必ず 失敗し、ClearCaseの第一人者がそれを理解するのに数時間/日を費やす必要があります。そうです、専任のフルタイムのClearCaseの第一人者が必要です。
- 失敗すると、操作をロールバックできないこともよくあります。そのため、進行中の操作でスタックし、開発者がブロックされます。
- きれいな（？）アイコンを見渡すと、GUIは非常に貧弱です。たとえば、ウィンドウのサイズを変更して完全なファイルパスを表示できない場合などです。
- 彼らのサポートスタッフは、何かを修正することに非常に消極的です。彼らの最初の反応は常に「これは設計によるものです」と「それを回避できますか？」です。彼らが最終的に修正を提供する場合（多くの議論の後）、それは最も差し迫った問題に対する最も基本的な可能な修正になります。
基本的に、それは遅く、複雑で、地獄のように信頼できません。ああ、それは途方もなく高価だと言いましたか？彼らがそれを売ることができる唯一の方法は、製品を使用したことがなく、使用することもない意思決定者と話すことです！世界中の開発者がそれを購入することはないと確信しています。
于 2009-07-17T05:00:28.483 に答える
25
アトミックコミットとチェンジセットは、ClearCaseに対する私の最大の不満です。バグ修正またはリファクタリングの一環として5つのファイルをチェックインするとします。次に、何かが台無しになっていることが発見され、元に戻す必要があります。それらがどの5つのファイルであり、それぞれがどのバージョンである必要があるかを見つけて頑張ってください。しかし、一歩後退しましょう。これらの5つのファイルの編集が完了したので、コミットします。最初の4つは問題なく通過します。最後の1つは、大規模なマージが必要です。他の4つのファイルはすでにチェックインされています。最後のファイルで必要な変更が完了するのを待ちません。誰も更新したり、動的ビューを使用したりしないことを願っています。継続的インテグレーションビルドサーバーも失敗します。
チェックインする必要のあるファイルでいっぱいの新しいディレクトリを作成することもありますが、完了するまでチェックインしたくありません。それは早く、すべてがまだ不安定です、なぜあなたがすぐに削除するかもしれないので物事をチェックするのですか？OK、今のところ大丈夫です。次に、チェックインします。新しく作成したフォルダーをソース管理に追加します。ClearCaseは再帰的ではないため、その単一のフォルダーのみがチェックインされます。SVNを使用すると、そのフォルダーとその下のすべてが、選択に応じて追加されます。開発者はすべてを追加することを忘れないでください。そうしないと、多くのファイルが失われます。
ClearCaseはファイルとフォルダーを所有しているため、最初にチェックアウトしない限り、何も変更できません。Eclipseプラグインは、ここで多くの厄介な問題を取り除きます。すばやく変更するためにviでファイルを開いた回数はわかりませんが、最初にチェックアウトするのを忘れていたことがわかりました。チェックアウトも再帰的ではありません。
変更セットがないと、更新が非常に遅くなる可能性があります。スナップショットビューで更新すると、変更されたファイルだけでなく、すべてのファイルが更新されます。20,000以上のファイルを使用するプロジェクトに取り組みました。私は自分の作業用マシンにリモートでアクセスし、更新を開始してから、ドライブして作業します。コーヒーを飲む; それが終わっている間に私の机に行きなさい。それは誇張のように聞こえるかもしれませんが、残念ながらそうではありません。
非常に小さなチームでない限り、動的ビューはひどいものです。その場合、なぜClearCaseを持っているのですか？誰かが他のすべての人の意見を壊したファイルをチェックインしたために、無数の人々の意見がうんざりしているのを見てきました。常に自分のビューで競合を更新してマージする必要があります。そうすれば、変更はあなたにのみ影響します。動的ビューでは、プッシュバックする前にマージすることはできません。あなたはただコミットして希望します。
コストはおそらく大きな問題ではないことは知っていますが、会社のためにお金を稼ぐ開発者は、楽しいイベントや新しい機器（一般的な追加であるClearQuestライセンスに応じて）に5万ドルから10万ドルを費やすことを楽しんでいます（椅子、モニターなど）。IBMは、ClearCaseを継続するためのスタッフを配置することをお勧めします。物事がクラッシュして燃えないようにするのではなく、それらの人々を再利用して会社の収益を生み出してみませんか？
切り替えない理由のいくつか：
- 学習には時間とお金がかかります
- SVNまたはMercurialの学習には1日しかかかりません。ClearCaseのみが、管理者と開発者の比率を一定にすることを提案しています。
- 移行は苦痛になります
- 安全
- SVN AFAIKには既知のギャップのある穴はなく、開発チームは迅速に見つかったものを修正することに専念しています。国防総省はSVNで問題ないようです。
- その後、実際の生産性の向上はありません
- チェンジセットなしでバグを追跡しようとすると、永遠に時間がかかります。バグが見えなくなるまでロールバックできるのが大好きです。ClearCaseではそれを行うことはできません。
- マルチサイト
- WANdiscoはその問題を解決します。ただし、無料ではありません。
ClearCaseが他のファイルよりも優れている唯一のことは、他のファイルを別のブランチと同じトラックに保ちながら、個々のファイルをブランチすることです。
于 2009-07-14T12:42:53.290 に答える
20
Clearcaseで行ったことはすべて、常に難しいようです。一方、私は他のシステムでそのような印象を持ったことはありません（たまにCVSを除いて）。
私はSVN、CVS、Clearcase、およびMercurialを使用しました。
于 2009-07-13T17:10:46.090 に答える
15
ClearCaseでの私の経験は惨事でした。そして、常駐の専門家が必要であるというDonの2番目の声明を紹介します。残念ながら、複数の専門家がいました。私はCVSや他のバージョン管理システムの経験があり、概念に精通していましたが、ClearCaseのドキュメントが理解できないことに気づき、何度か助けを求めなければなりませんでした。さまざまな専門家から、実際にCDを壊したところまで相反するアドバイスがありました。つまり、UNIXシェルでClearCaseコマンドを発行した後、「cd」コマンドが失敗し、エラーメッセージが表示されました。
バージョン管理システムの基本的なタスクは非常に簡単です。正直なところ、他のコマンドとうまく機能するファイルスキームを使用すれば、半ダースのコマンドで十分だと思います。私には、ClearCaseは、製品を洗練された強力なものに見せるために、マーケティング担当者が意図的に物事を複雑にした結果のように見えます。シンプルで安全、信頼性の高い方法で動作するように構成できると聞きましたが、これも専門家のサービスが必要です。箱から出してすぐに、電動スイスアーミーナイフのようになります。
于 2009-07-02T19:21:27.033 に答える
15
ClearCaseに関連して私が経験したことはすべて、非効率的で、醜く、過度に複雑で、遅く、混乱し、高価で、不便です。
それはちょうどそれをすべて間違ってしまったマネージャーやエンジニアを引き付けるようです。
くそー、IBMとRationalは、そのようなくだらない製品を販売するために素晴らしい営業担当者を持っている必要があります。
于 2010-03-25T22:33:02.587 に答える
15
ここに示した多くの理由により、CCからGitに移行しているところです。CCやその他の商用ソース管理システムに近づかない理由を1つ付け加えたいと思います。
重要なビジネスデータはClearCaseの人質です。あなたはそれを取り出すことはできません。
重要なビジネスデータは、コード、そのバージョン履歴、およびコミットコメントなどのすべてのメタデータであり、誰がいつチェックインしたかです。
すべてのソフトウェアの耐用年数は限られています。コード、バグ、顧客データなど、重要なビジネスデータを飲み込む新しいシステムを導入するときは、常に自問自答する必要があります。データを再度取得するにはどうすればよいですか。その質問に答えられない場合は、そのシステムを導入しないでください。
移行すると、ほとんどの履歴とすべてのメタデータが失われました。基本的に、リリースされたバージョンに対応する履歴しかありませんが、顧客の要求に応じて行われた変更に関する情報は失われます（そのデータはカスタマーサポートとバグチケットシステムにあるため、完全に失われるわけではありませんが、ソースコードはなくなりました）。
これは、短期から中期的には、私たちにとって厄介な問題と問題の間のどこかになります。数年後には、それはもはや重要ではなくなりますが、おそらく1〜3年は重要になります。
（CCを他のSCMに移行するための商用ツールがありますが、それらは私たちのニーズに十分であるとは見なされず、それが実現可能であったとは思えません。私たちが行った最小限のエクスポートには十分な時間がかかりました。）
学んだ教訓は次のとおりです。重要なビジネスデータをプロプライエタリシステムに決して委託しないでください。
于 2011-07-02T21:55:07.903 に答える
14
アトミックコミットはありません
アトミックコミットはサポートされていないため、ファイルをチェックインすると、特定の状態に戻すのは非常に困難です。複数のファイルをチェックインする場合、各ファイルはチェックイン自体ではなく、新しいリビジョン（CVSと同様）を取得します。これは重要な機能だと思います。単一のファイルを元に戻すことはほとんどなく、コミットアクション（タスクをマップする必要がある）を完了する必要があるためです。ClearCaseを使用すると、ラベルを使用することによってのみ特定の状態に戻すことができます。実際には、チェックインごとにClearCaseラベルを使用するのはやり過ぎであり、したがって実行されません。
安っぽいユーザーインターフェース
ClearCaseExplorerのGUIは単なる冗談です。使いやすさと醜い見た目で恐ろしい。異なる、そしてしばしば必要な機能は提供されていません（例えば、アーティファクトで作業されたものを再帰的にチェックインする）。cygwinで使用されるコマンドラインツールcleartoolの方がはるかに優れていますが、ソース管理に新しいファイル/フォルダーを再帰的に追加するなど、まだ利用できないものもあります。これを回避するために50行のコード長のスクリプトを読んだ場合、私は頭を笑わせる必要があります。
高度な管理努力
ClearCase beastの管理は、明白または軽量ではありません（CVS、subversion、Gitなどの他のscmシステムとは異なります）。実行を継続するために、かなりの数の専任のClearCaseエキスパートを配置することを期待してください。
ひどいパフォーマンス
SCMツールとのインターフェース中に開発者を待たせることは、ハンドブレーキを有効にして運転するようなものです。それはあなたの脳とあなたの仕事を遅くします。スナップショットビューに新しいファイルを取得するには、10Kのアーティファクトで約30分かかります。同じ量の更新（アーティファクトは変更されていません）には、約5分かかります。多くの実験を行い、さまざまな最新のビュー間をジャンプする場合は、多くの待機を意味します。ファイルで作業していて、ファイルをチェックインまたは更新したい場合は、さらに悪化します。チェックアウト、チェックイン、およびソース管理サイクルへの追加には約10〜15秒かかりますが、これは明らかに悪夢です。タイプまたはメソッドの名前変更/移動をリファクタリングする場合、非常に煩わしくなります（多くのファイルが影響を受ける可能性があります）。
分散開発のサポートの欠如
今日、ソフトウェア開発は分散型のものであることがよくあります（開発者は同じ製品/プロジェクトに取り組んでいる世界中に散らばっています）。ClearCaseはオフライン作業にはあまり適していないため、これには明らかに適していません。チェックアウト（ファイル/フォルダーを編集する前のアクション）を実行するには、ネットワークに接続している必要があります。ここではハイジャックオプションを使用できますが、これは機能としての回避策です（基本的にはファイルシステム上のファイルのロックを解除するだけです）。開発サイトが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-away-from-clearcase/から取得したものです
于 2009-07-21T15:45:46.523 に答える
13
おそらくこれまでに作られた最悪のソフトウェア。私は合理的なものを使用する会社では働きません。CCが完全にクラッシュし、動的ビルドでワークステーションを頻繁に再起動することは別として。ソース管理に何かをプッシュしていて、CCが最善を尽くしてクラッシュするとどうなりますか？次に、コードはlost + foundに入れられ、どこかにバックアップされますか？いいえ、それは永遠になくなりました。したがって、この巨大な高価なソフトウェアを使用するというひどい状況に陥ったことがある場合は、すべての複製を保管してください。良い仕事Rational/IBM。ソース管理の最も重要な部分である信頼性をキャプチャする方法。ゆっくり死ぬ。
于 2010-05-14T02:29:53.740 に答える
12
ClearCaseの欠点-ここで最も詳細な投稿への追加。
マージツールは価値がありません。それはほとんどあなたを助けません、あなたが下した決定を覚えていません、それはただ栄光の違いです。
マージツールは、ディレクトリをチェックアウトして、マージが必要かどうかを確認する必要があります。その少し狂気。
私は仕事でBitKeeperを使用しています（Gitを想定します）。競合がある場合でも2つのリポジトリをマージすることは、コマンドラインを使用しても非常に簡単でユーザーフレンドリーですが、多数のGUIツールを備えたClearCaseは長くて骨の折れるプロセスであり、エラーが発生しやすくなります。 。
すべてのGUIツールには大量のレイテンシが必要です。ファイルで何ができるかを確認する場合でも、高速接続が必要です。そのため、自宅で作業しているファイルをClearCaseツールで右クリックすると、ネットワーク要件が非常に大きいため、高速インターネットを使用する場合に1〜2分かかる場合があります。
ビューの仕様がチームと異なる場合、誰かがリポジトリやチェックインを完全に台無しにする可能性があります。これは、誰もブランチをチェックアウトできないというのは非常に正気ではありません。偶然に適切なものを提供する適切なビュー仕様が必要です。全体のコンセプトは素晴らしく柔軟ですが、99％の確率で多くの苦痛を引き起こします。CCツールはUTF-8を受け入れないため、コピーして貼り付けることができないため、Microsoft Outlookを介して仕様を電子メールで送信できないことを述べましたか？
私はCCについて何も言うことはありません。2社で2年間使って、ずっと幸せな気持ちで一気に落としました。また、自宅で自分のプロジェクトを試すことは不可能です。そのため、自宅でSVNやGitを学び、職場でClearCaseの苦痛を経験することを余儀なくされます。私が知っている人は誰もCCを自発的に使用したことがありません。彼らはそれを使用するのは、職場の一部のマネージャーがCCが救いへの道であると判断し、全員がCCに移行することを余儀なくされたためです。実際、私の最後の会社はCVSからClearCaseに移行し、1年後にClearCaseからSVNに移行しました。それは嫌いでした。
ClearCaseは、あなたにノーと言わせるだけのことではありません。まるでアリがはびこっている家に住んでいるようなものです。それぞれのアリはせいぜい小さな不便ですが、侵入はあなたを怒らせます。
于 2009-07-20T17:46:56.177 に答える
11
ここで、いくつかのコメントを実際の投稿にまとめようとしています。いくつかの点を除いて、私は実際には一方が他方よりも優れていることをあなたに説得するためにここにいるわけではありません。
- gitとClearCaseを比較している場合は、ニーズをより適切に定義する必要があることを敬意を表して提出します-「良い」理由でClearCaseを検討している場合、gitはおそらく方程式に含まれていません-信頼するにはあまりにも新しいですエンタープライズレベルのソース管理用、imo。
- ClearCaseは、他のシステムにはない多くの概念をバージョン管理スペースに導入するため、かなり困難で混乱を招く可能性があります。特に、ここにいる少数の人々の場合のように、あなたが持っている唯一の経験がドキュメントを読むことである場合。
- ClearCaseは、VOBサーバーを備えたLAN上にいない開発者がサポートする巨大なコードベースにはまったく適していません。多くの複製された（マルチサイト）VOBサーバーを使用して、リモート開発者に近づけることができますが、これらのリモートサイトが単一の開発者である場合、これは必ずしも実用的ではありません。
- ファイルのバージョン管理またはリポジトリのバージョン管理が必要ですか？これは非常に重要な質問であり、必然的にツールのセット全体を除外して、作業を容易にするものです。リポジトリのバージョン管理には多くの利点があります（一部のポスターが主張するように、「新しい」ものではありません。Perforceのような商用ツールは12年以上前から存在しており、Perforceの前からリポジトリのバージョン管理を行っていたツールがあった可能性があります）。それは万能薬ではありません。
- ソース管理システムを十分に大規模にインストールすると、支援が必要になります。ツールを検討するときは、あなたを助けてくれる人を見つけるのがどれほど簡単かを考慮する必要があります（経験のある求職者、または問題に対処するためにすぐにそこにいるコンサルタントのいずれか）。メンテナンスフリーのSCMシステムのようなものはありません。SCMシステムがあると仮定すると、「多すぎる」管理が必要なものを選ぶよりも問題が発生します。
- 「動的ビュー」がどれほど悪いかについて話す人にはあまり注意を払わないでください。使用しているツールに関係なく、悪いSCMポリシーは悪いです。構成管理のポリシーとプラクティスは、選択したツールとは別にする必要があります。適切な分岐およびマージポリシーを定義しない限り、ユーザーがコードベース全体を破壊するのを防ぐツールはありません。開発者に/mainに直接コミットさせることが賢明なアイデアであると誰かが提案した場合は、その会話から離れることをお勧めします。
ClearCaseは優れたツールですが、複雑です道具。これを回避する方法はありません。「簡単インストール」モードはありません。:-)技術的な観点からは、ClearCaseができないことはgitやSVNでできません（ただし、オープンソースプロジェクトは既存の分類法を発明する傾向があるため、用語は異なることがよくあります）が、いくつかのことは間違いなく簡単です。 /設計に応じて、特定のシステムではより困難になります。ClearCaseの「スナップショット」ビューは、SVNまたはCVSからリポジトリをチェックアウトした場合と基本的に同じです。これは、マシン上のソースコードのローカルコピーであり、バージョン履歴をクエリするためのツール用のポインタが中央サーバーに戻されます。これらのビューは、作成後にClearCaseサーバーにネットワーク接続しなくても操作でき、「リサイクル」できます。たとえば、別のブランチで作業するために移動する場合に、リポジトリ全体を再度ダウンロードしないようにするためです。「ダイナミックビュー」は基本的にClearCaseの発明であり、LANの標準動作モードです。これらはSVNリポジトリをチェックアウトするのと同じように見えますが、変更を加えるまで実際にはファイルをコピーしません。このようにして、ビューはすぐに使用可能になりますが、メインのClearcaseサーバーが使用できない場合は明らかに操作できず、待ち時間の長い接続で操作するのは不快です。また、作成されたサーバーにアクセスできる任意のマシンにネットワークドライブとしてマウントできるという便利さもあるため、Windowsワークステーションが停止した場合でも、別のワークステーションにログオンしてビューをマウントし、取得することができます。仕事に戻る、
また、これは独自の段落に値します....clearmergeは入場料だけの価値がほとんどあります。これは、私がこれまでに使用した中で最高のマージツールです。高品質のマージツールがないためにSCMで多くの悪い習慣が生まれたと確信しています。そのため、CVSユーザーはブランチの適切な使用法を学ぶことができず、このブランチへの恐れは特に理由もなく今日にまで広がっています。
そうは言っても、ClearCaseを使用しない理由を探しているのであれば、見つけるのは難しくありませんが、それは間違った方法だと思います。本当に、ClearCaseを使用しない理由ではなく、ClearCaseを使用する正当な理由を考え出す必要があります。ClearCaseがツールとして多すぎる、またはツールが複雑すぎると想定して、SCMの状況に陥り、それを使用するように促す状況があるかどうかを確認する必要があります。IBMまたはRationalのロゴがあるのは正当な理由ではありません..:-)
次のすべてのステートメントに「はい」と答えられない限り、ClearCaseを検討することすらありません。
- 現在、または最終的には、50人以上の開発者が同じコードベースで作業しています。
- これらの開発者のほとんどは中央に配置されているか、中央の場所への高スループットで低遅延の接続を持っています。
- 一連のSCMポリシーがあり、ClearCaseを使用してそれらのポリシーを適用する方法を特定できます（実際には、どのツールでもこれを検討する必要があります）
- お金は本当に目的ではありません
于 2009-07-16T19:31:17.753 に答える
9
私の経験は主にCC、CVS、SVNによって制限されています。原則として、CCは技術的に能力があり、エンタープライズ対応であり、最新のVCSと同等の機能を備えています。しかし、それはどんな人指向の環境でもそれを使用できないようにするいくつかの欠陥を持っています。プロセス指向の環境の場合はおそらくより適切ですが、そのような環境自体が適切であるとは思えません。たぶん、軍隊、宇宙、または医療用ソフトウェアでは、私にはわかりません。とにかく、これらのドメインでも、適切でさらに使いやすいツールがあると思います。
CCには、技術的に優れたVCSであることに加えて、いくつかの明確な利点があります。
- 動的ビュー
- 素敵なバージョンツリー
- トリガー
- 名前の変更を含む、優れたマージバージョン管理
私の意見では、それらの使用は最後のものを除いて制限されています。そしてそれらは欠陥を補償しません。動的ビューは理論的には優れていますが、実際には常に利用できるとは限りません。バージョンツリーは他のVCSでの使用がはるかに少ないですが、ブランチが急増しているためCCでは必要です（6を参照）。私が知っているように、トリガーは非常に詳細で有能ですが、ほとんどの実用的なタスクにはSVNフックで十分だと思います。そして今、主にユーザビリティに関係する不利な点について：
- CCは、メインユーザーグループ（開発者向け）の使いやすさという意味では完全に失敗します。そしてそれが、企業であろうとなかろうと、いかなる環境でも決して使用されるべきではないと私が考える主な理由です。それが無料であったとしても、それでも開発者の時間を無駄にし、彼らを苛立たせることによってあなたの会社のお金を吸い込むでしょう。この点は以下から構成されています：
- 厳密なロックアプローチによる「チェックアウト-チェックイン」-これは逆効果であり、リファクタリングは不親切であり、複数の開発者向けの単一の開発ブランチを持つリポジトリ組織では危険です。一方、厳密なロックの利点はごくわずかです。
- パフォーマンスが低く、負荷が高い
- マルチサイトなしではリモートで効果的に使用することはできません（2のため）。マルチサイトも高価です。ClearCaseリモートクライアントは非常に制限されています。（バージョン7.1より前の）それはありません
cleartool、動的なビューだけを残します。 - オフラインではほとんど使用できません。動的ビューは機能しません。リポジトリへのアクセスなしではチェックアウトできないため、スナップショットビューは事実上読み取り専用です（1を参照）。ハイジャックは貧弱なオプションです。これは、実際には、CCがハイジャックされたファイルに対する責任を放棄することを意味します。また、CCは、オフラインの場合、以前のリビジョンとの違いを表示できません。SVNは、オフラインであっても以前のリビジョンとの違いを示すことができます。
- 特にUCMの場合、非常に複雑なモデル：VOB、PVOB、プロジェクト、ストリーム、ブランチ、ビュー、配信、更新、ロード、復元、リベース、マージ、ベースライン、チェックイン、チェックアウト。この概念の半分は不要であり、付加価値はありませんが、技術的および概念的な複雑さが増していると思います。CCに関する基本的なことさえ理解している開発者はほとんどいません。
- 枝の増殖。たとえば、リポジトリは開発者ごとにストリームで編成されることがよくあります（1のため）。SVNや他のほとんどのVCSでは意味がありません。
- リポジトリ全体のリビジョンはありません。ええと、理解するような改訂があります、彼らはベースラインと呼びました。しかし、いくつかのファイルリビジョンを確認し、そのファイルリビジョンの時点でリポジトリスナップショットを取得したい場合、いくつかの問題が発生します。スナップショットビューを作成するには、構成仕様を使用して黒魔術を実行する必要があります。または、動的ビューが利用可能な場合は、何らかの方法で動的ビューを検索する必要があります。
- 安っぽいユーザーGUI。バージョンツリーは、優れていても、使いやすさは平凡です。マージツールは残念です。その他の「機能」：サイズ変更できないウィンドウ、一部の場所でのインクリメンタルサーチの欠如、マウス中心のインターフェイス、1995年スタイルのルックアンドフィール、クライアントとプロジェクトエクスプローラー間で分散される奇妙なワークフローなど。
- CCは、まれで膨大なチェックインを引き起こします。ご存知のとおり、チェックインは小規模で頻繁でなければなりません。ただし、開発者は通常、CCとの追加のやり取りを控え、ファイルをハイジャックし、ローカルのVCSで作業するか、VCSをまったく使用しない場合でも作業します（残念ながら、これはより頻繁に行われます）。そして、2週間の開発の後、20個のファイルを追加し、さらに20個のファイルに影響を与えるcomlex機能のコミットを開始します。ファイルが乗っ取られ、リポジトリからのすべての新しい変更を手動でマージして、すべての競合と不一致を解決する必要があるため、1〜2日続きます。そのプロセス中、いくつかのファイルが正常にチェックインされ、他のファイルはチェックインされないため、コードはコンパイルできません。その後、CCにさらに2つのファイルを追加するのを忘れたため、まだコンパイルできません。
- それはとても高価です
- インフラストラクチャの点で非常に複雑であり、専任の管理者が必要です
于 2010-07-02T23:20:38.837 に答える
8
ClearCaseは、外部から見ると非常に強力に見えます。しかし実際には、基本的なワークフローに使用する必要のあるコマンドとオプションの数が非常に多いため、これらがいくつかのエイリアスやスクリプトの背後に隠れてしまい、Visual Sourceの使いやすさで、CVSよりも強力ではなくなります。安全な。また、スクリプトで許可されているよりも少し複雑なことをしたいときはいつでも、胃の中で気分が悪くなります。
これを、外部からは複雑に見えるGitと比較してください。ただし、1週間使用すると、完全に制御できるようになります。リポジトリモデルは理解しやすく、信じられないほど強力です。簡単に理解できるので、日常のワークフローの表面を掘り下げるのは実際に楽しいことです。
たとえば、スナップショットビューでファイルの非HEADバージョンを表示する方法などの簡単なタスクを理解するには、数時間かかり、最終的には完全なハックでした。楽しい種類のハックでもありません。
しかし、Gitでは、一部の変更のみをインタラクティブにコミットする方法（残りは後で使用する方法）など、一見複雑に見えるタスクを理解するのはとても楽しかったです。VCSによってコードを整理し、歴史は私たちがVCSをどのように使用したかという偶然ではなく、私に合った方法での歴史です。「Gitとは、「あなたが持っているべき」と言う必要がないことを意味します」。
私の仕事では、ClearCase内であっても、あらゆる種類の軽量タスクにGitを使用しています。たとえば、私はTDDを実行し、一連のテストに合格してリファクタリングしようとしているときはいつでもGitにコミットします。タスクが最終的に完了すると、ClearCaseにチェックインし、Gitを使用して変更内容を正確に確認できます。ClearCaseを取得して、いくつかのファイル間で差分を生成するようにしてください。それはできません。Googleを使用して、人々がこれを回避しようとしたさまざまなハックを見つけてください。これは、バージョン管理がすぐに実行できることであり、簡単なはずです。CVSは何十年もこれを持っています！
于 2009-07-09T23:27:22.487 に答える
7
- 安全な環境で管理する悪夢
- 時代遅れのテクノロジー
- 直感的でないGUI
- 高価な
- リソースモンスター
- マイクロソフトへの売り切れ
私の意見では？それを持っている唯一の理由は？宗教的にRUPをフォローしている場合。
于 2009-07-14T13:00:16.680 に答える
6
サポートはひどいです。私たちは何年もの間チケットを開いてきました。私たちのEclipseの第一人者は、Javaファイルを分解することにより、実際にEclipseプラグインのバグをローカルで約30分で修正しました。しかし、チケットはまだレベル1のサポートを超えていません。時々、彼らはそれをこっそり閉じようとするか、「最新バージョンを試すために」私たちにpingを返そうとします（私たちが彼らに自分で試すことができる複製レシピを送ったとしても）。
バージポールに触れないでください。
于 2009-07-20T19:22:46.153 に答える
5
パフォーマンス。
ClearCaseは強力で安定していますが（適切に保守および監視されている場合）、低速です。時々地質。
動的ビュービューは、ビルドに時間がかかります。スナップショットビューは、更新（大規模なプロジェクトの場合は昼休み）またはチェックアウト（その日は家に帰る）に時間がかかる場合があります。
于 2009-07-03T19:45:38.053 に答える
4
Clearcaseは非常に煩わしいため、実際に人々はそれについて詩を書くようになります。
http://digital-compulsion.blogspot.com/2007/01/poetic-pathetic-version-control.html
http://grahamis.com/blog/2007/01/24/if-it-was-free-no-one-would-download-it/
于 2009-07-17T05:42:29.553 に答える
4
開発者は、作業を行う前にクリアケースを理解するために半分の時間を費やします。理解したら、gitをローカルにインストールし、必要に応じてクリアケースリポジトリにプッシュするだけです。
専用のClearcase管理者を採用する必要があります。
于 2011-12-22T00:46:10.673 に答える
3
私は最近、同様の状況に苦しむ必要がありました。たぶんあなたは私の話から学ぶことができます。
私が新しく割り当てられたチームは、複雑でエラーが発生しやすい方法で重量級のツールを使用していました。私は最初に、選択したツールとプロセスでそれらを販売しようとしました。この試みは惨めに失敗しました。私は、彼らがより簡単でより効果的な環境よりも、そのような厄介な環境を選ぶだろうと驚きました。彼らは懲戒処分を受けたいと思っていたことが判明し、苦痛なプロセスを使用することは彼らに懲戒処分を受けたと感じました。奇妙に聞こえますが、それは本当です。彼らには他にも多くの誤解がありました。彼らが何を求めているのかを理解した後、実際には同じツールスイート（Serena）を使い続けましたが、構成方法を大幅に変更しました。
あなたへの私のアドバイスは、あなたのチームにとって何が重要かを理解することです。ClearCaseをリッピングしても、彼らの興味に話さない限り、どこにも行き着きません。また、彼らが代替手段を使用したくない理由を見つけてください。基本的に、少し要件を収集し、ツールの選択をニーズに合わせます。オプションによっては、誰が知っているか、結局、ClearCaseが最良のオプションになる可能性があります。
于 2009-07-17T07:10:51.230 に答える
3
ツールセットにはSVNを、スケーリング/ワークフローにはGitをお勧めします。また、可能な限りCCを回避することをお勧めします。（お金を数えないで、フルタイムの管理者を必要とするのは使用するのがとても苦痛であるという事実は完全な冗談です）
于 2009-07-02T15:58:31.877 に答える
2
私はClearCaseに完全に反対しているわけではありませんが（長所はあります）、短所をリストアップします。
- ライセンスの制限-ライセンスサーバーにアクセスできないため、自宅で簡単に仕事をすることはできません。ラップトップのスナップショットビューを使用しても、ライセンスを取得できないため、トリックを実行する必要があります。特別なリモートクライアントがありますが、それ自体の制限がたくさんあります。
- 再びライセンスの制限-周りを回るのは非常に多くの座席だけであり、それから誰もそれを使用することはできません。
- 時代遅れのUnixツール-ClearCaseはUnixシステムで最もよく動作するようですが、GUIツールはそれを嫌います。ClearCaseのWindows/Unix統合は、あらゆる種類の独自の問題をもたらします。
于 2009-07-16T04:20:15.070 に答える
1
私にとって最大の欠点は、パフォーマンス（特に、VOBがマルチサイトまたはオフサイトの場合）と、潜在的に長いダウンタイムの両方です。
あなたが私のようで、大企業の一部として比較的小さなオフィスで働いている場合（オンサイトITがない場合）、Clearcaseサーバーがダウンすると、生産性が低下するだけでなく、適切な人材を確保するために、1日の作業の大部分が犠牲になる可能性があります。それを修正するために。
結論としては、自分がしていることに本当に必要な場合にのみ使用し、それを維持するための多額のIT予算があることを確認してください。
于 2009-07-13T23:50:16.003 に答える
1
ClearCaseは、その上に別のバージョン管理システムを使用する場合にも完全に使用できます。個人的には、CCの上に水銀を使用すると非常にうまく機能することがわかります。
于 2009-07-20T23:27:26.003 に答える
1
- アトミックチェックインなし
バージョン7.1の新しいバージョンの時点で、CCは、必要に応じて機能としてアトミックチェックインを提供します。個人的には本当に欲しくないのですが、「本質的な機能」だと思っている方もいらっしゃると思います。ある種の大規模なバージョンとして、一度に1つの大きなバルクが必要になることは決してありません。次にもう一度...必要に応じてオンにします。
だから...もはや議論ではありません。
于 2010-07-09T15:05:08.423 に答える
1
過去4年間、ClearQuest（DR追跡/変更要求システム）と統合されたUCM ClearCaseを使用し、50人以上の開発者が参加しました。35Kを超えるDRと変更要求を処理する数千を超えるストリームを含む50を超えるUCMプロジェクトがあります。この期間中に、600を超える統合配信を公式に行い、最大6つの同時開発およびリリース作業を行いました。
私は、定期的な配信/マージおよび統合ビルドを実行できるバックアップを持つメインのCM/ClearCaseの担当者です。ネットワークとサーバーはITチームによってサポートされています。私が言えるのは、この膨大な開発努力のCM側からの問題はほとんどなく、ショーストッパーではなかったということだけです。私たちの開発者は、プロジェクト管理者からの要求に応じて新しいプロジェクト（ブランチ）が作成されるたびに、基本的なものと簡単な手順だけでトレーニングを受けました。
適切なCM/IT / ClearCase / Process / Managementサポートが不足しているため、ClearCaseについて不満を言う開発者が多すぎます。開発者は、SCMではなく開発に集中するか、ツールのスペシャリストになる必要があります。大規模なソフトウェア開発の場合、予算の少なくとも5〜7％をCMとツールのサポートに費やす必要があります。
于 2011-04-05T19:47:44.557 に答える
0
LinuxでVOBからJDKを実行する。
それを試してみてください、あなたはLD_PRELOAD変数で遊ぶ必要があります（私は知っています！）
于 2009-07-15T10:31:52.320 に答える
0
「専任者が必要」「複雑」などのポイント。
この問題を見つける際のここでの中心的な問題は、組織で構成管理（バージョン管理ではない）を実行するかどうかを定義する必要があることです。構成管理はプロジェクト管理に似ています。ツールがなくてもプロジェクト管理を実行でき、ツールがなくても構成管理を実行できます。多くの人がこれを理解するのに苦労しており、多くの人が構成管理はソフトウェアのソースなどをバージョン管理するツールと同等であると考えています......（したがって、サブバージョンまたは他のバージョン管理システムとの比較）
ClearCaseは、構成管理環境ERGOで使用するために構築されたソリューションです。構成マネージャーがあります（「プロジェクトマネージャーがあります」のように）。
ですから...ツールを管理するために専任の人がいるというあなたの認識では、何か非常に悪いことがあると思います。私の認識では、構成管理を行う専任の担当者がいて、エンドユーザーの観点からは、ツールに問題がある場合にのみ表示されますが、これは彼の仕事の1％にすぎないと見なしています。
したがって、（他のソフトウェアプロジェクトと同様に）実行する必要があることは、要件に戻り、組織が構成管理で望んでいることに関する要件のリストをまとめます。そして、はい、他のソフトウェアプロジェクトと同様に、特定の要件について他のユーザー（管理など）に完全に同意しないユーザー（開発者など）がいます。私がここで読んだいくつかの反応には重要な意味があります。
また、要件の組織リストと構成マネージャーが混在している場合は、IMHO ....選択は非常に明確です（www.cmcrossroads.comのフォーラムも参照してください）。
ClearCaseは、subversionやgitなどのバージョン管理下でソースを入力するエンドユーザー専用のツールではありません。これは、構成マネージャーが成熟した構成管理ツールを本当に必要としている理由の1％にすぎません。
そして...CMシステムの選択は、適切なプロジェクト管理ツールまたは適切なCRMシステムを選択することと同じように開発者に委ねられるべきではないと思います。開発者は、ツールの機能の特定の部分のエンドユーザーです。
于 2010-07-15T17:10:04.900 に答える
-1
私はここで一人になるかもしれませんが、ClearCaseは誰もが言うほど悪くはありません。巨大なリポジトリを処理できます。ダイナミックビューもかなりクールで強力な機能です。信頼性が高く、pefファイルベースのトリガーと制約、権限などを追加してカスタマイズできます。
残念ながら、それは価格、大きな価格が付属しています。コストがかかり、適切に運用するには、専任のITチームが適切に構成および保守する必要があります。それはBigCoにとっては本当に良いことですが、SmallFirmにとってはそれほど賢明な選択ではありません。
私はDVCSとgitの大ファンですが、BigCoがSVNとGitではなくClearCaseを選択する理由は理解できます。なぜ誰もがGitよりもSVNを選ぶのか理解できません;>
于 2009-07-21T15:49:50.460 に答える
-1
動的ビュー。完全に機能する半透明のファイルシステムを賞賛する必要があります。
大きな利点の1つは、知的財産が常に企業ネットワーク内にあることです。ラップトップは紛失/盗難に遭う可能性があり、ソースコードが危険にさらされることはありません。
もう1つは、ソースコードと変更されたファイルへの即時アクセスであり、何かをダウンロードするために時間を費やすことはありません。
それはそれが持っている目的のためにうまく機能します。
于 2009-10-07T01:13:15.407 に答える
-3
管理。6から7へのアップグレードを実行し、セミマス（159GB）VOBSを古いサーバーからSANストレージに移動するには、複数の1日にわたるダウンタイムをスケジュールする必要がありました。gitやsvn+svkのようなシステムでは、これはユーザーに影響を与えることなく、ほぼ自動的に一晩で実行できます。ユーザーは気付かないでしょう。変更をアップストリームにプッシュすることはできませんでしたが、引き続き機能します。ClearCaseまたはrawSVNを使用すると、リポジトリサーバーに翻弄されます。
ClearCase UCMは素晴らしいツールです。私はそれが好きで、SVN / mercurial / git / bzrに同様の機能を追加するために何かできると思います。フックスクリプトで実装できないわけではありませんが、それはカスタムの1回限りです。各サイト。UCMは非常に普及しており、誰もがそれを行っていますが、リポジトリでUCMを追跡する人はほとんどいません。：-/
于 2009-07-14T15:53:43.557 に答える