15

仕事では、現在 ClearCase を使用しています。ただし、多くのオーバーヘッドが必要です。特に誰かが愚かなことをした場合 (トランクで複数の予約済みチェックアウトを使用してビューを消去するなど)。私たちはオーバーヘッドを減らし、できるだけ軽量にしようとしているので、CC の機能の 90% を使用しない方法を見て、CC を捨ててより軽いもの (Subversion または Mercurial) を使用する可能性について調べました。とりあえず。これは合理的に聞こえますか、それともフェラーリをステーションワゴンと交換しますか?

4

13 に答える 13

28

私の経験からすると、ClearCase には確かに多くのオーバーヘッドがあり、SVN でうまく管理できました。

私は「ダウングレード」に投票します (実際にはアップグレードです)。;)

于 2008-10-05T14:32:38.423 に答える
18

私が学んだ主なことは、製品よりもプロセスが重要だということです。

SVN タイプのモデルを使用して ClearCase (CC) を実装した場合、SVN は問題なく動作し、はるかに安価になります。

一方、時間と労力を節約し、信頼性を向上させる上で非常に有利に使用されている遅延分岐、ラベルによるビルド、および動的ビュー (または可能) を使用している場合は、これらの機能を失うことを非常に後悔することになります。(ビルド管理、UCM などは言うまでもありません)

ほとんどの人は、ラッシュアワーの渋滞でフェラーリを使うのと同じように、最初の選択肢を使用します...

例？ラベル GA、SP1、SP2 を定義します (GA と SP1 の間に好きなだけリリースを含めることができます。関連性はなく、CC ラベルは SVN と同じではないことを覚えておいてください)。GA がベース リリースで、SP1 が現在のリリースです。SP2 は次のリリースです。現在のリリースは、GA および SP1 に基づいています。次のリリースは、GA、SP1、および SP2 に基づいています (CC 構成仕様を参照)。

QA を開始します。開発は「次のリリース」に向けて継続的に行われており、ユーザーは GA と SP1 を参照 (変更ではなく) し、SP2 を適用することができます。メンテナンスは、QA によって発見された不具合を修復する作業を行っており、GA を参照し、SP1 を適用できます。

ケース 1: ClearCase では、SP1 ラベルを適用するだけで、Dev SP2 リリース チームが修正を自動的に利用できるようになります。仕事がありません。なだ、ゼロ。

Subversion では、QA ブランチで変更を行ってから (忘れずに) 変更を SP2 に移行します。

ケース 2: ご質問の前に、確かに、SP2 の変更を追加する場合は、SP1 の後続の変更を追加するために分岐する必要があります。これは、ほとんどのシステムと同様です。

私の世界では、実際の数字: ケース 1 は、私の最後の SP (年間 8 SP) で 122 回発生しました。年間 800 以上の変更を ClearCase で行う必要はありませんでしたが、Subversion モデルを使用していれば変更する必要があったでしょう。

ケース 2 は、CC をインストールした 2002 年初頭から 6 回発生しています。

製品だけでなく、プロセスを見てください。

(長々とすみません、そんなに長くは始まりませんでした:-)

于 2008-10-06T17:04:14.983 に答える
6

以前のポスターに同意します。IBM 製品を捨てて、オープンソースのソース管理製品に移行することは、ダウングレードではありません。これらの軽量で使いやすいツールにきっと満足していただけるでしょう。私たちのショップでは、CVS から SVN への移行を進めており、その結果に非常に満足しています。

于 2008-10-05T14:42:39.323 に答える
5

clearcase から subversion への移行は、間違いなくアップグレードだと思います。

于 2008-10-05T14:38:18.070 に答える
4

ClearCase LT から SVN に移行しましたが、とても気に入っています。維持費で多くの現金を節約しており、すべてが以前と同じように機能しています。

SVN を推奨する前に、Git などを調べておけばよかったのにと思います。

于 2008-10-06T17:15:39.547 に答える
3

私はあなたの「スイッチ」に問題はありません。UCMを使用する相互依存プロジェクトがあまりない場合は、アップグレードになります。

私はSCM（ClearCaseとSubversion）の両方を管理しており、中小規模の独立したプロジェクトにはSubversionをお勧めします。

ただし、開発者がClearCaseの動的ビューに慣れていないことを確認してください。これはファイルシステムのカプセル化であり、ユーザーがネットワークからファイルにアクセスできるようにします。私の知る限り、この種のアクセス権を持つのはClearCaseだけです。

そして、パラダイムシフトを考慮に入れてください。

  • ClearCaseはファイル中心です（取得するすべてのファイルは読み取り専用であり、作業しているファイルのみをチェックアウトします）
  • Subversionはリポジトリ中心です（取得するすべてのファイルは読み取り/書き込みであり、1回のアトミックコミットですべての変更/追加/削除されたファイルをチェックインします）
于 2008-10-05T17:01:44.007 に答える
3

あなたが切り替えることをお勧めします。機能を使用していない場合、商用価格のソリューションを使用するのはビジネス上の選択としては適切ではありません.

現在、「無料」ソリューションにも関連するコストがあります。SVN も Mercurial も商用レベルのサポートを提供しません。これが問題であり、状況によっては確かにそうなる可能性がある場合は、実行したくない場合があります。

あなたが言及した2つのうち、SVNは、現在集中型VCリポジトリを使用している場合に選択する必要があるものです. SVN の運用モデルは単純で直感的なものであるだけでなく、SVN にはオープン ソース プロジェクトで私が今まで見た中で最高のドキュメントと開発者コミュニティがあります。ユーザーのメーリング リストは素晴らしく、開発者はユーザーに迅速に対応し、責任を負います。Red Bean ブックは、オープン ソース マニュアルの中で最高の 1 冊です。

于 2008-10-05T15:29:39.590 に答える
2

私が ClearCase で気に入った点で、他の SCM ツールではうまくできなかったか、まったくできなかった点:

  1. 開発者ブランチでの作業は簡単でした。CC (UCM) では、ストリーム (別名ブランチ) で作業し、一連の作業を統合ストリームに「配信」します。一方、他の開発者も同じことをしています。次に、インテグレーター (おそらく開発者の 1 人) は、統合ストリームでいくつかのテストを行い、すべてがビルドされていることを確認し、場合によってはスモーク テストを行ってから、すべての開発者の作業を含む新しいベースラインを推奨します。その間、あなたは支店で働き続けます。次回配信するとき (または必要に応じて配信前) に、新しいベースラインが利用可能であることを確認して、ストリームにマージします。実際、新しいベースラインが利用可能な場合は、リベースを余儀なくされます。Microsoft Team Foundation Server と SVN でこれを試してみました。まず、CC の強制リベースのようなポリシーを強制する方法が見つかりませんでした。そのため、最後のマージ以降に行ったリビジョンと、それ以降トランクで行われたことを把握し、トランクからブランチにマージする必要がありました。次に、新しい作業をトランクにマージしたいときに、ブランチにマージしたばかりのものすべてと、新しい作業を再マージする必要がありました。
  2. 開発者ブランチは、効果的なコード レビューに役立ちました。私がCCを使っていたときは、すべて見直しました。しかし、実際にはレビューには時間がかかり、作業を続ける必要がありました。各作品は、CC のアクティビティに対応しています。レビューが完了して初めて、アクティビティを統合ストリームに配信しました。レビューで変更が必要な場合は、元の作業で行ったアクティビティに変更を加えるか (そのアクティビティで変更されたファイルにその後の変更が加えられない限り)、レビューの変更に対処する新しいアクティビティを作成するか、またはアクティビティ全体を吹き飛ばして最初からやり直す可能性があります (これも、その後の変更がない限り)。TFS や SVN では、一度何かをコミットすると、その後の作業を吹き飛ばさずに簡単に戻ることはできません。そのため、他の開発者に変更を示す別の方法を見つける必要がありました。これは最終的にウェブページに変換された差分でしたが、それでも、レビュー待ちの作業と混ざらない限り、これ以上作業を進めることはできませんでした。
  3. 動的ビューを使用すると、クロスプラットフォーム開発が容易になります。ここで比較するのは SVN しかないので、Mercurial などの方が優れているかもしれません。私の目標は、Linux と PowerPC の両方のプラットフォーム (および別のプロジェクトでは Windows) で変更、ビルド、テスト、デバッグを行い、すべてのプラットフォームで動作することを確認したら、単一の変更セットをコミットすることでした。PowerPC のビルドでは、ターゲットのビルドとテストに使用する Sun ワークステーション (動的ビューにアクセス) がありました。速度が遅かったので、ほとんどのコーディングとデバッグを Linux で行い、PowerPC でビルドとテストを行った後、(PowerPC) ターゲットで最終テストを行い、最後にチェックインしました。これを回避する 1 つの方法は、ネットワーク ファイル共有です。ここで見た問題の 1 つは、Windows 上の Linux svn と TortoiseSVN の間のバージョンの非互換性です。Tortoise を Linux リポジトリのコピーに入れると、.svn ファイルが変更されます。Linux svn は、バージョンが新しすぎると不平を言います。(ターゲットに選択したプラットフォームが原因で、Linux ボックスを新しい十分な svn にアップグレードできませんでした。) そのため、Linux svn リポジトリで Windows diff ツールを使用できません。逆に、Windows チェックアウトと Windows リポジトリの Linux マウントを使用すると、シンボリック リンクは保持されません (Linux ビルドで必要です)。

ClearCase を維持することは悪夢であり、お金がかかります。しかし、セットアップが完了すると、非常に優れた開発環境を提供できます。特に、ClearQuest (コード レビューの追跡にも使用した欠陥追跡) との統合を開始する場合は特にそうです。

別のレスポンダーが述べたように、あなたへの答えはプロセスのニーズに大きく依存します。

于 2009-10-28T19:19:12.763 に答える
2

私の前の会社 (CMMi プロセス) では、約 100 人の開発者/テスター/インテグレーターが ClearCase (CC) を使用しており、常勤の管理者は 3 人です (任意のパートタイムの 2 人を追加)。構成管理部分 (ベースライン) を使用しない限り、最新の SCM に移行する必要があります。ベースライン機能は強力です。従来の SCM では、更新/リベースすると、デフォルトで最新のリビジョンが取得されます。ベースラインは、ビルドが正常であることを確認するための、特定の「互換性のある」リビジョンのソフトウェア コンポーネントのセットです。ある意味、これは依存関係のビルド (つまり、Maven、Ant Ivy) に似ています。開発者がベースラインをリベース (更新) すると、「ビルド可能」であるべきものが得られます。

今、私の新しい会社 (アジャイル ショップ) から振り返ってみると、SVN と Mercurial を使用しており、CC は毎日の苦痛だったと思います。CC を使用してプロジェクト (リポジトリ) で作業するには、ビューを作成し、アクティビティを作成してから、ファイルをチェックアウトします。一部の同僚はブランチを作成することを恐れていました :) . SVN と Mercurial では、GUI クライアントにこのような問題はありません。開発者は毎日 10 回コミットします。対 CC ユーザーは 1 日 1 回チェックインします。

実際、CC には多くのオーバーヘッドがあり、ネットワーク レイテンシが遅く、ライセンス コストが高く、専任の管理者が必要です。では、構成管理以外の利点は何ですか。

Mercurial では、ワークフローが軽くなります。現在のプロジェクトでは、ソースファイル以外をコミットしてめちゃくちゃになりました。Hg の歴史は不変です。管理者はいません。ある開発者は、半日で新しいプロジェクトを再クローンしました。Clearcase では、削除されたファイルをバックアップするためだけに専門家に依頼する必要があります:)。新しいレポを作成するには、管理者に依頼してください:)

ClearCase から離れてから、SVN、特に Mercurial に満足しています。したがって、ClearCase から Mercurial への移行は、プロセスの点で非常に軽量になり、生産性が向上します。

SVN と Mercurial の選択は? 集中リポジトリか分散リポジトリかを自問する必要があります。スタックオーバーフローで簡単に検索できます。

私は IBM Rational 製品を嫌い、洗練されたオープン ソース ソリューションを好むようになりました。

これを読んで理解したなら、タイトルは「clearcase から svn-mercurial へのアップグレード」にすべきです。

追加: Clearcase は推奨のしきい値を下回っていますが、Mercurial、Subversion、および Git は明確に推奨されています。 http://martinfowler.com/bliki/VersionControlTools.html
Mercurial と Clearcase を組み合わせることもできます。「複数のVCS」の段落を読んでください

于 2011-01-26T21:54:21.297 に答える
1

HG Init - SVN から Mercurial への切り替え方法に関する Joel Spolsky によるガイドを読むことをお勧めします。

以前の回答で述べたように、SVN と ClearCase は基本的に同じパラダイムで動作するため、この記事を読むと、「Subversion」という言葉をすべて「ClearCase」に置き換えて、状況に適用することができます。

これは、仕事で Mercurial を使い始めることを最終的に確信させた記事です。

于 2010-05-19T21:12:42.910 に答える
1

私はここ数週間、CVS を置き換えてアジャイルの採用をサポートするために採用する SCM (ソフトウェア構成管理) および ALM (アプリケーション ライフサイクル管理) ツールを新しい仕事で調べていました。

並列開発と分岐を備えた真の SCM をサポートするものを探しているなら、おそらくあなたが思っているよりも多くの選択肢が存在します。

シンプルな SCM ソリューションについては、以下を参照してください。

  • Accurev:これは、ストリーム/並列ベースの開発をネイティブでサポートする SCM ツールです。これは非常に優れたストリーム ブラウザを提供し、ストリームのグラフィカル ビューを提供し、変更を課題または変更セットとしてグラフィカルにプロモートできるようにします (一連のソース ファイルのアトミック プロモートを強制します)。変更管理を提供し、タスクベースの方法で作業できるようにするための問題トラッカーが組み込まれています。AccuFlow を使用すると、ワークフローで変更をより詳細に制御でき、Accubridge は IDE 統合を提供します。
  • Seapine Surround:これは見栄えの良いツールで、分岐には適していますが、Accurev ほど高度ではありません。Seapine の優れている点は、問題追跡ツールである TestTrack Pro と、テスト ケース管理ソリューションである TestTrack TCM (TestTrack Stuido に統合されている) との統合です。最後に、Web および winforms 自動テスト ツールである QA Wizard Pro もあります。
  • PureCM:これは非常に人気のあるもう 1 つの代替手段ですが、詳しくは調べていません。
  • Perforce:この分野のもう 1 つの選択肢で、あまり感銘を受けませんでしたが、画像を比較してマージする機能など、興味深いニッチな機能がいくつかあります。
  • プラスチック SCM:未熟な製品ですが、非常に興味深い製品です。

これらのソリューションはすべて、(ClearCase でクレイジーなビューを使用する代わりに) 開発者サンドボックスやバージョン スナップショットなどの概念をネイティブにサポートする ClearCase よりもはるかに優れた分岐サポートを提供します。基本的に、ベースラインに少し似た読み取り専用ブランチです。

大規模な Rational デプロイメントがある場合は、次の代替手段を検討することをお勧めします。

  • MKS Integrity:テスト実行ビューが組み込まれた優れたポートフォリオ管理ツールを備えた、うまくまとめられた優れた製品です。そのツールはすべて 1 つの IDE に収まり、非常にカスタマイズ可能です。
  • Serena CM:ここでも、コア ALM ソリューションに関する広範なツールを備えた十分に優れたスイートです。非常に大きなポートフォリオ管理の要素であり、Mashups コンポーネントによる多くのビジネス プロセス サポートとプロトタイピングのサポートがあります。
  • Telelogic:皮肉なことに、現在は IBM の一部であり、まもなく IBM の合理的な組織になります。その SCM ソリューション (Telelogic Change and Synergy) は、コード変更をタスクごとに明示的にリリース ビルド ブランチにプロモートする機能を備えた、私が見た中で最高のものです。

上記のソリューションはすべて、Accurev などと同じ SCM コンセプトをサポートしていますが、明らかによりエンド ツー エンドの製品であり、エンタープライズ規模です。

この時点で、選択を MKS または Telelogic のいずれかに絞り込みました。

これに関する私の最大のポイントは、ClearCase と CVS/Subversion の間には、非常に多くのソリューションがあり、それらは商用でありながら非常に安価であるということです。

これが役に立ったことを願っています。

于 2008-10-24T13:57:46.073 に答える
0

あなたは git/mercurial で満足し、おそらく SVN では満足しないように思えます。OTOH、私のclearcaseの経験はすべて退屈で愛情のないものだったので、「逃げる」アクションは本当に良いことだと思います。

分散型システムは、ワークフローにより適しているように思えます。

于 2009-10-30T20:17:02.073 に答える
0

ブランチ構造がどのように設定されているかについてお聞きしたいと思います。

ユーザーが製品の「トランク」に取り組んでいるのはなぜですか? （これはあなたのメインブランチを意味すると思います）。開発ブランチは、開発者がメイン トランクに影響を与えるのを妨げませんか?

rmview スクリプトにトリガーを導入して、ユーザーがチェックアウト中にビューを削除できないようにできなかったのはなぜですか? これは非常に簡単な作業であり、オンラインにはたくさんの情報源があります (質問すれば、StackOverflow が答えを提供してくれるはずです!)。

もう 1 つの提案は、IBM 製品に既に投資している現金がある場合 (したがって、商用サポートされている SCM 環境にお金を費やす意思がある場合) は、Team Concert と Jazz を検討することをお勧めします。

于 2008-10-24T13:12:59.440 に答える