0

これらのプロジェクトはすべて相互に依存しているため、これらのプロジェクトをどのように編成すればよいかわかりません。

現在、すべてが次の構造になっており、管理が難しくなっています

-trunk
 |-bin - compiled common dlls
 |-lib - static libs for use with common dlls
 |-src - common dll source code
 |-include - headers for common dlls
 |-common.sln - VS 2008 solutions for common dlls
 |-samples
 ||-res - resources for samples
 |||-img
 |||-snd
 ||-c++ - c++ samples for common dlls, tends to double up as tests
 |||-various VS 2008 sample solutions
 ||-py - python versions for some samples
 |||-...
 |-wrappers
  |-python
  ||-bin - compiled python extension dll
  ||-src - source for python wrapper
  -Apps - actaul programs using common dlls, each with its own dir and solution
  |-...

これには多くの問題があります: -1 svn 構造が少し混乱しています。たとえば、1 つのアプリケーションだけの bracnh を作成する実際の方法がありません。アプリによって。たとえば、python プログラムは、python 拡張 dll がどこにあるのか、および各共通 dll がどこにあるのかを知る必要があります。これらのパスは、svn では、リリースの場合とは非常に異なります (すべて共通のディレクトリにある可能性が高い)。

4

2 に答える 2

3

うーん！

すべてを個別のプロジェクト/dll/ライブラリ/アーティファクトに分割します-それらを呼び出したいものは何でも、推奨されるSVN構造に従います。

/ (root)
  /Application1
    /branch
    /tag
    /trunk
  /Application2
    /branch
    /tag
    /trunk
  /LibraryX
    /branch
    /tag
    /trunk
  /LibraryY
    /branch
    /tag
    /trunk

次に、アプリケーションがそれらのライブラリまたは依存関係のいずれかがその構造内のディレクトリにあると予想する場合、svn:external プロパティを使用してそれを取り込みます。

たとえば、LibraryX からコンパイルされた dll を Application1 内の dll というフォルダーに配置する場合は、次の svn:external プロパティを /Application1/ のリポジトリに追加する必要があります。

svn://repositoryname/LibraryX/buildoutput/ dll

Application1 をチェックアウトすると、すべてのファイルが取得され、作業コピー内に dll というフォルダーが追加され、LibraryX/buildoutput/ からチェックアウトされます。

各プロジェクトを独自のフォルダーにチェックアウトして、特定のファイルを選択することもできます。ただし、これには少し異なるアプローチが必要です。次のように、ローカル マシンに同じ親フォルダーを持つすべてのフォルダーをチェックアウトします。

Application1 (checked out from svn://repositoryname/Application1/trunk)
LibraryX (checked out from svn://repositoryname/LibraryX/tag/stable)

したがって、LibraryX のビルド出力から特定のファイルが必要な場合は、次のように追加します。

svn:externals ../LibraryX/build/thelibfile.dll libfile.dll

..Application1 のチェックアウト済み作業コピーのプロパティとして、LibraryX から libfile.dll を取得し、Application1 作業ディレクトリのルートに貼り付けます。

これの主な利点は、タグを使用することで、アプリケーションがその依存関係の特別にタグ付けされたバージョンを取得できることです。上記の例では、開発者は Application1 のトランクで作業できますが、安定したバージョンのライブラリを使用しています。ライブラリの次の安定版リリースが再タグ付けによって作成されたら、更新するだけで、開発作業コピー内のすべての開発者のマシンに取り込まれます。

外部ファイルは、ローカルの作業コピーからチェックアウトして参照している場合にのみ、単一のファイルに対してのみ機能します。フォルダーでできるように、リポジトリから直接実行することはできません..まだ.

Subversion バージョン 1.6.x では、単一ファイルの外部ファイルのみを取り込むことができます

于 2009-05-13T21:22:08.260 に答える
1

一般に、Subversion リポジトリ内に複数のプロジェクトがあり、それが乱雑になっている場合、次の 2 つのいずれかを実行する必要が
あります。 . これは、同じチームがすべてのコードに取り組んでおり、プロジェクトが実際には異なる方法でコンパイルされた単なるコンポーネントである場合に行われる傾向があります。

2) 異なるプロジェクトを別々に分割し、それらを独自のリポジトリに配置します (または、少なくともそのプロジェクト ディレクトリの下にある独自のトランク/ブランチ/タグ セクションで上部に分割します)。完全に個別にビルドし、リポジトリに公開します。この場合、共有ファイル システムまたは Web サーバーです。

あなたの特定のケースでは、ライブラリコードの共通セットとこのコードの一部のユーザーの 2 つのプロジェクトがあるように見えます。したがって、次のような最上位構造になります。

  1. アプリ
  2. 一般
  3. サンプル（かも？！）
  4. ラッパー

それぞれに、そのプロジェクト ディレクトリの下に独自のトランク、タグ、ブランチ構造があります。それらのそれぞれには、依存プロジェクトの出力を表す (またはリポジトリ内のバージョンを参照する) コンパイル済みバイナリのコピーも含まれているため、依存関係を進めるための正式な方法が得られます。

于 2009-05-13T21:20:51.677 に答える