2011-05-11 23 views
2

私は維持している古典的なASP webappのためにSCMとしてSubversionを使用しています。依存関係や長期的な発展を伴う変更を処理するには、フィーチャー分岐を使用します。ブランチと共有のdevサーバー?

私はDev/QA用の共有Webサーバーを使用していますが、これが私の質問です。中央のDevサーバーはトランクの作業コピーです。そして、機能ブランチからDevの変更を見る必要があるとき、それらをDevの作業コピーに追加します。これまでのところ良いことだけど、私は道に不満のために自分自身を設定していますか?

たとえば、アナリストは、フィーチャーに加えた変更を「削除」し、デモサイトのDevサイトにマージすると言っていました。フィーチャーが殺されたわけではなく、もうそれを見る必要はありません。そして私はそれが簡単にできないことに気付きました。私がマージした変更は、Dev作業コピーのローカル修正として表示され、簡単には削除できません(影響を受けるファイルの変更を手動で元に戻す必要があります。その他の機能)。

私がそれについて書くほど、私は自分の質問に答えたように感じます。ブランチ戦略(環境ごとのブランチ)を変更する必要がありますか?または、各ブランチ(dev.mysite.com:4801、dev.mysite.com:4802)ごとに別々の「共有Dev」サイトを用意する必要がありますか?それとも、あなたがこれをどう扱うか?

答えて

1

削除したい機能が特定のリビジョンに完全に含まれている場合は、トランクに関連するブランチ上で、その特定のリビジョンの逆マージをトランクブランチの作業コピー上で行うことができます。 "svn merge"コマンドのオプションを見てください。このページによると、あなたはこのようなコマンドを発行することができるはずです。

のsvnマージ-c -revision YourDevBranch YourWorkingCopy

これはあなたのトランクの作業コピーから、もともとのブランチにコミット1つのリビジョンを削除する必要があります。

ただし、オリジナルの開発ブランチであっても、1つのリビジョンでコミットされているいくつかの機能に関連する問題がある場合、唯一の選択は手動で修正を削除することだと思います。

+0

OKです。変更を元に戻すことができます。私は前にそのタイプのマージを使ったことがありません。私はこれがこのアプローチをある程度検証すると思いますか? –

+0

はい、それは実際に私のポイントでした:) – yms

関連する問題