問題タブ [multiple-repositories]

2 つのエンティティ マネージャーを使用してリポジトリ パターンを実装しました。mainManager は読み取り専用と削除用で、updateManager は編集と新しいエンティティの追加に使用されます。createEmptyCopy() を使用して updateManager を作成します。

エンティティを更新する前に、エンティティを mainManager からエクスポートして updateManager にインポートします。変更後、updateManager.saveChanges() メソッドを呼び出します。

promise 応答で更新されたエンティティが返されることに気付きました。これらのエンティティを mainManager にインポートするベスト プラクティスは何ですか?

ここに私のコードがあります:

今、私は mainManager.clear() を呼び出しており、上記の getDomains 関数でわかるように、サーバーからデータを再度取得しています。しかし、これは広すぎると思います。saveChanges promise から更新されたエンティティが既にあるのに、なぜサーバーを呼び出すのですか?

私はまた、これらのエンティティをmainManagerにインポートしようとしました:

しかし、私は内部ヌル微風例外を取得します:

エラーはこの行からのものです Breeze.debug.js:13081

私はいくつかのライブラリを出荷しようとしていますが、次のようなものを作成したいと考えています:

次のように、ライブラリのみをバージョン管理します (例として)。

サブモジュールを維持するためのメイン リポジトリ(「Project/Assets」にチェックアウト)

サブモジュール 1 (「Project/Assets」にチェックアウト):

サブモジュール 2 (「Project/Assets」にチェックアウト):

サブモジュール 3 (「Project/Assets」にチェックアウト):

そのようなリポジトリ構造をセットアップする方法はありますか? いくつかの gitignore の微調整？それとも、他の git の概念はありますか? 「維持できる」もの。

理由を尋ねるかもしれません:サブモジュール 1 にはオープンソースのライブラリが含まれているため、ユーザーは自分のProject/Assetsフォルダーにチェックアウトする必要があります。Project/Assetsさらにサブモジュールにはクローズド ソース化/収益化ライブラリが含まれますが、ユーザーは残りのライブラリと同様にフォルダーにチェックアウトする必要がありますが、すべてをProject/Assets/AwesomeLibrariesフォルダーに並べる必要があります (一種の「自動的に」)。

特定の方法で動作するように複数の git リポジトリを設定する方法 (可能であれば) を理解しようとしています。基本的に、複数のクライアント用に複数のリポジトリがありますが、それらはすべてシステム ディレクトリを共有することを意図しています。1 つのクライアントのシステム ディレクトリに変更を加える場合は、すべてのクライアントのシステム ディレクトリに変更を加える必要があります。複雑なことに、CI 開発システムに使用する複数の環境があります。現在、本番環境、クライアントrev環境、qa環境、開発環境があります。これらは、ワークフローが次の環境で承認されたときに、そのワークフロー ブランチを適切な環境ブランチにマージし、そのワークフローからの変更のみをその環境に追加できることを意味するため、さまざまなブランチに適切に変換されます。

問題は、コード構造が、ベース コードであるシステム ディレクトリ、クライアント固有のコード (システム コード内のファイルの代わりに使用されるファイルを含む) を持つカスタム ディレクトリ、およびクライアント固有のディレクトリを持つように設定されていることです。構成ディレクトリ。カスタマイズを容易にする継承や拡張がないため、開発をさらに複雑にするオブジェクト指向システムを使用していないことに注意してください。

私たちの目標は、この開発システムを GIT に変換することです。私たちが抱えている問題は、その共有システム ディレクトリを維持することです。サブモジュールを試してみましたが、サブモジュールは上書きやミスポイントを防ぐために多くのメンテナンスを必要とし、クライアントのqaブランチが常に指していることを確認するための過度の退屈な作業量のため、永続的な環境ブランチではうまく機能しません.システム サブモジュールの qa ブランチのリード コミットであり、WF ブランチのリード コミットではありません。

私たちの現在の IDE は、サブツリー統合を持たない eclipse です (ただし、サブツリーについて私が読んだことは、サブツリーはサブモジュールと同じくらい複雑になる可能性があるということです)。本当に必要なのは、伝播される複数のリポジトリにまたがる並列ブランチです。たとえば、クライアント リポジトリでワークフロー ブランチを作成すると、システム リポジトリと他のすべてのクライアント リポジトリで WF ブランチが作成されます。そして、変更を加えてそのワークフローを qa にマージすると、システム リポジトリの wf ブランチも qa ブランチにマージされますが、システム フォルダーへの変更のみがあり、custom および config ディレクトリに加えられた変更は含まれません。

このようなものを機能させるための良い構造があるかどうか疑問に思っていました。私が他のサイトや情報源で読んだことはすべて、解決策はそのようにしないことだと言っていますが、その決定は私が行ったものではありません. 上層部は、現在の開発システムを維持することを決意しています。

私が考えたことの 1 つは、システム モジュールだけを含むリポジトリを作成するパススルーのようなことを行う方法があるかどうかを確認することです。次に、クライアントごとにそのレポを複製し、custom ディレクトリと config ディレクトリを追加します。次に、開発を行うときに、そのクライアントのリポジトリを複製します。この方法で、変更を加えてコミットしてアップストリームにプッシュした場合、これにより変更がトップレベルのリポジトリにプッシュされるかどうか疑問に思っていました。また、変更をプルダウンするときに、最上位のレポからずっとプルできる場合。これの反対側は、ストリームをプッシュするときにカスタムおよび構成ディレクトリを無視するが、ダウンストリームにプルするときにそれらのディレクトリが含まれるように、クライアントリポジトリに .gitignore を設定する必要があることです。

これに関する任意の考えをいただければ幸いです。また、コード ホストはプライベート gitlab サーバーです。

長くなって申し訳ありませんが、少し説明が必要な非常にユニークな (良くない) システムがあると思います。

将来の Git ユーザー

1 台のマシンで開発した Java バックエンド アプリケーション用の最初の GIT リポジトリ (ssh://git@myserver:7999/swlab/java_be_app.git) と 2 つ目の GIT リポジトリ (ssh://git@myserver:7999) があります。 /swlab/dotnet_app.git) は、別のコンピューターで開発した .NET アプリケーション用です。はい、SSH と、両方のリポジトリの同じアカウントの同じキーを含む「C:/Users/xxxxxxx/.ssh/id_rsa.ppk」ファイルを使用しています。

ここで、2 台目のコンピューターがクラッシュしました。HDD が RIP になり、メモリがフリーズし、CPU が何も処理されなくなりました。そして、1 台のマシンで両方のアプリケーションの開発を続ける必要があります。TortoiseGit を GIT クライアントとして使用しています。

2 つのリポジトリを 1 つにマージすることは、多くの理由から選択肢ではありません。これらは 2 つの異なる顧客のための 2 つの異なるアプリケーションであり、プライバシー、コード、およびデータ セキュリティの非常に深刻な問題もあります。

同じ Windows マシンの同じアカウントで両方のリポジトリを使用するにはどうすればよいですか?