いくつかの独立したサプライヤーによって開発された分散システムの実績のあるSVN構造は何ですか？分散開発のSVN - ベストプラクティス？
例えば、 3つの層（UI、サービス、データ）とそれらの間のサービス契約：各層は、特定の層に結びついていない異なる供給者によって開発されたいくつかの構成要素からなる。サプライヤAはUIおよびサービスレイヤのコンポーネントを開発し、サプライヤBはサービスおよびデータレイヤのコンポーネントを開発します。
各サプライヤは、必要なサービス契約への読み取りアクセスだけでなく、独自のコンポーネントへの書き込みアクセス権しか持たないようにしてください。
- >このような設定でSVNを構造化するにはどうすればよいですか？
サプライヤーによる？レイヤーで？どちらも？ ...？
これらのサプライヤが本当に独立している場合は、これらのコンポーネントをすべて1つのSVNリポジトリに保存するようアドバイスしません。私はむしろサプライヤに別々のSVNリポジトリを提供し、よく定義されたリリースプロセスを介して共通のアーティファクト（Mavenのような）リポジトリから/へのコントラクトと相互作用を制御したいと思います。たとえば、Nexusには、どのアーティファクトをどのユーザーが利用できるのかを制限し、読み取り/書き込みを制御できる機能があります。
サプライヤを別々にしておく必要があります。各サプライヤコンポーネントのトランクはそれに適しています。
最近の主要なソフトウェアプロジェクトでは、各サプライヤがそれぞれのリポジトリに読み取り権限を持つリポジトリを許可しました。その後、トリガーされたスクリプトを使用して読み取り専用の統合トランクを作成しました。これらは毎日真夜中に実行されました。
回帰およびシステムインテグレーションテストを行った構築環境によって統合トランクが引き出され、失敗と問題が毎日の開始のために開発チームに転記されました。
わかりやすくするために、レイヤーごとに構造を整理することをお勧めします。そのようにして、構造を見るとコンポーネント間の関係が明らかになります。クライアント（つまりサプライヤ）のオーバーヘッドが増えたり、リポジトリへの各クライアントのアクセスを設定するオーバーヘッドが増えたとしても、これは価値があります。これは、各クライアントがプロジェクトの全体的な構造を考えるのに慣れていくためです。長期的にはバグやAPIの競合の可能性があります。
これは、管理者が自分のやり方を持っている場合、サプライヤごとにリポジトリを分離する傾向がある場合です。プログラマーとして、あなたはより良く知っています。適切なワークフローの慣行が遵守されていることをマネージャーに見せるために、作業の一部を分かりやすくするためとプログラミングを改善するために入れてください。
また、異なるサプライヤが同じ構造内で互いの仕事を見ているだけで、その小さなやり方では、やり取りが促進されます（ただし、小さい）。これは、やはりセキュリティと制限よりも重く重んじるオープン性とコミュニケーションの努力です。あなたが最初にプログラマとしてsay-soを持っていれば、それはチャンスです。
ところで、GitはSVNよりも優れています。