問題タブ [mergeinfo]

プロダクション リリース ブランチ (ブランチ PR ) には 1 からタグ 20 までのタグがあります。ここで、タグ 20 は最終製品タグです。

ブランチ A : 現在の Production タグから作成されます。たとえば、タグ番号 1 です。ブランチ B: ブランチ A から作成 + 独自の変更 タグ 2 からタグ 20 はブランチ B にマージされます。

つまり、ブランチ B ----> タグ 1 + タグ 2 からタグ 20 (マージから) + 独自の変更。

ブランチ C : プロダクション タグ 1 から作成され、タグ 2 からタグ 8 がマージされます

つまり、ブランチ C ----> タグ 1 + タグ 2 からタグ 8 (マージから) + 独自の変更。

これで、ブランチ B からブランチ C に直接マージできますか :

ここで、ブランチ C には B の変更も含まれます (つまり、タグ 1 からタグ 8 へ)

マージを実行しましたが、タグ 9 からタグ 20 への変更は必要ありませんでした (他のブランチの変更は、いくつかの競合で簡単にマージされました)。たとえば、タグ 20 で削除されたコード スニペットは、マージ後もそこにありました。このコード スニペットはタグ 8 で導入されましたが、タグ 20 で削除されました。誰か助けてください:

1.マージ情報プロパティはここでどのようにその役割を果たしますか? および2.他のブランチでそのファイルを再度マージするときに、svnがファイルの過去のsvnmerge infoプロパティを使用する方法。

これは svnmerging にとって非常に重要な学習です。PS : 再統合を提案しないでください > 統合のベスト プラクティスを既に読み、環境に応じてそれらのほとんどに従っています よろしくお願いします

2 つのブランチ間の mergeinfo に次のリビジョンがあります。

そして、このリストからリビジョンの 1 つを削除して、マージを再試行できるようにしたいと考えています。どうすればこれを行うことができますか？

私は最近、SVN 1.5.5 がリポジトリとして使用されている環境で、レガシー コードベースの作業を開始しました。ここの開発チームは、SVN 分岐の仕組みに十分な困難を抱えていたため、放棄されました。必要に応じて分岐の慣行を維持したいのですが、これまで SVN を使用して経験したことのないいくつかの問題に遭遇しました。

トランクをブランチにマージすると、変更されていない何十ものファイルが変更済みとしてリストされ、それらが激しく競合する傾向があります。SVN は、競合をファイルの一部としてそれ自体と混ざり合って表示します。これらのファイルを実際に編集した人は誰もいないので、正しいバージョンを選択して先に進むのは簡単ですが、それでも開発者はプロセスについて不安な気持ちになります。次に、ブランチをトランクにマージすると、誰も編集していない同じファイルのセットが競合します。これは、一方または両方のブランチまたはトランクでファイルが合法的に編集されたときに、svn マージ アルゴリズムが作成することで悪名高い他の厄介な競合に追加されます。

通常、このガイドで行われているように、ブランチとマージを元に戻します。ただし、開発チームにはリポジトリと直接対話する 12 ～ 15 人がおり、全員が「ベスト プラクティス」に 100% 従うとは限りません。過去 8 年以上にわたって、このプロジェクトには他にも多くの開発者が参加しています。

また、誰も編集していないファイルの svn mergeinfo で多くの競合が発生しています。これが発生するたびに、完全に異なるファイルのセットになりますが、分岐が関係するときはいつでも発生することが保証されています. ブランチが作成されてから時間が経過するほど、謎の競合が発生します。

これらの多くの競合するが編集されていないファイルは、「--dry-run」オプションで予測できる場合があります。「--dry-run」を使用しても予期しない競合が表示されないことがありますが、同じマージ コマンドを実行すると、変更のない約 45 個のファイルが競合することになります。

トランクのルートで「svn propget svn:mergeinfo」を実行すると、次のようなブランチ名とそれらがカバーするリビジョン番号の大きなリストが表示されます。

そのような54行、合計。それは propget mergeinfo の予想される出力ですか - 単なるブランチのリストですか?

私は、何かが壊れていると信じているところにいます。これは、一見デフォルトの方法での分岐/マージの予想される結果ではありません。私は SVN を 2007 年から 2008 年にかけて 1 年以上使用しましたが、このような問題は一度もありませんでした。ただし、どこから解決策を探し始めればよいかわかりません。何人かの同僚と私は、次のことを検討しました。

• 私たちの svn バージョン (1.5.5) にはバグがあります。アップグレードする必要があります。官僚主義と戦う必要があるかもしれませんが、それほど苦痛ではありません。

• リポジトリの履歴のある時点で、svn mergeinfo が破損しているか、何らかの方法で手動で編集されていました。これを確認する方法はありますか？もしそうなら、それを解決する方法はありますか？

• リポジトリの歴史のある時点で、何らかの形で「破損」しました。ここで進む方法がわからない。

他の誰かが同様の問題を経験しましたか? これを修正して、変更されていないファイルが競合としてリストされないようにするにはどうすればよいでしょうか。私のチームは、コードベースでランダムなものを破壊することを心配することなく、ブランチを再び使用し続けることができますか?

(記録として、git に切り替えるための長期的なプロジェクトがあります。残念ながら、当面は SVN で立ち往生しています。)

最初のプロジェクトで SonarQube を動作させようとしていますが、C++ コードの分析中に次のエラー メッセージが表示されます。

この関連する回答を見つけましたが、サーバーで v1.7 ではなく v1.6.11 を実行しています。

Subversion 1.6 は mergeinfo をサポートしていますが、おそらく SonarQube は v1.6 に対して間違った構文を使用してクエリを行っているのでしょうか?

svn サーバー v1.6.11 を使用して、mergeinfo を SonarQube v5.2 および SVN プラグイン v1.2 で動作させるにはどうすればよいですか?

以下のコマンドを実行しています

svn mergeinfo --show-revs 対象 --log svn:///svn/branches/16.1.3.x svn:///svn/trunk -R -v

しかし、出力では、16.1.3.x からの単一のリビジョンではなく、16.1.1.x や 16.1.2.x などの他のブランチからリビジョンを取得しています。一方、亀のsvnのマージ画面からログを表示すると、ブランチ16.1.3.xのリビジョンのみが取得されます。

mergeinfo コマンドから同じ動作が必要です。助けてください。