問題タブ [externals]

ここで、すべての svn:externals 参照は他のプロジェクトのタグの 1 つから取得する必要があるというルールを確立しようとしています。トランクやブランチからではありません。これは合理的なルールですか、それともこのアプローチに問題がありますか? 私は安定した開発環境を実現しようとしていますが、このルールによって開発が遅くなったり難しくなったりするのではないかと考えています。

私は自分の会社の svn externals を調べていますが、私たちが使用するのに適した機能のようです。多くの場合、共有コンポーネントを参照する製品がいくつかありますが、古いバージョンに遅れをとったり、コードベースが異なって分岐したりするという悪い習慣があります。

それらが現在どのように機能するかについてかなり読んだことがありますが、その概念は理解できたと思います。100% 確信が持てないのは、複数のリポジトリの異なるリビジョンがどのようにリンクされているかです。

Product と Library があるとします。製品はライブラリに対してビルドされるため、そのレポにはライブラリ ソースにリンクする svn:externals プロパティがあります。svn:externals 定義に特定のバージョンがない場合、製品の HEAD をチェックアウトすると、ライブラリの HEAD も取得します。

私は何年にもわたって製品のいくつかのバージョンを構築し、そのたびにライブラリの最新バージョンを参照しています。ある日、正しいリビジョンを手動で選択して、製品バージョン 1 に戻ってチェックアウトする必要があります。そうするとき、ライブラリのどのバージョンを取得しますか? HEAD ですか、それとも最初にビルドしたときに使用したリビジョンですか?

うまくいけば、私は優れた開発者であり、リリースする製品のすべてのバージョンにタグを付けることを忘れていませんでした. タグ 'Product-1-0-0' をリポジトリに適用すると、ライブラリ リポジトリの正しいリビジョンもタグ付けされますか? タグ「Product-1-0-0」に基づいて製品を後でチェックアウトすると、正しいリビジョンのライブラリがチェックアウトされますか?

私は svn:external を使用して、Nlog や Lucene.net などのプロジェクトを取得しています。vs2008 csproj ファイルがありません。簡単に作成できるので、他のプロジェクトに追加できます。この 2008 プロジェクト ファイルを内部ソース管理に追加することは可能ですか?

svn：externalsの使用を非難するいくつかの回答をここで読みました。それらがどのように悪用される可能性があるかはわかります。それにより、Subversionへの依存度が高まりますが、私たちのグループがすぐにSubversionから離れることはありません。

とにかく、これが私のジレンマです。リポジトリの独自のセクションにある複数のプロジェクトを参照するソリューションがあります。これらのプロジェクトの多くは複数のソリューション間で共有されており、プロジェクトの共有を妨げることも望んでいません。また、いくつかの固定バージョンの依存関係がリポジトリにチェックインされています（単体テストフレームワーク、ライブラリなど）。

開発者向けのソリューションを構成するために、外部のみを使用するいくつかの「ワークスペース」を構成したいと思います（Subversionに関する限り、それらは空のディレクトリであるか、単一のソリューションファイルを含む可能性があります）。ほとんどのプロジェクトを自分でチェックアウトするだけではビルドできませんが、すべての依存関係が付属しているため、ワークスペースをチェックアウトするだけでビルドできます。他の誰かが同様のソリューションを実装しましたか？svn：externalsはこれを実行するための良い方法でしょうか？私たちがこの道を進む場合、あなたは私にどのような注意を払っていますか？

基本的に、構造は次のようになります（簡潔にするためにトランク/ブランチ/タグは省略されています）。

以前に削除されたファイルを上書きするときに、Subversionの「レイジーコピー」はまだレイジーですか？

外観はバージョンごとに別々のフォルダーに保存します。つまり、dojoの場合は次のようになります。

そうすることで、少なくとも私にとっては、新しいバージョンへの切り替えが簡単になると思います。

それぞれの新しいバージョンを追加するだけでは、怠惰なコピーを行うために必要な履歴をsvnに実際に与えることはありません。だから私が使った戦術の1つは

• svnは、古いバージョンを新しいバージョンが存在する場所にコピーします
• 次に、svnはそのフォルダ全体を削除します
• 次に、新しいバージョンをその場所に解凍します
• 次にsvnはそれらを追加します

アイデアは、私のリポジトリに大量の重複データがないようにすることです。

svnが新しいファイルを見て、次のように言っていることを願っています。

「ねえ、私はすでにこれを一度持っていて、コピーしてから削除しました...だから私は怠惰になり、変更のみを保存します」。

それは私の理論でした-しかし、それは実際に起こりますか？

psはい私は別の方法が「フォルダの外部プロパティ」を設定することであることを知っています-しかしそれは別の質問です。

svn:externalリポジトリに作成しました。コマンドの出力を除いて、すべて正常に動作しますsvn status。出力には、必要のない多くの情報があります。

実行svn st --ignore-externals -qして、この行を小さなスクリプトに配置することはできますが、もっと良い解決策があるかもしれません。外部に関する情報を表示せずに作業コピーのステータスを確認するにはどうすればよいですか?

.netで非常に単純なはずのものは、非常に難しいようです。

MyExtendersというプロジェクトがあり、基本的なタイプへのいくつかの単純なエクステンダーが含まれています。

多くのプロジェクトはMyExtendersを使用しているため、従来のsvnチェックアウトおよびビルドアプローチでは、MyExtendersをsvn：externalとして追加し、リビジョンは最後にビルドおよびテストされた方にロックされています。

同じソリューションにMyExtenderを追加する必要がある2つのプロジェクトがある場合、すべてがヒープに分類されます。両方のMyExtenderをソリューションに追加することはできません。したがって、1つだけを使用する必要があります。これは、リビジョンが異なる場合は、古いプロジェクトをそれを使用して再テストすることを意味します。

おそらく、依存関係を最もよく説明する図は次のとおりです。

Delphi / Cは、上記で問題なく動作します。すべての参照は、独自のプロジェクトフォルダからのものです。

VSは、ディレクトリ構造を失い、上記を次のように平坦化することを主張しています。

そして、私はプロジェクトの1つを変更して、別のMyExtenderを参照するように強制され、そのときは別のリビジョンを参照しました。

明らかに私はそれをすべて間違っています..しかし、あなたはそれをどのように正しくしますか？

Subversion から Mercurial に一連のプロジェクトを移行しています。プロジェクトは現在、svn:externals を使用して、あるコードから別のコードにプルします。外部を特定のリビジョン番号に向け、必要に応じて手動で更新するという推奨事項に従っています (メイン プロジェクトの過去のリビジョンに更新すると、外部の過去のバージョンも取得できるようになります)。

Mercurial で外部を行う方法はサブリポジトリを使用しているようですが、それらを特定のリビジョンにペグする方法がわかりません。メイン リポジトリを更新するたびに、Hg は常にサブリポジトリを最新のリビジョンに更新するようです。あれは正しいですか？それを回避する方法はありますか？

FreeImage .NET ラッパーに依存する ASP.NET プロジェクトがあります。これは、外部ディレクトリへの参照を使用してロードされます。ラッパーは、動作するために存在する FreeImage.dll に依存しています (明らかに)。

Visual Studio に FreeImage dll への参照を含めるにはどうすればよいですか。これは .NET アセンブリではありません。別のものに組み込まれていると思います (そのため、参照として追加することはできません)。

これらのファイルは別の SVN リポジトリにあるため、このプロジェクトのコピーは必要ありません。