3

それでは、私たちの現在の状況について説明させてください。私たちは経験豊富なJava開発者の小さなチーム（6）であり、SAPとSiebelのコンフィギュレーターで大部分が構成されている大きなISチームで負けています。
他のすべてのチームは現在、主にボールティングシステムとしてVSSを使用していましたが、アジャイル手法に最適なSubversionに切り替えました（DVCSも評価した後）。

現在、すべての人がClearCaseに移行するように求められており、VSSユーザーはユーザーの大部分を占めるため、すべての移行作業はVSSユーザーに費やされています。
私たちは自分たちだけで、ClearCaseを本当に知らないので、現在の作業プロセスに適合しないのではないかと心配しています。

現在、私たちが日常的に取り組んでいる方法は次のとおりです。

  • SVNリポジトリは、/ trunk、/ branchs、/tags構造に従います。
  • 各開発者は、テストとプロトタイピングの目的で、リポジトリに独自のサンドボックスを持っています。
  • 私たちは新機能の開発にブランチを集中的に使用し、それらをトランクに昇格させる前に、それらをマージして統合テストを実行するために使用されます。
  • Javaで作業していると、リファクタリングを行うのに慣れています。Eclipseはそのための大きな助けになります。多くのクラスとパッケージの名前変更は毎日行われます。
  • プロジェクトがどのように進化したかに応じて、一部の部分が再利用され、プロジェクトがいくつかのプロジェクトに分割され、元の部分はsvn：externalプロパティを介して統合されたままになります。
  • テスターがテストしているリビジョンを知るための非常に簡単な方法であるため、一部の要素にはキーワード置換を使用します。
  • 私たちのSubversionリポジトリは、テストスイートを実行するためにHudsonにリンクされており、タグを付けることで有効なビルドを促進します。

ClearCaseについて今のところ私が知っているのは、CCRC（またはEclipseプラグインバージョン）を介して使用する必要があることと、問題追跡管理のためにほとんどのプロジェクトをClearQuestプロジェクトにリンクすることを強くお勧めします。 。

ClearCaseがSubversionをどれだけうまく置き換えるか、どの概念が完全に一致するか（同義語は気にしませんが、実際には概念について）、プロセス全体でどのような変更を予測できるかについて教えてください。

ありがとう。

4

6 に答える 6

3

まず、ClearCaseについて読むことができるいくつかの投稿を次に示します。

今：

  • CCRCは、「Webビュー」、つまりClearCase専用Webサーバー上のスナップショットビューを意味します...デスクトップとそのサーバーの間に良好なLANがある方がよいでしょう。

  • ブランチはClearCaseの第一級市民です。つまり、ClearCaseビュー（ここではスナップショットccwebビュー）を指定すると、1つのブランチにしかアクセスできなくなります。一度に複数のブランチで作業することに慣れている場合は、複数のビューが必要になります。

  • すべての操作はファイルごとであるため、プライベートブランチで作業してからマージするという考え方は、マージの数が多いため面倒です。複数の開発者が対処したい特定の開発作業について、共通
    のブランチで 作業することを強くお勧めします。 プライベートブランチとサンドボックスが必要な場合は、ClearCaseビュー内にGitビューを問題なく設定できます。 （注：スナップショットビューをサンドボックスと見なすことはできません。ファイルをチェックインすると、他のすべての開発者は、スナップショットビューの更新を行うときに変更を確認できます）

  • ClearCaseEclipseプラグインはリファクタリングをサポートしています。

  • svn：externalの概念は、リンクを介する場合を除いて、ClearCaseでは実際にはサポートされていません。または、UCMベースラインの依存関係を介して。
    ソースの依存関係よりもバイナリの依存関係を操作する方が簡単であることに注意してください。外部が次のプロジェクトの数千のソースファイルを含めるためのものである場合、ClearCaseでは（長い更新のために）面倒になります。いくつかのjarまたはdllを含めると、それははるかに高速になります（さらに、それらは実際にデプロイされるものです）。

  • UCMを使用している場合、あるコンポーネントから別のコンポーネントにコードを移動することはできません。clearfsimport新しく識別された「共通」コンポーネントのメインラベルを使用する必要があります。

  • 注：RCSキーワードの置換は一般的に考えられています...悪;）関連する重要なファイルのバージョンまたはラベルが含まれている別のテキストファイルをお勧めします。これは、ソースファイルではなく、配信資料に対しては正常に機能します。

于 2009-08-11T08:14:13.743 に答える
3

私の意見では、CCはアジャイルチームにとって悪い選択です。原則として、それを使用することはできますが、必然的にある程度の生産性が失われます。その程度の量は、CC管理者がどれだけ上手で思いやりがあるかによって異なります。開発チームのニーズを明確に理解する必要があります。

私たちのチームでは、CCで本当に悪い時期があります。私たちの管理者はリモートでチームの他のメンバーから隔離されているため、メールやリクエストトラッカーを介して管理者と通信する必要があります。あなたはそれがどれくらいの時間がかかるか想像することができます。このプロセスの費用と複雑さ（および管理上の負担）のため、最新のCCバージョンにアップグレードすることはできません。そのため、7.0バージョンのCC/CCRCを使用します。

このバージョンのCCRCは完全に最悪です。簡単にリファクタリングすることはできません。それと任意のマージを実行することはできません。ベースラインを作成することはできません。無視されたリストにファイルを置くことさえできません。ちなみに、私が知る限り、CCは、ネイティブCCクライアントではなく、後のCCRCバージョンでのみ無視されたファイルをサポートします。CCRCバージョンには、コマンドラインインターフェイスがまったくありません。

CCはサーバー通信に大きく依存しているため、CC（およびCCRC）は、開発者がオフラインで作業しようとすると、開発者自身に任せます。CCリポジトリは、CCRCまたはリモートデスクトップなしではリモートで使用できません（マウスクリックの応答時間は数分程度です）。

CCは、すべてのファイルを読み取り専用としてマークし、変更前に明示的にチェックアウトする必要があるため、他のツールに干渉します。したがって、Eclipseプラグインを使用すると、リファクタリングすることができます。しかし、他のツールでは運が悪いです。事前にファイルをチェックアウトするか、ファイルを強制的に変更して、ハイジャックされるようにする必要があります。別のIDE、sedまたはawkスクリプトなどを使用すると、問題が発生します。また、Eclipseのみを使用している場合でも、CCが遅いため、CCを含む操作（つまり、すべての名前変更リファクタリングなど）は遅くなります。

CCの唯一の良い点は、マージとマージ追跡が得意なことです。しかし、Subversion1.5はその点にかなり近づきました。そしてとにかく、それは私がCCを使うことに夢中にならない。

私の鋭い否定的な意見は、主に私の個人的な悪い経験によって形成されていることを認めます。しかし、完璧なプロセスと管理を備えた理想的なCCセットアップでも、とにかく生産性が低下することは間違いありません。これは、CCがサーバーに過度に依存しており、厳密なロックアプローチで「チェックアウト-チェックイン」しているためです。これには、予約されていないチェックアウトやハイジャックされた状態など、いくつかの「回避策」（私はむしろそれらをクラッジと呼びます）を提供しますが、それらは独自の問題を追加します。CCは常にあなたとあなたのコードの間に立っています。

ちなみに、IBMRationalは遅かれ早かれ顧客をJazzプラットフォームに移行すると思います。そのRationalTeamConcertは、「アジャイルフレーバー」を備えたものです。10人の開発者向けの無料版とCCとの統合があります（ただし、無料かどうかはわかりません）。だからあなたはそれを試してみることができます。ただし、IBMRationalの良い点は何も信じていません。

于 2010-07-11T02:49:47.220 に答える
3

ClearCaseの問題は次のとおりです。

ClearCaseは、デスクトップシステム上のワークステーションにディスクドライブさえなかった可能性がある1990年代に作成されました。スペースは言うまでもありません。さらに、デスクトップシステムはおそらくメモリが制限されていて低速でした。

ClearCaseは素晴らしい答えでした。ビューはビューサーバー上に存在する可能性があります。VOBはVobサーバー上に存在します。高速、高速、高速の専用マシン。

ClearCaseには、低速のマシンでコードのコンパイルを試行する代わりに、ウィンクインできる派生オブジェクトがありました。なんて時間の節約になりました！

また、ClearCaseのVOB構造は、ほとんどのバージョン管理システムでは実行できないことを実行できることを意味します。たとえば、名前cdを追加すると、ファイルに入れることができます。@@これにより、そのファイルのすべてのブランチ、タグ、およびすべてのバージョンを表示できました。標準のUnixツールを実行するだけで、違いなどを検索できます。

その後、世界は変わりました：

  • デスクトップシステムはより強力になりました。ディスクスペース、メモリ、および生の処理能力があります。ローカルドライブにチェックアウトワークスペースを作成すると（確かに1つあります）、ネットワークプロセスが増えるにつれて速度が低下しているネットワークに依存する必要がなくなりました。派生オブジェクトでウィンクしますか？ちなみに、私のマシンは、ClearCaseが適切な派生オブジェクトを見つけるよりも5倍速く吸盤を構築できました。

  • ウィンドウズ。ClearCaseはUnixを念頭に置いて設計されました。誰もがデスクトップにPerlをインストールしているため、フックはローカルシステムで動作でき、すべてが同じリビジョンであることを簡単に確認できます。localちなみに、適切なバージョンのPerlまたはインストールされているものを使用してNFSマウントされた/ usr / localディレクトリ（私は知っていますが、ネットワークディレクトリが一般的でした）を使用でき、フックは機能します。Windowsはそれほどうまく機能しませんでした。フックは頭痛の種になりました。

  • 再びWindows：ClearCaseはUnixツールに依存してうまく機能しました。Windowsにはそれらがありませんでした。

  • アジャイル開発：ClearCaseが開発されたとき、開発モデルは開発者を互いに分離するものの1つでした。別の開発者がシステムに変更を加えることを常に心配する必要がなければ、はるかに速く作業できます。ClearCaseでは分岐は簡単でした。全員に独自のブランチを与えることができ、完了したらメインブランチにマージして戻すことができます。前後にマージ！ClearCaseでは簡単です。ちなみに、UCMはまさにその基盤の上に構築されています。残念ながら、この戦略には完全な規律が必要でした。他の開発者がそれらを見ることができるように、開発者にコードをマージするように注意を促し続ける必要がありました。何十人もの開発者がすべて変更を統合ブランチにマージしようとするため、リリースの直前に避けられないマージクランチが発生しました。アジャイル開発は、開発者の分離の概念を取り除きます。あなたは小さな変更を加え、他の人がしていることを追跡します。したがって、「オプラ分岐」（分岐を取得します！分岐を取得します！誰もが分岐を取得します！）の概念は使用されなくなりました。

  • これで、十分なディスク容量とメモリを備えた高速システムができました。一度に3つまたは4つの個別のチェックアウトを行うことができます。動的ビューの利点は、犬の速度が遅く、ネットワークを集中的に使用するという欠点を単純に克服しませんでした。スナップショットビューは役立ちますが、かつてのClearCaseの魔法をすべて削除します。言い換えれば、そもそも単にCVSを使用できるのに、なぜCVSのようにClearCaseのように大きくてかさばるシステムを使用するのでしょうか。

  • 最後に、ClearCaseは難しいです。開発者がすべてシステムとネットワークの専門家であった昔は、ClearCaseの詳細を学ぶことが期待できました。ビューを作成することは、YACC構文を学ぶことほど難しくありませんでした。ただし、開発者はかつてほどシステムに精通していません。なぜそうすべきなのか？JavaまたはC＃でプログラミングするために、メモリがどのように機能するかを知る必要はありません。開発者は、仕事をするために100種類のツールについて学びたくなくなりました。ClearCaseのトレーニングには数日かかる場合があり、ClearCaseの詳細の学習には数週間かかる場合があります。ClearCaseでは、ブランチのコードを変更するなどの簡単なことを行うために、ビューの構文を理解する必要があります。CVSでは、それはたった1つのコマンドです。

ClearCaseは単純に複雑すぎて、遅く、高価です。そして、それの多くは、彼らがClearCaseを構築したときにAtriaが取った賭けでした：1）。とにかく100の他のツールを学ばなければならないので、開発者はそれを喜んで学ぶでしょう。2）。デスクトップマシンは、ネットワークサーバーに比べて低速で小型です。「クラウド内」ですべてを実行する方が高速です。3）。ClearCaseの集中化機能は、1つのサイトですべてを管理およびサポートできるため、企業にとって大きな利点です。

これらの3つの仮定はすべて誤りであることが判明し、そのため、ClearCaseを検討している企業はますます少なくなっています。RationalがPureAtriaを購入したとき、Rationalが21世紀にそれを小型化、軽量化、低価格化するために導入した場合でも、広く使用されているツールである可能性があります。しかし、Rationalは忙しすぎて、購入したすべての気の利いたツールを一元化された開発プロセスに統合するために、開発をより複雑にしました。IBMがRationalを購入するまでに、ClearCaseはユーザーの出血を始めていました。

于 2010-12-20T17:10:38.950 に答える
2

ギズモ、

私は現在、他の観点を除いて、あなたと同じ問題を経験しています-私はClearCase管理者であり、チームをSVNからClearCaseに移行しようとしています。

CCRCは、Javaを開発するために使用するツールとして宣伝されています。CCRC（ClearCase Remote Client）は、メインインフラストラクチャからリモートで作業する開発者を支援するように設計されていると私は完全に確信していません。アクセス速度を上げるためにコードはデスクトップに保存されますが、チェックインとチェックアウトのオーバーヘッドがあり、無視することはできません。

CCRCからリファクタリングは技術的に可能ですが、インフラストラクチャから切断されている場合はリファクタリングを実行できません。ツールでは使用できません。

EclipseワークスペースがCCRCビューにうまく適合することには、他にも問題があります。（環境の分岐構造によっては）ツールの絶対パス名に問題がある場合があります。

心に留めておくべきこと、そしておそらく調べるべきことは、ClearCaseがバニラスナップショットビューを実行するということです。私はVonC（おそらく初めて、彼は1人のhelluva管理者です）に同意しません。CCRCビュー（Webビューと呼ばれます）は、より多くのような環境で開発できるネイティブスナップショットビューとはまったく異なると思います。 SVN-特にJava開発を行う場合。

ClearCaseとHudsonについては、Andrew Bayerと話し合って、ClearCaseプラグインがDynamicViewsで少し簡単に機能するようにしました。これは0.9リリースで登場しました。彼はHudsonコミュニティの非常に活発なメンバーであるため、プラグインに問題がある場合は、発生した問題をすぐに修正する必要があります。

私ができる最大のアドバイスは、それが違うからといって、それが悪いという意味ではないということです。しばらくお待ちください。ドキュメントを読んで時間をかけると、ClearCaseが提供できる制御のレベルに驚かれることでしょう。

幸運を！

スチュアート

于 2009-08-12T12:37:46.477 に答える
1

Clearcaseは強力なソフトウェア構成管理ツールであり、日常の活動として概説したほとんどのことはClearcaseを介して可能です。

Clearcaseには、あなたが言及したサンドボックスに似たビューの概念があります。構成仕様（リポジトリから要素のバージョンを選択するための一連のルール）に関する基本的な知識があれば、分岐を行うのが簡単になり、異なる分岐で行われた変更のマージが適切にサポートされます。

サポートされているかどうかわからないアクティビティの1つは、キーワードの置換です。Clearcaseのサポートでキーワード置換が行われない場合でも、事前チェックイントリガーを作成して、キーワード置換を自動的に行うことができます。

しかし、Clearcaseとのすべてのやり取りがCCRC（Clearcase Remote client）のみを介して行われるかどうかは私にはわかりません。私はCCRCを使用したことがなく、CCRCを介してすべてがサポートされているのかわかりません。

于 2009-08-11T08:17:57.120 に答える
0

clearcaseは、私が今まで知っている中で最も強力なバージョン管理システムです。列挙されたすべてのタスクがサポートされます。

于 2009-08-11T08:00:24.833 に答える