私は、InterSystems Ensemble (InterSystems Caché 上に構築された統合フレームワーク) を使用して開発を開始しているグループに所属しています。
インターシステムズは、Ensemble 管理ポータルをソース管理対応にしていません。これは、開発チームが対処したい問題の原因のようです。
Ensemble/Caché で使用しているバージョン管理システムと、それを中心に開発プロセスをどのように構築しているかを知りたいです。
私は、InterSystems Ensemble (InterSystems Caché 上に構築された統合フレームワーク) を使用して開発を開始しているグループに所属しています。
インターシステムズは、Ensemble 管理ポータルをソース管理対応にしていません。これは、開発チームが対処したい問題の原因のようです。
Ensemble/Caché で使用しているバージョン管理システムと、それを中心に開発プロセスをどのように構築しているかを知りたいです。
もう 1 つの選択肢は、Caché 専用に設計されたTrackWareのようです。
Caché 用に設計されたバージョン管理システムであるVC/mを見つけました。
経験したことがある場合は、コメントを追加してください。
開発作業を恐れていない場合は、スタジオを現在のソース管理ツールに接続するための開発を行うことができます。ファイルの変更を検出し、ソース管理ツールと対話できるようにするフックが Cache に用意されています。
ここでは、基礎を説明する pdf へのリンク: Using the Studio Source Control Hooks
もちろん、このソリューションでは、自分で多くの作業を行う必要があります。
私はMercurialを使用しており、Cache Studioソース管理フックを使用していますが(アンサンブルは使用していません)、基本的に同じソリューションで機能すると思います。
重要なのは、それが分散ソース管理であるということです。したがって、フックが行うのは、保存時に、現在のファイルをハードドライブ上のフォルダーにエクスポートし、ローカルリポジトリにチェックインすることだけです。ローカルで正常に機能している場合は、中央リポジトリにプッシュします。つまり、通常の方法で分散ソース管理を使用します。
何かを台無しにした場合にロールバックする方法が得られるので、各保存をコミットするのは良いことですが、実際には必要ありません。キャッシュコマンドプロンプトからコードを呼び出すときに、コードをローカルリポジトリにプッシュするものを記述できます。
分散ソース管理では、チェックイン機能とチェックアウト機能がサポートされていないという事実は重要ではありません。中央リポジトリにプッシュするときにマージすることでこれらの問題を処理します(またはリポジトリを構造化することにします)。
1つの警告-キャッシュクラス定義の場合、定義していない形式でXMLとしてエクスポートされます。これには、ファイルが生成された日時のタイムスタンプと最終更新日が含まれます。これらは、ソース管理システムをだまして、変更されていないのに変更されたと思い込ませます。したがって、少なくともそれらを取り除くのに十分なだけXMLを解析する必要があります。そもそも生成を防ぐためのフラグを知りません。
SynervaのCodeToolsは、そのための非常に優れたソリューションを提供します。かなり長い間、いくつかのプロジェクトでそれを使用しています。
ベストソリューション!幸運を!
返信が遅くなりましたが、とにかく - Synerva の CodeTools をご覧ください。. CodeControl は Studio プラグインとして機能します