1

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

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

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

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

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

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

/branches/5###_active_feature:27629-27780
/branches/7###_auto_friend_feature:43686-43693
/branches/7###_mobile_navigation:45430-45690
/branches/8###_tracking:44442-44719
/branches/9###_video_module:45388-45418
/branches/9###_episode_guide:45233-45287
...
/branches/11###_redesign:28289-28395,46973-48171

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

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

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

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

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

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

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

4

1 に答える 1

2
  1. 多くのブランチソース/trunkは問題ありません - 時間内に多くのブランチをマージしただけです
  2. 私の知る限り、merge-tracking と mergeinfo の概念は 1.6 以降でのみ導入されました。以前のマージは実際には「Merge Hell」でした。
  3. いずれにせよ、おそらくリポジトリを検証する必要があると思います-「アーカイブコードベース」と「アクティブコードベース」に分割します。
  4. SVN 1.8 への更新 (両側で、ただし少なくともクライアントでは) が適切な選択です。(必要な手順で) マージがはるかに簡単になります。
于 2014-08-27T19:24:27.363 に答える