2012-04-04 18 views
3

2人の開発者がそれぞれトランクからフィーチャブランチを作成した場合、それらのフィーチャブランチとトランクの間で「同期マージ」を行っても、問題なくトランクに各フィーチャブランチをトランクに再統合できますか?SVNのフィーチャーブランチをマージすることは安全ですか?

"同期マージ"とは、 "svn merge ^/Project1/trunk"と "svn merge ^/Project1/branches/other-feature-branch"という形式のコマンドを意味します。それぞれの場所から既にマージされたものの

私が尋ねる理由は、ブランチと同じリビジョンで再作成すると矛盾の問題が発生することを示唆する数多くの場所でドキュメントを読んだことです。場合である)。これがそうである場合、上記のシナリオは、各機能ブランチがトランクだけでなく他の機能ブランチとも同期するため、問題になるはずです。したがって、トランクで行われた変更は、トランクと直接同期することによって、もう1つの機能ブランチ(すでに同じトランクが変更されている可能性があります)。

私はこれを行ったことがありましたが、完全にうまくいくように見えますが、私は私たちのチームのワークフローとしてこれを推奨する前に専門家の安心感を捧げたいと思います。

@nosid:SOのばかげた文字制限が4文のコメントを防止するため、この編集でnosidに返信します。このTwitterは何ですか?

私はドキュメントを読んでいます。問題は、一度に不安定化機能が1つしか動作せず、他のすべての作業がトランクで行われている間に不安定化作業が機能ブランチで実行される非常に単純なシナリオを説明することです。このシナリオでは、機能ブランチをトランクと同期させておくことは自明です。

しかし、より現実的なシナリオでは、製品は一度にいくつかの主要な不安定な作業を簡単に行うことができます。これらの作業を同期させて、必要に応じてトランクやお互いに同期できるようにするプロセスは何ですか。

+0

同時に任意の数のフィーチャブランチを持つことができます。それは問題ありません。オーバーラップが小さい限り、各ブランチの変更も巨大になる可能性があります。オーバーラップが大きい場合は動作しませんが、クロス集約の代わりに回避しようとします。 – nosid

答えて

0

2つの機能ブランチを互いに同期させる場合、2つの機能ブランチを持つポイントは何ですか?

これらは本質的に同じです。

+1

違いは、他の開発者がチェックインしたときに強制するのではなく、必要なときに機能を引き出すことができる点です。 – gbanfill

+0

これは手動引き出しです(言い換えれば "継続的にマージ"ではありません)。 –

+0

希望するワークフローはgbanfill状態です。私は「継続的にマージする」とは言いませんでした。 – Neutrino

4

これは方法ではありませんが、Subversionでは機能ブランチを使用する必要があります。簡単な例でのテストでは、このアプローチは後で問題を引き起こすことを示しています。次の手順を試してください:

  • 新しいリポジトリを作成します。
  • 初期構造(トランク、ブランチ、タグ)を作成してコミットします。
  • svn cp -m 'new branch' ^/trunk ^/branches/aと対応するコマンド(^/branches/b)を持つ空のトランクの2つの新しいブランチを作成してコミットします。
  • ブランチbに新しいファイルを追加してコミットします。
  • ブランチbからブランチaへの変更をsvn merge ^/branches/bでマージします。私はトランクを変更していないので、マージするものはありません。
  • トランク上にブランチを再統合しコミットするasvn merge --reintegrate ^/branches/a
  • トランクからの変更をブランチbにマージしてsvn merge ^/trunkにマージします。
  • これで、以前に追加したファイルにツリーの競合が表示されます。

Subversionのドキュメントでは、機能ブランチの推奨使用方法について詳しく説明しています。次のリンク:Feature Branchesを参照してください。機能ブランチは、通常、トランクから作成されます。機能ブランチで独自の変更を行い、トランクからの変更を機能ブランチに継続的にマージします(svn merge ^/trunk)。作業を終えるとすぐに、ブランチをトランクに再統合します(svn merge --reintegrate ^/branches/name)。再統合後、フィーチャブランチは廃止されており、もう使用しないでください。

+0

はい、私はそれが実際にはバマーです参照してください。私のテストは単純すぎて、新しいファイルを追加するのではなく、既存のファイルの変更をテストしていたので、私はこの問題にぶつからなかった。 – Neutrino

+0

SVN 1.8以来、--reintegrateスイッチはもはや必要ではありません - あなたは通常のマージを行い、SVNはツリー衝突を起こさないために必要なすべての魔法を行います。ここを見てください:http://stackoverflow.com/questions/18444634/tortoisesvn-subversion-1-8-merge-no-more-reintegrate-a-branch-option –

0

ここに私のOPの質問があります。質問に対する答えを決定するための他の情報源によって提案されたテスト手順といくつかの相似点があるかもしれませんが、私は別の結論に達します。

はここに私のREPROスクリプトです:

#---------------------------------------------------------------------- 
# Test whether merging between feature branches in SVN results in 
# tree conflicts, as claimed elsewhere: 
# http://stackoverflow.com/questions/10015249 
#---------------------------------------------------------------------- 
export REPO=file:///tmp/merge-test/repo 

#---------------------------------------------------------------------- 
# Create a new repository. 
#---------------------------------------------------------------------- 
echo Creating a new repository ... 
cd /tmp 
rm -rf merge-test 
mkdir merge-test 
cd merge-test 
svnadmin create repo 

#---------------------------------------------------------------------- 
# Create and commit the initial structure (trunk, branches, tags). 
#---------------------------------------------------------------------- 
echo Creating initial structure ... 
svn mkdir $REPO/trunk -m "Initializing trunk" 
svn mkdir $REPO/branches -m "Initializing branches" 
svn mkdir $REPO/tags -m "Initializing tags" 

#---------------------------------------------------------------------- 
# Create and commit two new branches of the (empty) trunk. 
#---------------------------------------------------------------------- 
echo Creating two new branches of the empty trunk ... 
svn cp $REPO/trunk $REPO/branches/a -m "branch a" 
svn cp $REPO/trunk $REPO/branches/b -m "branch b" 
svn co $REPO/trunk 
svn co $REPO/branches/a 
svn co $REPO/branches/b 

#---------------------------------------------------------------------- 
# Add and commit a new file on branch b. 
#---------------------------------------------------------------------- 
echo Adding and committing a new file on branch b ... 
cd b 
echo testing > foo 
svn add foo 
svn ci -m "committing new file" 

#---------------------------------------------------------------------- 
# Merge the changes from branch b to branch a. 
#---------------------------------------------------------------------- 
echo Merging the changes from branch b to branch a ... 
cd ../a 
svn merge ^/branches/b 
svn commit -m "merged b into a" 

#---------------------------------------------------------------------- 
# Reintegrate and commit branch a on the trunk. 
#---------------------------------------------------------------------- 
echo Reintegrating and committing branch a back to the trunk ... 
cd ../trunk 
svn merge --reintegrate ^/branches/a 
svn ci -m "merged a back into trunk" 

#---------------------------------------------------------------------- 
# Merge the changes from the trunk to branch b. 
#---------------------------------------------------------------------- 
echo Merging the changes from the trunk to branch b ... 
cd ../b 
svn up 
svn merge ^/trunk 
svn ci -m "refreshing b from trunk" 

#---------------------------------------------------------------------- 
# Look for a tree conflict on the file added earlier. 
#---------------------------------------------------------------------- 
echo Looking for tree conflicts for the file added earlier ... 
svn status 

おそらく何の木の競合が存在しないことを意味し、最後の(SVNステータス)コマンドからの出力はありません。私が知る限り、ブランチ間のマージは問題を引き起こすことを示す明確なステートメントはありません。ブランチとトランクのマージを含むマージが発生する通常の競合を超えています。クロスブランチマージが一般的なマージよりも問題があるという証拠がある人は、その証拠を調べることに非常に興味があります。それまでは、私は、実際に危険なことは何もないことを営業担当者に助言する傾向があります。

+0

これは非常に奇妙です。私はあなたの例を行ごとに処理し、 "トランクからブランチbへの変更をマージする"ステップでツリーの競合を起こしました。svn出力は "svn merge ^^/trunkでした。 --- r5からr8を '。' : Cは Uをfoo.txtの ---にR8を介してR5のマージのためのmergeinfoを記録。 '':。競合の G 概要: ツリーの競合:1" SVNバージョン1.7.8 – Neutrino

+0

でだ、私が知っていますsvn 1.7は以前のいくつかのバージョンですが、1.9にアップグレードすると1.7のサーバーから大きなリポジトリをチェックアウトしようとすると、Windowsのクライアント例外が発生して失敗するので、サーバーをアップグレードするまでは1.7でうまくいきます。 – Neutrino

関連する問題