4

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

4

4 に答える 4

4

あなたの懸念は、「svn:externals」を含むプロジェクトがそのプロジェクトへのコミットなしで変更される可能性があることです。重大な変更を発見したり、適切なバージョンにロールバックしたりするのは難しいため、これは問題です。

そうです、svn:external 参照が安定していることを要求することは良いルールです。タグへの参照のみを許可することは、それを実現する 1 つの方法です。もう 1 つの方法は、-r 構文を使用して外部を固定リビジョンに固定することです。Subversion book の例:

サードパーティ/スキン -r148 http://svn.example.com/skinproj

これにより、タグの変更からも保護されます。これは、私が好むよりも一般的な悪い習慣です。

そうは言っても、安定性と継続的インテグレーションの間にはまだトレードオフがあります。とにかく、外部依存関係の変更とバグ修正が必要になることがよくあります。その場合、問題をできるだけ早く修正できるように、依存関係の変更によってプロジェクトが壊れたことを CI サーバーからできるだけ早く通知する必要があります。ほとんどの継続的インテグレーション サーバーは、外部のチェックをサポートしています。

このため、(CI サーバーがある場合) 依存関係のトランク HEAD を追跡するトランク内の外部を維持しても問題ないと思います。タグ付けや安定したメンテナンス ブランチの作成時に、外部を固定リビジョンに固定するだけです。

于 2009-08-07T20:42:14.040 に答える
2

ソフトウェア開発の実践がどれだけ成熟しているかにかかっていると思います。変更管理プロセスはありますか？自動ビルドとレポート？など。最も安全な方法は、プロジェクトのタグ付きビルド（つまり、lib、dll、jarなど）にリンクすることです。

外部プロジェクトにバグ修正が頻繁に行われる毎週のリリースがある場合、それは役立つと同時に障害になる可能性があります。適切な構成管理ポリシーがないと、タグにリンクすると重要な更新を見逃しやすくなることがわかりました。そして、その依存関係を「アップグレード」するまでに、多くの小さな変更が行われ、多くの作業が必要になる可能性があります。

比較的安定したプロジェクトでは、これは良い考えです。唯一の問題は、すべてのIDEがソースディレクトリが外部参照であることを明確にしているわけではないということです。その場合、開発者はそのタグへの変更をチェックインするのが非常に簡単になります。私が覚えていることから、私は古いバージョンを使用してきましたが、Subversionはまだ「読み取り専用」を実装していません。

于 2009-08-07T13:55:23.270 に答える
2

そして、実際に外部を許可するという決定は？あなたが正しい理由でそれをしていることを確認してください。多くの場合、元の場所からチェックアウトするか、複数の場所で依存関係をチェックインする方がよいでしょう。私は過去に外部の参照によって焼かれました。分岐する場合は、外部を「フリーズ」しない限り、それらは実際の問題になります。

しかし、あなたの質問に答えるために、すべての外部が配置され、参照される特定の場所を持つことは非常に理にかなっています。つまり、その場所のコンテンツを制御でき、人々は、そこに何かを置くと、それが外部として使用され、多くのプロジェクトに依存することを知っています。

于 2009-08-07T13:56:16.700 に答える
2

トランクがどれほど安定していると考えるかによって異なります。

  1. トランクが常にリリースの準備ができているものである場合、外部がトランクを指すことは本当に望ましくありません。
  2. トランクからリビジョンをマージすることによってのみ変更されるリリース ブランチがある場合、外部がトランクを指すことは本当に望ましくありません。
  3. なんらかの理由で、「現在、このエクスターナルのこのバージョンを使用しています」というトランクのリビジョンが必要な場合、プロジェクト コードへのすべての変更を制御する場合、エクスターナルがトランクを指すことは望ましくありません。

ただし、開発者が外部の作業コピーをトランクに切り替えることは問題ありません。開発ブランチ内のトランクを指すことも問題ありません。プロジェクトの最初の安定版リリースの前にトランクを指定しても問題ない場合があります。

私の個人的な考えでは、trunk は私にとって特別な意味を持っているため、非常に慎重に扱うことです。これはプロジェクトの完全な歴史です。定義上、解放されるものはすべてトランクを通過する必要があります。変更に対してリビジョンを記録せずにトランクを変更できる場合 (これは、トランクの外部を指す場合に実際に起こることです)、そのリビジョンをいつリリースするか、いつそのリビジョンをプロジェクトに組み込むかを制御できなくなります。 .

トランクから分岐するときに特定のリビジョンへのすべての参照を変更することを忘れないでください。Hudson は、タグ付けをサポートすることで物事をより見やすくすることができますが、他にはほとんど役に立ちません。

トランクを指すことも、「手に負えないライブラリ」の問題につながる可能性があります。

CI に関して言えば、最終的に統合されたプロジェクトだけでなく、すべてのコンポーネントで CI を実行できない理由はありません。最新のライブラリにいつマージするかを選択することで、統合作業をいつ行うかを選択できます。

ただし、「あなたのプロジェクトは古いライブラリを使用しています。最新バージョンは X です」というメカニズムがあると便利です。これは現時点では不可能です。

また、外部をネストしている場合、ベース ライブラリからの変更を 5 層の参照を介してメイン プロジェクトにプッシュするのは面倒です。

于 2009-08-10T11:58:49.140 に答える