3

そのため、アプリケーション Pluto とアプリケーション Goofy があり、どちらも同じ SVN プロジェクトを使用しています。実際には、構成の違いはほとんどありません。

今、私はこの問題に直面しています: Pluto の顧客はいくつかの新しい変更を望んでいます - 詳細には、彼は Javascript に機能を追加し、JSF 環境で使用するいくつかの xhtml タグを望んでいます。基本的に、これは彼が求めている JavaScript に関する改善です。古い機能がまだ存在している必要があります。ただし、新しい機能は Goofy の一部を破壊する可能性があります。Goofy ははるかに大きなアプリケーションであり、テストが難しいためです。実際、グーフィーは冥王星のスーパーセットです。たとえば、グーフィーは冥王星ができることは何でもできますが、実際にはテスト用であり、最終製品は冥王星に存在します。

変更が必要なファイルはかなり静的です。ファイルの 1 つを最後に変更したのは半年以上前だと思います。確かに、過去 2 年間で変更があったのは 2、3 回程度です。

私が考えたのは、javascript と xhtml タグへのすべての変更を実装する Pluto のブランチを作成することです。開発者はトランクで開発し、デプロイする前に常にブランチからの変更をマージします (これはおそらく自動的に行われる可能性があります)。ただし、ローカル開発には問題があります。これはトランクであり、新しい機能はブランチにのみあるため、Pluto 用にローカルで開発する場合、新しい機能は利用できません。

別のアプローチは、たとえば if application==Goofy load javascript Goofy を使用することです。

または最後に - すべての変更をマージしてバグを修正するなど、試行錯誤します:-)

皆さんはこれをどのように決定しますか？

4

1 に答える 1

3

私は異なるブランチを使用し、特別なトリックを使用してマージする不便さを受け入れif application==Goofyます。プログラムの複雑さが増し、おそらくより多くのアプリケーションが追加されると、後者の実装は確実にあなたを苦しめます.

より効果的な別のアプローチは、コードをリファクタリングし、アプリケーションのコア部分を独自のプロジェクトに分割することです。次に、各アプリケーションがコア プロジェクトを個別に参照できるようにします。たとえば、コア パーツにビジネス ロジックを含め、グーフィー/プルートがコア パーツの一部で GUI や特別な実装を処理することができます。SVN ツリーは次のようになります。

trunk
  |--- Core stuff
  |--- Project Pluto
  |--- Project Goofy

より複雑ですが、非常に柔軟なアプローチは、コアのものを独自のリポジトリに移動することです。svn:externalsその後、コア パーツをプロジェクトに含めるために使用できます。これにより、Pluto と Goofy を Core Stuff の特定のリビジョンにロックできるという利点が得られます。したがって、コアのものを更新して、あるプロジェクトには必要であるが、他のプロジェクトには有害または望ましくない機能を追加できます。私はこれが動作しているのを見てきましたが、うまくいきました。レガシー プロジェクトの開発が停止してから何年にもわたってコア部分がアップグレードされていたにもかかわらず、非常に時代遅れでありながらコンパイルして動作するレガシー コードがありました。

Core trunk
  |--- Core stuff (rev 123)

Application trunk
  |--- Project Pluto (Core rev 111)
  |--- Project Goofy (Core head)

最後のオプションを試してみたい場合は、ブログ投稿svn:externalsが役立つはずです。

于 2012-08-22T18:41:40.487 に答える