問題タブ [svn-merge]

私のブランチがリファクタリングされたデータレイヤーがある新しいバージョンを表している場合がありますが、すべてのバグ修正はトランクに適用されています。
私が遭遇したすべてのドキュメントは、ブランチをトランクにマージすることのみを参照しているため、私は何か反対の方法をとっていますか?
バージョン ブランチとバグ修正の同期を維持したいのですが、どうすれば簡単に実行できますか?
特に、バージョン ブランチのディレクトリ階層とファイルに多くの変更が加えられているために競合が発生している場合。
この場合のベストプラクティスは正確には何ですか？

私は慣れていない svn セットアップで作業しており、あるブランチから別のブランチに新しいコードをマージする必要があります。

トランク フォルダーにはコードがないため、トランクをコードに更新して 2 番目のブランチを更新する必要があるかどうか、または 1 つのブランチを別のブランチに更新する方法があるかどうかはわかりません。私の最後の手段は、コードを手動で更新することです。

ここでの最善のルートは何か考えはありますか? 私は端末からすべてをやっています。

現在、ブランチからの変更をトランクにマージしようとしています。ブランチの変更により、トランク内の各プロジェクトの名前がブランド解除されます。簡単にするために、トランクのルートは次のようになります...

そして枝はそのように見えます...

ブランチを現在の状態にするために、次のコマンドがブランチで実行されました...

その後、ブランチとトランクの両方でコードの変更が行われました。マージを実行しているので、トランクの作業コピー内で、Tortoise SVN を使用してマージ タイプとして「ブランチの再統合」を選択し、実行の結果としてブランチへのパスを「From URL」として選択しました。これは現在、作業コピーに含まれています...

フォルダー company-name-* は削除対象としてマークされ、他のブランド名が削除されたフォルダーは追加対象としてマークされます。商標が削除されたプロジェクト フォルダ内のすべてのファイルに関連する履歴情報がなく、トランクで発生したさらに悪い変更が商標が削除されたフォルダに存在しないという問題があります。svnコマンドラインツールを使用してフォルダーの名前が変更されたことを考えると、SVNはトランクから変更を取り込み、マージ後に履歴を保持するのに十分なほどインテリジェントであると思いました。私が受け取っている結果は期待どおりですか、それともマージを実行する必要がある他の方法はありますか?

ログ、mergeinfo などを使用して、Subversion 1.6 で --reintegrate オプションを使用していつマージが行われたかを判断する方法はありますか? (これは、どのコミットがマージの結果であるかを知っていることを前提としています。)

ブランチB1がありますが、まだ安定していないため、トランクにはありません。ただし、B1からの変更を処理するため、B1からブランチB2を作成します。

したがって、svncopyは次のように実行されました

数日後、B1は安定し、B1はトランクに再統合されます。

ここで、問題はB2のバックをトランクにマージすることにあります。B2をB1に再統合してからトランクに再統合しますか、それともB1->トランクとB2->トランクを直接再統合しますか？

トランクから分岐した状況があり、ブランチで数日間の開発作業を行った後、他の誰かがトランクのプロジェクト ディレクトリの名前を変更しました。このようなもの: /Project/Directory/trunk/old_dir_name から /Project/Directory/trunk/new_dir_name へ

これは私に問題を引き起こしました（もちろん）。

彼がこれを行ったときのログ エントリを見ると、次のように表示されます。 Action Path Copy from path Revision Deleted /Project/Directory/trunk/old_dir_name added /Project/Directory/trunk/new_dir_name /Project/Directory/trunk/old_dir_name 12345

トランクをブランチにテストマージして最新の更新を取得しようとしたところ、1 つのファイルで競合エラーが発生しました。そのファイルだけの最新リビジョンのテスト マージを試みると、次のようになります。

必要に応じてブランチを最新の状態に保つために、これを修正するにはどうすればよいですか?

(問題がある場合は、TortoiseSVN フロントエンドを使用します)。

トランクにマージして戻す必要のある、実行時間の長い機能ブランチがあります。しかし、私は呪文を正しく理解するのにかなりの時間を費やしているので、少し助けを借りることができます。

私の機能ブランチからのログは次のようになります（これを簡単にするために単純化しています）：

したがって、私がやりたいと思うのは、100-120、130-150、170をマージすることです。これらの変更は両方の場所にすでに存在し、ツリーの競合が発生する可能性が高いため、130または160をマージしたいとは思いません。

（そして、なぜ私が「再統合」機能を使用しないのか疑問に思っている人のために、それは私のSubversionサーバーがまだ1.4であるため、その機能がないためです、AFAIK。）

svn:external リンクを含むディレクトリがある場合 (これは仕事で広く使用されています)、ブランチ間でそのディレクトリをマージするたびに、ディレクトリ内のすべてのファイルが新しい svn:merge-info プロパティを取得します。

外部リンクがマージによって変更されていないため、svn がそれを独自のサブツリーとしてカウントしているためだと推測しています (関連しますが、同じ問題ではありません:mergeinfo プロパティ)。

これにより、実際の変更がすべてのマージ情報プロパティの変更に埋もれてしまい、変更セットが大きくなり、ほとんど判読できなくなります。(1 行の変更をマージすると 500Kb の差分が発生する可能性がある、十分なマージ履歴と外部を備えたブランチがあります)。

これまでのところ、コミットする前に svn:external リンクを含むサブツリーからマージ プロパティを削除することしかできません。これにより、 --reintegrate の使用が妨げられ、実際のサブツリーのマージが発生した場合に追跡できなくなります。

誰にもより良い解決策がありますか？

pre-commit スクリプト内で、? に起因するコミットを特定することは可能svn mergeですか?

svnlook changed ...変更されたファイルを表示しますが、マージと手動編集を区別しません。

merge理想的には、標準とを区別したいと思いmerge --reintegrateます。

バックグラウンド：

プロジェクトに SVN の使用ポリシーを適用するために pre-commit フックを使用する可能性を探っています。

ポリシーの 1 つは、一部のディレクトリ ( など/trunk) を直接変更してはならず、機能ブランチの再統合によってのみ変更する必要があると述べています。したがって、pre-commit スクリプトは、ブランチの再統合を除いて、これらのディレクトリに加えられたすべての変更を拒否します。

何か案は？

アップデート：

コマンドを調査しましたが、最も近いのは、ディレクトリsvnlookのプロパティへの変更を検出して解析することです。svn:mergeinfoこのアプローチにはいくつかの欠点があります。

1. svnlookプロパティの変更にフラグを立てることはできますが、どのプロパティが変更されたかはわかりません。proplist(前のリビジョンとの差分が必要です)
2. の変更を調べることでsvn:mergeinfo、実行されたことを検出できsvn mergeます。ただし、コミットが純粋にマージの結果であるかどうかを判断する方法はありません。マージ後に手動で行った変更は検出されません。(関連記事:別のパス/リビジョンに対するトランザクション ツリーの差分)