5

私は分岐とマージに svn を使用することにかなり慣れていますが、通常はこれで問題なく動作します。ただし、1 つのコンポーネントが 2 つのブランチで作業され、基本的にコンポーネントが異なる方向に進んだため、自動マージは機能せず、beyond compare を使用するとファイルがほとんど異なるものとして表示されます。

いくつかのファイルをつなぎ合わせようとしましたが、うまくいったとしても結果はかなりひどいものです。

私はビジネスに対して、これは絶対にできないと言いたくなる。モジュール + 機能 A が機能し、モジュール + 機能 B が機能しているのに、モジュール + 機能 A + 機能 B がそのままでは意味をなさないので、これが彼らを苛立たせているのがわかります。たとえば、機能 A は、機能 B の重要なコンポーネントだったものを削除する場合があります。

そのようなコードをマージしようとする方法はありますか? それとも、モジュール + A + B は本当にモジュール + C ですか?

私たちはこれが実現することを確認しましたが、機能 A は、長期にわたるプロジェクトの一部であった機能 B よりも短い時間スケールで必要でした。このようなことが起こらないようにする方法はありますか? それとも、両方の機能がうまく適合するようにコードを構成する方法はありますか?

4

2 に答える 2

4

あなたが話しているのは、本質的にブランチの 1 つをリベースしようとしていることです。一部の DVCSではこれがサポートされていますが、SVN でこの種のサポートが行われていることは知りません。

あなたの最善の策は、分岐の 1 つ (現在最も重要なもの) を選択し、それをかなり単純なメイン ラインにマージすることです。他のブランチでは、トランクから変更をプルし、違いを調整する必要があります。説明した状況を考えると、これはほぼ確実に自動ではなく、このブランチ機能を一番上に実装する方法について真剣に考える必要があるかもしれませんメインラインにマージされたものの1つですが、それは並行開発のコストです.物事は変わります.

将来これをどのように回避しますか？頻繁な統合。

それぞれコードベース A を与えられた 2 つのチームがあり、6 か月間異なる機能に取り組んでいる場合、それぞれのチームが A について他のチームが変更したことを想定しているため、統合は非常に困難になります。一方、毎週または毎月の統合ビルドでは、各チームは他のチームがどの変更を行っているかを大幅に認識し、最終的な統合がはるかに簡単になるはずです。

これが、オープンソース プロジェクトがしばしば巨大なパッチに反対する理由であり、それらは驚くほど早く時代遅れになり、適切にレビューする時間は誰にもありません。一方、同じ貢献を独立した小さな消化可能な部分に分割した場合、あなたの貢献は A) 受け入れられ、B) 適切にレビューされる可能性がはるかに高くなります。欠陥の無限の流れ。

于 2009-02-26T12:07:16.030 に答える
0

src1.c などの 1 つのファイルを使用します。この方法でマージを説明するダイアモンド ダイアグラムを作成できます。

   Original src1.c
        /       \
       /         \
      /           \
   b1 src1.c     b2 src1.c
      \            /
       \          /
        \        /
         \      /
        merged src1.c

ここで、b1 は最初のブランチ バージョンを意味し、b2 は 2 番目のブランチ バージョンを意味します。並列差分を比較できます (たとえば、マージされたソースと b2 バージョン、および b1 とオリジナルの間のもの)。これが役立つ場合があります。

于 2009-02-26T12:33:58.090 に答える