リリースサイクルのソースの分岐は、一般的なソース管理シナリオの1つです。できるだけ早くマージすることをお勧めします。したがって、人間の要因があります。ブランチは閉じていますが、誰かが何かをトランクにマージするのを忘れていました。
Q:ブランチXからトランクにマージされなかったすべてのリビジョン番号を取得する「ワンクリック」方法はありますか?
(注:何をマージするかを見つけるのにこれらのリビジョン番号は必要ありません。自動検証を作成する必要があります。これにより、トランクに何かをマージするのを忘れていないことを人々に思い出させます。マージ自体は問題ではありません。)
Svn mergeinfoコマンドはここでは役に立たないようです。マージがルートレベルではなく実行された場合、ブランチとトランクのルートを渡すと失敗します(これは一般的なシナリオです)。
スクリプト、ツール、あらゆる種類のsvnフックをソリューションとして歓迎します。
追伸.
SVNの最新バージョン。このシナリオがどれほど一般的で良いかを論じる必要はありません;)
短い答え:そうは思いません。
長い答え:私はpythonスクリプトを書きました。開発者が変更セットをマージするときはいつでも、彼らはログメッセージに "merged rXXX"を入れる必要があります。これはsvnの前から: mergeinfo exists)スクリプトはすべてのライブsvnブランチ+トランクを解析し、すべての「マージされた」リンクを再帰的にスキャンして、マージしていない変更の開発者ごとのリストを出力します。
[更新] @tmontからの回答は、論理的な修正のみを記録したい場合に、すべての人がsvn mergeinfo --show-revs eligible
とsvn merge --record-only
をサポートするsvnバージョンを持っているので、より優れています。
mergeinfo
サブコマンドで比較的新しいバージョンのSubversion(1.5以降)を使用している場合は、これを非常に簡単に行うことができます。
svn mergeinfo --show-revs eligible svn://repo/branches/your-branch-name svn://repo/trunk
これにより、ブランチ「your-branch-name」からトランクにマージできるすべてのリビジョンが表示されます。
ソース: http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.mergeinfo.html
あなたのケースはおそらくこれには遅すぎると思いますが、私がこの種のことに対して行うのは、マージコミットの規約を確立して、後でそれらを識別できるようにすることです。たとえば、「[1234]のマージ:...(1234の完全なコミットログ)...」のようになります。次に、後でスクリプトを使用してsvnログから解析できます。
チーム全体で確実にそれを行うには、マージ規則をスクリプトにして、プロジェクトに入れます。 (例:./scripts/merge 1234)。人々は一般的にこれを二重にさえ感謝するでしょう、それでスクリプトがソースのURLを自動的に理解するようなことをすることによって生のsvnコマンドがそうするよりも簡単にマージを行うなら
幸運を。
マージする必要のある特定の変更番号について心配する必要はありませんが、差分を確認するだけです。
まず、トランクでサイドブランチを最新の状態にします(または何がマージされるかを確認します)。
cd branch-dir
svn merge --reintegrate http://svnrepo/path-to-trunk .
svn ci -m'making this branch current'
cd ../trunk-dir
svn merge --dry-run http://svnrepo/path-to-trunk http://svnrepo/path-to-branch .
svn ci -m'merging in all unmerged changes from <branch>'
Svn mergeコマンドはsvn diffコマンドと同じように見えることを覚えておいてください。diff/ patchを作成し、それを特定の場所に適用します。上記のマージコマンドは、単に「トランクとブランチのすべての違いを取り、それらをトランクの作業コピーに適用する」と言っています。したがって、2番目のマージコマンドをメール通知のdiffに変更するのと同じくらい簡単です。
いずれの場合も、コミットする前に差分を確認し、問題が発生していないことを確認してください。いくつかの競合を解決する必要がある場合もあります。
現在、これをテストするためのSVNサーバーを自宅に持っていなくて申し訳ありませんが、次のコマンドを実行できます。
svn log --verbose
どちらを解析できますか?メインにマージした後の出力はわかりませんが、(スクリプトを使用して、自分のSVNサーバーを使用しているのは私だけなので、スクリプトを使用して)ログを解析し、すべてを読み取ることができる場合がありますチェックインされたファイルを検索し、ファイルがメインにマージされたことを示すキーワードを探しますか?
時間があれば、今夜帰宅したらいつかチェックしてみます。
スレッドが作成されて3年になりますが、私はあなたのスレッドを楽しんでいます。そして私はあなたがそれを置く形であなたの仕事のための解決策がまだないと信じています:)
私が$ svn help merge
で見つけたのは、サブツリーのマージを行わないようにというアドバイスです:
サブツリーのみをマージする場合は、サブツリーパスをSOURCEとTARGET_WCPATHの両方に含める必要があります。これは非推奨であり、サブツリーmergeinfoを回避します
したがって、解決策は、サブツリーのマージを行うという「一般的なシナリオ」を打破することだと思います。
マージ操作の制御を確立することは必須です。そうしないと、あるブランチへの読み取りアクセス権と別のブランチへの書き込みアクセス権を持つ誰もが最初から2番目のマージを実行できるためです。だから実際の質問は-サブツリーのマージを制御する方法です))
私はJavaブランチ間でマージされていないリビジョンを見つけるためにWicketとSVNKitを使用するWebアプリケーションを書いています、それはあなたが望むことを何でもするようにカスタマイズできます... link
o
Ether の返信 above に基づいて、マージされていないリビジョンをチェックするブランチから
svn merge --dry-run http://svnrepo/path-to-merge-source . \
| grep Merging \
| sed 's/--- Merging//' \
| sed 's/into.*//' \
| sort -u \
| sed 's/ through r/:/' \
| sed -e :a -e N -e 's/\n//' -e ta \
| sed 's/ r/ -r/g' \
| sed 's|^|svn log http://svnrepo/path-to-merge-source |'
ウィルsvn merge --dry-run
必要な詳細を教えてください。
そのため、CVSはブランチのルートをマークするタグを作成しました:) SVNの場合は次のようになります。
+ trunk / project1
+ tags / project1-b1-root
+ branches / project1-b1
ノート:
特効薬がないため、統制された方法は、何がどこからマージされたかをメモしておくことです。