問題タブ [repository-design]

現在、多数の Excel VBA を使用したワークブックを VSTO ソリューションに変換するプロジェクトに取り組んでいます。すべてのワークブックは、多数のクラス ライブラリとサード パーティのアセンブリを共有します。実際、ほとんどの作業はクラス ライブラリで行われます。私は現在、このようにフォルダ構造をレイアウトしています。

各ワークブックは独自のソリューションになり、ワークブック ソリューションはフォルダー構造内のアセンブリを参照するだけです。私の質問は、ソース管理をどのようにレイアウトしますか? ベースでリポジトリを開始しますか? それとも、ワークブック ソリューションごとにリポジトリを作成しますか? フォルダを並べ替えますか？

初期開発が完了したので、残りのワークブックの変換を支援するために多くの外部開発者をプロジェクトに参加させようとしています。彼らがベースからチェックアウトできるというアイデアが本当に気に入っています。ディレクトリを作成し、すべての依存関係をすぐに使用できるようにします。また、1 つのソース管理リポジトリの下に 20 以上のソリューション/プロジェクトを配置することに伴う懸念事項が他にもあることも心配しています。

プロジェクトに参加する人々のためにすべてをできるだけシンプルにしたいのですが、長期的な使いやすさを犠牲にしたくありません。私の考えでは、1 つのリポジトリとソリューションごとに 1 つのリポジトリのどちらが簡単ですか?

私は新鮮なので、あなたが持っている洞察力に感謝します。

追加情報: 現在、私は個人的に Mercurial を使用していますが、他に何か説得力のある議論ができない限り、プロジェクトはおそらく StarTeam に移されるでしょう。

現在、最初のasp.net mvc アプリケーションに取り組んでいます。私が見ているすべてのサンプル プロジェクトのクールエイドを飲み込もうとしており、リポジトリ デザイン パターンを使用しようとしています。

次のような IUserRepository というインターフェイスがあります。

私の IUser インターフェイスには、CreatedBy、CreatedDate、ModifiedBy、および ModifiedDate の一連のプロパティとプロパティがあります。

私の UserRepository は次のようになります。

現在の Web アプリケーションでは、ユーザーがログインするときに顧客のビジネス プリンシパルを現在のスレッドに隠し、ビジネス オブジェクトが更新されると、現在のビジネス プリンシパルの Identity プロパティで Name プロパティを使用するだけでうまく機能します。

それで私の質問は何ですか？リポジトリの Add メソッドまたは Update メソッド内で同じことを行う必要がありますか、または実際に現在のユーザーへの IUser 参照を渡し、そこから UserId を取得する方がよいでしょうか?

ご意見をお待ちしております。

私は通常、関連するすべてのエンティティを同じリポジトリに保持しようとします。以下は、2 つの間に関係があるエンティティです (インデントでマークされています)。

• ユーザー
  • ユーザー設定

したがって、ユーザーリポジトリに移動するのは理にかなっています。ただし、ユーザーは多くの異なるエンティティにリンクされていることがよくあります。次の例ではどうしますか?

• ユーザー

  • ユーザーの好み
  • 注文

• 注文

  • 製品

注文は製品とユーザーの両方と関係がありますが、4 つのエンティティすべての機能を同じリポジトリに配置することはできません。ユーザー エンティティを処理し、注文情報を収集するときはどうしますか? 製品に関する追加情報が必要になる場合があり、多くの場合、ORM は遅延読み込み機能を提供します。ただし、製品エンティティがユーザー エンティティとは別のリポジトリにある場合、リポジトリ間で競合が発生することは確実でしょうか?

私の SVN リポジトリには、リリース サイクルが異なるプロジェクトがいくつかあります。リリースは、SVN の従来のタグ構造を使用して作成されます。リリースで修正すべきバグがある場合、タグからブランチが作成され、バグが修正され、そこからトランクにマージされます。

現在、複数の理由から、SVN から mercurial に切り替えて、中央のプッシュ サイトを使用したいと考えています。

質問: ほとんどコードを共有しない複数のプロジェクトを Mercurial で編成するのに最適な方法はどれですか? プロジェクトごとに 1 つずつ、複数のプッシュ サイトを作成する必要がありますか?

私のリリースタグ、バグ修正ブランチなどを再作成する方法についての説明を回答に含めてください...お好みのバージョンのリポジトリ設計を使用してください。

編集：できるだけ少ない拡張機能をインストールしたいと思います。

編集2:

この SVN レイアウトを考えると:

(ありがとう @bendin! :) )

複数の hg push リポジトリで作業する方が良いですか

枝のために。タグは適切なブランチに折りたたまれます。

または、この例では 2 つのプッシュ リポジトリを使用しますか?

名前付きブランチを使用するため、1 つのリポジトリ内に複数のヘッドがあります。

複数のヘッド リポジトリの利点は、複数のリポジトリでタグを探しに行く必要がないことです。私が見る不利な点は、hg book が複数のヘッドリポジトリを思いとどまらせるように見えることです。あなたは何をしますか？

そのため、リポジトリの構造に少し問題があります。これを進める方法について、いくつかの指針を教えていただければ幸いです。

設定;

いくつかのオープンソース ソリューションが統合された 1 つの大規模な Web プロジェクトがあります。私はそれをすべて Bazaar リポジトリに持っています。

問題;

このサイトの 2 つ以上の「構成」が必要です。つまり、データベースと css/templatesが異なる必要があります。これを適切に分岐するにはどうすればよいですか？「ベース Web プロジェクト」を 2 つ以上のリポジトリに入れたくありません。

別のリポジトリに別の構成データベースを配置しても問題ありませんが、ベース リポジトリから .css を移動するときに問題が発生します。

「.css」で簡単に検索すると、約 200 個のファイルが見つかります。これをクリーンアップすることはできますが、オープンソース ディレクトリを更新するたびに統合地獄が発生します。

考え;

私の現在の考えは、css ファイルのないbasesite-repo を 1 つ作成し、basesite-repo と 200 の .css ファイルすべてのデータベースを含む別の config-repo を作成することです。

これは、サイトをチェックアウトしてセットアップしたいときはいつでも正常に機能し、同じディレクトリに2つのチェックアウトがあります。うまくいくはずですよね？

しかし、ローカルでサイト (ベース + 構成を意味する) で作業する場合、どうすれば解決できますか? 同じディレクトリに 2 つのブランチがありますか? バグ修正をリリースするのは苦痛になると思います...サポートさえされていれば(?)

私のアイデアの構造がどのように見えるか;

この問題は、過去 10 年間で何度か解決されたに違いありません。しかし、それでも私はかなり迷っているので、どんな指導もいただければ幸いです。

私の会社では、C++ コードを保持するために 1 つの SVN リポジトリを使用しています。コードベースは、共通部分（インフラとアプリケーション）とクライアントプロジェクト（プラグインとして開発）から構成されています。

リポジトリのレイアウトは次のようになります。

• インフラストラクチャー
• アプリ1
• アプリ2
• アプリ3
• プロジェクト-クライアント-1
  • App1-プラグイン
  • App2-プラグイン
  • 構成
• プロジェクト-クライアント-2
  • App1-プラグイン
  • App2-プラグイン
  • 構成

クライアント プロジェクトの一般的なリリースには、プロジェクト データと、それによって使用されるすべてのプロジェクト (インフラストラクチャなど) が含まれます。

各ディレクトリの実際のレイアウトは -

• インフラストラクチャー
  • 枝
  • タグ
  • トランク
• プロジェクト-クライアント-2
  • 枝
  • タグ
  • トランク

そして、同じことが残りのプロジェクトにも当てはまります。

上記のレイアウトにはいくつかの問題があります。

1. 関連するすべてのプロジェクトをチェックアウトする必要があるため、クライアント プロジェクトの新しい開発環境を開始するのは困難です (例: Infrastructure、App1、App2、project-for-client-1)。
2. 上記と同じ理由で、クライアント プロジェクトでリリースにタグを付けるのは困難です。
3. クライアント プロジェクトで一般的なコード (インフラストラクチャなど) を変更する必要がある場合、ブランチを使用することがあります。プロジェクトでどのブランチが使用されているかを追跡するのは困難です。

SVN で上記のいずれかを解決する方法はありますか? クライアント プロジェクトで svn:externals を使用することを考えましたが、この投稿を読んだ後、それが正しい選択ではない可能性があることがわかりました。

OK、単一プロジェクトのリポジトリのトランク/タグ/ブランチのことを理解しました。

ここで、メイン プロジェクトと、いくつかの小さな補助モジュール/プラグイン/ツール/スクリプトなどがあるとします。初期段階では、多くの名前変更、再編成などがあり、それらのいくつかはどこにも行かないために早期に死亡します。 . 組織がかなり安定するまで、特定のモジュールをトランクに貼り付けても意味がありません。(その時点で、トランクへのコピーはsvn設計ごとに「安価」です)

開発プロセスの早い段階で小さなモジュール (「FooModule」など) を配置するのに最適な場所はどこでしょうか?

• /branches/development/FooModule ?
• /開発/FooModule ?
• /sandbox/modules/FooModule ?

同様の方法でSubversionリポジトリを整理した経験のある人はいますか? 何があなたのために働いたのですか？

私はSVNリポジトリをセットアップする準備をしていますが、リポジトリ構造の良い例が誰かあるかどうか疑問に思っていました。私は現在考えています：

開発
..アプリケーション
....App1
......トランク
......ブランチ
......タグ
..データベース
..サードパーティ

この構造はおそらく私たちが必要とするすべてのものを保持することができますが、私はそれをもう少し細かくしたいと思います。何かご意見は？

アプリケーションを、他の多くのものと共有しているsvnリポジトリから、独自の新しいリポジトリに移動しています。だから、レイアウトで新たなスタートを切るチャンスがあります。

アプリ自体には 2 つのコンポーネントがあります。データベースと通信するかなり標準的な Java Web アプリと、DB をポーリングし、検出内容に基づいて長時間実行される処理タスクを開始する Java のバックエンド コンポーネントです。基本的には DB です。キューとして使用されています。コードは 3 つのパッケージに分割されます。

1. org.blah.common- Web アプリとバックエンドの間で共有される DAO などのコード
2. org.blah.webapp- ウェブアプリ; これは に依存しorg.blah.common、.warファイルにビルドされます。
3. org.blah.backend- バックエンド プロセス。これは に依存しorg.blah.common、jar といくつかのスクリプトを含む tar ファイルにビルドされます。

また、Tomcat と Apache の構成の他のビットも svn に取りたいと思います。

現在、3 つのパッケージはすべてディレクトリの下の svn にsrcあり、さまざまな部分をビルドするさまざまなターゲットを持つ ant スクリプトがあります。svn:ignore プロパティが非常に大きくなり、あるディレクトリのスクリプトが下のパッケージのコードに関連しているのsrcに対し、別のディレクトリのスクリプトは tomcat の起動と停止用であることがすぐにはわかりません。

私はMaven の標準的なディレクトリ レイアウトに惹かれていますが、これまで使用したことがありません。私はこれを思いついた：

現時点では、maven に移行するつもりはないことに注意してください。既存の ant スクリプトは機能するため、それらを適応させます。ただし、将来のある時点でmaven（またはmavenレイアウトを使用するbuildrのようなもの）に移行するオプションを保持したいと思います。

そう：

• これは、リポジトリをレイアウトする合理的な方法のように思えますか? さらに先に私をつまずかせるものはありますか？
• これは、アプリを初めて使用する人には明らかでしょうか?
• これは Maven と互換性がありますか? (理論的には、どのレイアウトでも Maven を機能させることができることはわかっていますが、理由により標準を推奨していると思います。)
• IDE でこれに問題が発生することはありますか? (私が使用しているコンピューターに応じて、intellij または eclipse を使用します。私のチームの他の人々 (これについて意見を持っていないのは有益です) は、netbeans を使用します。)