問題タブ [repository-design]

ほとんどの Subversion ツールは、/trunk、/branches、および /tags を使用してデフォルトのリポジトリ レイアウトを作成します。ドキュメントでは、コードをより簡単に共有できるように、プロジェクトごとに個別のリポジトリを使用しないことも推奨しています。

そのアドバイスに従った結果、次のレイアウトのリポジトリができました。

など、おわかりでしょう。時間が経つにつれて、この構造が少し不器用であることがわかり、次のような推奨事項の別の解釈があることに気づきました。

では、人々はどのレイアウトを使用し、その理由は? または - 私が完全に逃したことを行う別の方法はありますか?

最初の警告: 長い投稿で、とにかくパターンが完全に間違っている可能性があります:

Customer Aggregate の開始である次のクラスがあるとします。

また、CustomerType は値オブジェクトで表されます。

CustomerTypeId を持つ顧客オブジェクトがある場合は、これで十分です。ただし、MVC ビュー内に DropDownList を設定する場合、ICustomerTypeRepostory から CustomerType 値リストを正しく取得する方法の概念に苦労しています。

はICustomerTypeRepository非常に簡単です。

基本的にはコントローラーから正しく呼び出せるようにしたいのですがICustomerTypeRepository、コントローラーからDAL（リポジトリ）レイヤーを分離するのが一番いいと思いました。さて、私は物事を過度に複雑にしていますか？

これが私のコントローラーの現在の状態です。

Controller と Customer にリポジトリがあるので、これは私には間違っているようです。CustomerType 用に分離されたアクセス レイヤーが必要であることは、私には論理的に思えます。すなわちCustomerType.GetList()：

では、オブジェクトを からに公開する方法はどれですか?CustomerTypeICustomerTypeRepositoryCustomerController

標準の \trunk \tags \branch レイアウトを使用せずにセットアップされた Subversion リポジトリがあり、数年後、これを修正しようとしています。tortoiseSVN を使用しています。

現在のシステムでは、UI、ビジネス ロジックなどのさまざまなサブディレクトリを含む「dev」フォルダーがあります。

理想的には、trunk、branchs、tags を含む dev フォルダーを用意し、trunk フォルダー内にサブディレクトリを配置する必要があります。

私の計画では、新しいトランク、ブランチ、およびタグ フォルダーを dev フォルダーの下のサブディレクトリと同じレベルに作成し、新しいフォルダーを追加してコミットし、サブディレクトリをトランク フォルダーに svnmove することでした。

最新の作業コピーでこれを行うことができます。しかし、私たち全員が多数のローカル変更を行っており、更新すると必然的に何百ものツリー競合が発生するのではないかと心配しています。誰でもこれを行うより良い方法を見ることができますか?

私が見ることができる唯一のオプションは、ローカルで変更されたすべてのファイルを現在の作業コピーからリポジトリの新しいチェックアウトに個別にコピーしてから、古い作業コピーを削除することですが、これは理想的ではありません. 私たちは多くのローカルな変更を行っており、全員がかなり最新の作業コピーを持っているということはありそうにありません。

よろしくお願いします。

デイブ

svn の標準リポジトリ レイアウトは次のとおりです。

私が使用しているリポジトリは、よりフラットな構造です。

基本的に、トランクは他のブランチと同じレベルにあります。このため、-s または -b オプションを使用できませんgit svn init。

trunkgit ブランチとしてmasterプルインしfeatureX、同じ名前の git ブランチとしてプルするにはどうすればよいですか? 他のブランチやタグは気にしません。

私は同様の質問を見たことがあり、svn リポジトリの再構築を提案している人がいます。この質問に関する限り、これは検討の余地がありません。

DrupalのWebサイトに取り組んでいます。私は、別の開発者と連携するために最近githubに移植したカスタムモジュールのsvnリポジトリを保持しています。

SVNから来た私は、ステージングWebサイトのカスタムモジュールフォルダーをSVNリポジトリから直接更新できることに慣れています。しかし、私が読んだことから（私が間違っている場合は訂正してください）、このワークフローはGitでは不可能です。

drupalWebプロジェクトのリポジトリを設定するための推奨される方法は何ですか。サイト全体をリビジョン管理下にある1つのプロジェクトに入れる必要があります（drupalコアと提供されたモジュール、および任意のカスタムコード）。Ormは、カスタムコードのみをリビジョン管理下に置き続けることができますか？

ノート：

カスタムコードを再ビジョン化しただけなので、現在のリポジトリのディレクトリ構造はWebサイトと同じ構造ではありません。

@Charles Baileyによる「how-to-do-a-git-export-like-svn-export」への回答の提案で、私には可能性がありました。

本当の質問は次のようになります。

リポジトリの履歴をそのままにして、リポジトリのディレクトリ構造を変更することはできますか？

私はgit-archiveの概要を十分に詳しく調べていませんでした：

<tree-ish> [path]明らかに、リポジトリの任意の部分を「アーカイブ」できることを意味します。リポジトリ全体しかアーカイブできないと誤って思っていたので、混乱しました。したがって、この方法は、私がSVNで実行できたことを置き換えます。:)

（2）サーバー間でGitリポジトリを自動的に同期して、3番目のポイントから交換できるようにする方法を探しています。

状況は次のとおりです。すべてのプロジェクトで git を頻繁に使用しており、一部のリポジトリのサイズが非常に急速に大きくなっています。現在、中央サーバーが 1 つあり、全員がこのサーバーにプッシュ/プルしています。ただし、これはすべてインターネット接続を経由するため、最速の方法ではありません。

アイデア: オフィスに別のサーバーを配置し、すべての git リポジトリをオフィス内で使用できるようにします。このサーバーは、オンラインのサーバーと同期する必要があります。せいぜいユーザーは、何らかの dns 調整を介してどちらを使用しているのかさえわからないため、オンライン サーバー リポジトリのアドレスは、ネットワークに接続されたときにオフィス内のものに解決されます。

すでに似たようなことをしている人はいますか？または、目標を達成するためのより簡単な方法はありますか。

nHibernate上に構築されたリポジトリレイヤーを呼び出すASP.NETMVCWebアプリがあるとします。コントローラはISecurityToken、現在のユーザーのIDと権限をカプセル化するリポジトリを渡します。リポジトリは、クエリを実行するときに、ユーザーが表示できるはずの行のみを返すためにそれを使用します。

エンティティ（チケット）を、チケットが割り当てられているユーザーだけでなく、特定のユーザーグループのみが閉じることができるようにしたい。言い換えると、架空のCanCloseTicket()方法には2つの入力が必要です。

1. チケット自体（またはその現在の所有者ID）
2. 現在のユーザーのISecurityToken

この仮説的な方法はどこにあるべきですか？私はいくつかの可能性を見ることができますが、それぞれに欠点があります。

• コントローラ内：コントローラは必要なすべてにアクセスできますが、これによりセキュリティをバイパスできるようになります。（「おっと、falseに設定する前にこのアクションでCanCloseTicket（）を呼び出すのを忘れましticket.IsOpenた！」これは悪臭がします。
• リポジトリ内：リポジトリも両方の部分にアクセスできますが、Ticket.IsClosed上記と同じことが起こらないようにするには、セッターをプライベートにする必要もあります。リポジトリはモデルとはまったく異なるアセンブリに存在するため、内部セッターを使用しても機能しません。代わりに、セッターを公開したままにして、プロパティの現在の値を元の値と比較し、特権のないユーザーがそれを閉じるとエラーを返すことができますが、これも少し臭いがします。repo.CloseTicket()（「おっと、このアクションメソッドでの戻り値を確認するのを忘れました！」）
• チケットの内容：Ticket.Close(ISecurityToken token)エンティティに独自のセキュリティロジックを追加して責任を持たせることは、SRPの違反のように感じます。

ここではリポジトリが最良のオプションだと思いますが、最悪のオプションのように感じます。他に何かありますか？

古いC/C++コードベースをMercurialに移行中です。私が見つけた例は.NETまたはJava用であるため、リポジトリ構造が最適に（または少なくともほぼ最適に）どのように見えるかについては少しわかりません。私の問題は主に、以前からずっと使用しているVC++ディレクトリの処理に関するものです。

これが私たちが何も考えずにそれを行うことを私が見ることができる方法ですが、リンク（古い.libへのリンク）中にいくつかのバージョン管理/依存関係の問題が発生することを予測できます。\source、この例\includeでは、チェックアウトしたとき\static-libsの古いグローバルVC++ディレクトリになります。

代替案＃2へ。これはもっと良いでしょうか？サブリポジトリに移動して、サブリポジトリだけでプル/更新/マージを実行できますか？私がしたいのは、ライブラリの新しいバージョンだけで特定のプロジェクトの新しい本番ビルドを実行することだけです。この代替手段は、実際にはグローバル\libディレクトリを削除し、代わりにプロジェクトごとに作成します。これにより、うまくいけば、もう少し柔軟になります。一方、コンパイルされたライブラリをチェックインするのはかなり間違っていると感じるでしょう。

他のアイデアはありますか？どうしますか？過去4年間、主に.NETを使用してきましたが、これらのグローバル\source/\includeフォルダーはもう好きではありませんが、完全に取り除く方法がわかりません。ソースを少し切り詰めたり、コードをlibsに移動したりして、これらの.h / .cppファイルのプロジェクト間の依存関係を最小限に抑えることは間違いなく可能ですが、単純なコードの再利用が必要です。

追加の質問：私は同じリポジトリを見ることができ\include、\source同じリポジトリにいることさえできました。それらはほとんどロックステップにあることを意図しているので、それはあなたがそれをどのように行うのですか？

次のユース ケースを REST 形式で照会する独自の方法を探しています。

リポジトリに次のものが含まれていると仮定します:-

当社のストレージ リポジトリは、Google Storage、Amazon S3、Mongodb GridFS、Java コンテンツ リポジトリ (JCR 2.0)、または単純なファイル システムに基づくことができます。

上記のデータを保存および取得する理想的な方法は何でしょうか。上記のユース ケース [1-6] のいずれかをモデル化できるように、REST URL をできるだけ表現力豊かにしたいと考えています。上記のクエリに基づいてドキュメントを取得するために適切な命名規則を使用できるように、汎用リポジトリを設計する方法についての指針を感謝します。

一元化されたSCMシステムからGITに切り替えています。OK、どちらかを認めます。それはVisualSourceSafeです。したがって、Gitコマンドとワークフローの学習曲線を乗り越えることに加えて、私が現在直面している最大の問題は、単一または複数のリポジトリのいくつかのフレーバーに関して、現在のリポジトリをGitに移行する方法です。

私はこの質問がさまざまな方法で尋ねられるのを見てきましたが、通常は基本的なものです...「私はいくつかの低レベルのライブラリを共有したいアプリケーションを持っています」そして定型の応答は常に「別々のリポジトリを使用する」および/または「使用するこのパターンをいつ/なぜ使用する必要があるのか​​（何を克服するのか、何を排除するのか）についての説明があまりない「Gitサブモジュール」特にGitを初めて使用する人にとっては。

ただし、誰かが露骨に尋ねるのはまだ見たことがありません。「各レイヤーが独自のプロジェクトである従来のn層開発（UI、ビジネス、データ、共有ツール）がある場合、1つまたは複数のレイヤーを使用する必要があります。リポジトリ？」ほとんどの場合、新しい「機能」が追加されると、コードの変更が各レイヤーに波及するため、私にはわかりません。

Gitに関する問題を複雑にするために、これらのレイヤーを「フレームワーク」全体に複製して、開発者の観点からより管理しやすいプロジェクト/コンポーネントを作成しました。この議論の目的のために、これらのプロジェクト/レイヤーのコレクションを「タヒチ」と呼びましょう。これは「製品」全体を表します。

私たちのセットアップの最後の「レイヤー」は、タヒチをカスタマイズ/拡張するクライアントWebサイト/プロジェクトの追加です。これをフォルダ構造で表すと、次のようになります。

複数のプロジェクトで従来のn層設計をどのように拡張したかを説明した後、同様の状況でどのような決定を下したかについての経験を探しています（単純なUI、ビジネス、データ分離でさえ、あなただけでした）使用）そしてあなたの決定のために何がより簡単/より困難でしたか。サブモジュールがどのように少し苦痛になる可能性があるかについての予備的な読書で私は正しいですか？利益の価値よりも多くの痛みがありますか？

私の直感的な反応は、タヒチの1つのリポジトリ（「クライアントプロジェクト」を除くすべてのプロジェクト）、次に各クライアントの1つのリポジトリに対するものです。私が推測しているタヒチのソース全体は、1万未満のファイルでなければなりません。これが私の推論です（そして私は批判を歓迎します）

• Gitでは、「機能」と個々の「プロジェクト/ファイル」の履歴を追跡したいと考えています。プロジェクトを分離しても、「機能」は常に複数のプロジェクトにまたがっています。
• コアサイトでコーディングされた「機能」は、ほとんどの場合、コアWebサイトと「フレームワーク」のすべてのプロジェクト（つまり、CoreWebsite、Framework1.Business、Framework1.Data）に最小限の影響を与えます。
• 機能は複数のフレームワークに簡単にまたがることができます（実装する機能の10％はフレームワークにまたがると思います-CoreWebsite、Framework1.Business、Framework1.Data、Framework2.Business、Framework2.Data）
• 同様に、機能では1つ以上のSharedLibプロジェクトや「UIWebサイトヘルパー」プロジェクトへの変更が必要になる場合があります。
• クライアントのカスタムコードへの変更は、ほとんどの場合、リポジトリに対してローカルであるだけであり、「機能変更セット全体」が何であるかを確認するために他のコンポーネントへの変更を追跡する必要はありません。
• 機能がプロジェクトにまたがってスコープ全体を表示することを考えると、各プロジェクトが独自のリポジトリである場合、リポジトリ全体の*すべての*コード変更を分析しようとするのは面倒だと思われますか？

前もって感謝します。