あるソース管理ツールから別のソース管理ツールへの移行。助けてください？

Question

最近私は、PerforceリポジトリをTrueChange (McCabe TrueChange)に移行する必要があると言われました。私はその時点までTrueChangeについて聞いていませんでした。私はcvs、subversion、vss、perforceをこれまで使用してきました。私は、その移行を行う上での知恵の言葉と、TrueChangeから期待することを見つけようとしています。私はPerforceでの作業が大好きでした。私はPerforceへの移行がかなり簡単であることを発見しました。

お手伝いできますか？私はVS2005、RAD、CruiseControlを使用しています。

Answer 1

私は1999年9月からTRUEchangeを使用していますが、PERUEからTRUEchangeに移行する必要があると言われたことは幸いです。

私は多くのオープンソースの自家製CMソフトウェアシステムで働いていました。遠く離れたTRUEchangeはこれまでに使用した中で最高の製品です。 （つ以上がある - これらは、4つの重要なものである）TRUEchangeはとても良い作り

つの事：をベース代わりに、ファイルの差分をもと

1. 変更セット。 50個のファイルがグループとしてチェックアウトされ、変更された後にチェックインされると、それらの50個のファイルへの変更は、変更セットと呼ばれる単一の単位になります。 TRUEchangeは、これまで使用してきたCMソフトウェアよりも並行した並列ベースラインを処理します。 Csetsは、低い番号のベースラインに移行することも、高い番号のベースラインに移行することもできます。移行/マージの競合はまれであり、クライアントには非常に容易に競合を処理できる3方向マージツールが組み込まれています。変更セットは特定のバージョンから任意の順序で削除することができ、再度追加することができます。5つの異なる変更セットでファイルに5つの変更があった場合、変更1、3、4を残して2番目の変更を削除できます5つはそのまま。また、あるディレクトリから別のディレクトリへのファイルの移動、ファイルの名前の変更、またはディレクトリ名の変更をサポートするための完全なメタデータを保持します。ファイルは削除でき、ファイルを削除する変更セットがあります。ファイルを削除する変更セットは、ファイルのファイルID、ファイル名、および親ディレクトリの内容を保持するため、ファイルをシステムに再度ロードすることなく、いつでも復元できます。ファイルが復元されると、変更履歴が復元されます。

2. の代わりにプロジェクトバージョンに基づいています。バージョンがチェックポイントされると（タグ付けと同様）、プロジェクト全体のすべてのファイルの内容が1つの単位として記録されます。 5000個のファイルの個々のバージョン番号を追跡する代わりに、それらのファイルを含むプロジェクトのチェックポイントを追跡するだけで済みます。ファイルのバージョンを追跡する必要がないので、QAまたは展開用に構築されたものの履歴を維持することは「単純ではありません」。 TRUEchangeは、ビルド設定を使用して関連プロジェクトをグループ化し、Unix/Linux、Windows、またはVMSファイルシステム上でビルドプロセスのためにファイルが抽出されたファイルパスをグループ化します。 2.1.0などの3つのセグメントバージョン番号を使用します。バージョンの最初のビルド（または反復）は、2.1.0.1になります。 2番目は2.1.0.2となります。ビルドを実行して完了すると、ビルド構成の詳細を取り、2つのデータベーステーブルにデータを挿入します。 1つのテーブルには、ビルド構成名、メジャーバージョン番号、マイナーバージョン番号、サブバージョン番号、反復、記述タイトル、ビルドタイプ（QAまたは生産）、完了日時などのビルド構成レベル情報が含まれています。もう一方のテーブルには、最初のテーブルのビルド構成レベルの行を指す外部キーが含まれており、プロジェクト名、メジャー・バージョン番号、マイナー・バージョン番号、サブバージョン番号、およびビルドの実行に使用されたチェックポイントからの反復が含まれています。構成レベル情報とプロジェクトレベルの情報をビルドすることで、データベースにクエリを実行し、ビルド実行の正確な内容をすぐに知ることができます。私たちは現在、2001年9月からビルドの歴史を持ちます。ビルド数は約33,500、子レコードは228,000を超えています。1〜2分で、私は過去8年間に実行されたすべてのビルドのソースディレクトリ構造を再現することができました。ビルドの実行とは完全に正確で同一であることがわかります。ファイル・ベースのCMシステムでそれを実行しなければならない場合は、任意のビルドを再作成するまでにかなりの時間がかかります。

3. コマンドラインコマンド、Windows GUI、Java GUIクライアント（StreamCM）、カスタマイズ性と信頼性。 TRUEchangeには、多数のコマンドラインコマンドがあり、高度な自動化が可能です。シェルスクリプトとPHPを使用することで、開発者がCMシステムと対話するための完全自動化されたビルドサイクルとカスタマイズされたWebインターフェイスを開発することができました。開発ビルドは、TRUEchangeからのファイルの取得がWebページから実行される構成管理ユーザーとして実行されます。これにより、エンジニアがチェックインしたコードがCMで実行されたときにビルドされることが保証されます。 StreamCMは、Unix（Solaris、AIX、HP-UX、Irixなど）、Linux（Red Hat、Fedora、Gentooなど）、Windows（XP、Vista）、MacOS（PPCおよびIntel ）。この統一されたインタフェースにより、開発者は複数のプラットフォームを使用して、OSに関係なくクライアントを同じように動作させることができます。 TRUEchangeは、スクリプト言語を使用して高度にカスタマイズできます。 PostgreSQLで動作するCMデータベースと相互作用するようにTRUEchangeをカスタマイズしたので、WebベースのアプリケーションはCMシステムに問い合わせるのではなく、データベースからメタデータを読み取ることができます。また、TRUEchangeをカスタマイズして、Oracleデータベースへの接続を介してMercury Interactive Test Directorの問題追跡システムと対話します。信頼性が高い。ほぼ10年で、ディスクエラーのためにバックアップに戻る必要があるリポジトリに1つの障害が発生しました。 TRUEchangeは各リポジトリに対してポストされたトランザクションを維持するので、最初に適用された順序でリポジトリを変更したトランザクションを再生することができました。これは軽く使われたリポジトリでしたが、3日間の期間からすべてのトランザクションを再生するのにわずか10分しかかかりませんでした。当社は200を超えるユーザーライセンスを保有しており、ユーザーベースをサポートするCMエンジニアは2人以上にはなりませんでした。 2008年には、他のCMエンジニアと私は6300以上のQAビルドを実行し、実稼働展開のために1800を超える展開イメージを作成しました。 TRUEchangeはこれまで使用してきた他のCMシステムと比較して、大幅な管理の必要がありません。もう一つのプラスは、顧客のニーズに基づいて製品を強化するMcCabeの意欲です。我々は何年にもわたって数多くの機能拡張を求めてきましたが、それらはすべての要求に応え、期待を上回りました。 TRUEchangeのもう一つの素晴らしい点は、分散環境で動作するように設計されていることです。ライセンスマネージャーは、システムへのアクセスを制御し、リポジトリーが実際に稼働しているサーバーを追跡します。私たちには、ライセンスサーバーと、97のリポジトリを実行する4台のLinuxサーバーがあります。追加のリポジトリを格納するためにサーバを追加する必要がある場合、リポジトリを作成したり、既存のサーバを新しいサーバに移動したり、自動プロセスで開始スクリプトと停止スクリプトを再作成したり、新しいサーバー上のリポジトリを起動します。クライアントの介入は必要ありません。そして、私たちはほぼ5200万行のソースコードとバイナリファイル（gifファイル、jpegファイルなど）を管理しています。

4. CruiseControl Plugin。最新のソフトウェアリリースで、McCabeはTRUEchangeの統合を可能にするCruiseControlプラグインを開発しました。現時点ではCruiseControlは使用されていません。なぜなら、当社のソフトウェアは非常に複雑で多くの相互依存性を持っているからです。これはTRUEchangeの欠点ではなく、CruiseControlの欠点です。他のシステムに大きく依存しないスタンドアロンシステムに最適なようです。

簡単TRUEchange ITTに別のCM製品から移行するためには、単に指向のファイルに対して指向プロジェクトの概念を把握して、何にアクセスし、どのようなレベルでできるセキュリティ要件を（満たすためにリポジトリを設定しています）とソフトウェアシステムの論理的なプロジェクト構成。リポジトリとプロジェクトが正しく設定されていれば、それは単に古いCMシステムからファイルを取り出してTRUEchangeプロジェクトに一括してロードすることに過ぎません。