問題タブ [branching-and-merging]

TFS2010にアップグレードしました。プロジェクトごとに開発ブランチを作成しました。Branch1で変更が行われた後、Branch1がベースラインにマージされると、変更されたファイルだけでなく、すべてのファイルがマージされます。

その後のBranch1のファイルへの変更とその後のベースラインへのマージでは、Branch1の最初のマージと2番目のマージの間にBranch2からの変更がマージされない限り、それらの変更のみがマージされます（これは私たちが望むものです）。したくない）。

変更されたファイルのみが毎回マージされるようにするにはどうすればよいですか？

私は現在、いくつかの論理レイヤーと複数のフロントエンドで構成される.NETのプロジェクトに取り組んでいます。SVN構造の大まかな表現は次のとおりです。

私たちの日々の開発はすべてトランクで行われます-これはすべての開発者がチェックアウト/コミットする場所です。

環境（テストと本番）間でクリーンかつ簡単にデプロイする方法を探しています。

私の考えは、トランクからテストと本番の2つのブランチを作成することです。ソリューションとすべてです。私は次の理由でこれを自分自身に正当化しています：

1. トランクからテストブランチ、およびテストブランチから本番ブランチにマージするだけで、どの変更がどの環境に流れるかを完全に制御できます。
2. Subversionの対応するブランチのログを見るだけで、各環境で実行されているコードを簡単に確認できます。

誰かがこれに似たソリューションを使った経験がありますか？私が見逃している潜在的な落とし穴や見落としはありますか？

Visual SourceSafe 2005 の使用:

以前の時点で、ソースにラベルを付けて、ソフトウェアの新しいバージョンのリリースを示しました。

私がやりたいことは、ソフトウェアで行ってきた他の作業を含めずにマイナー アップグレードをリリースするために、ラベルが作成されたブランチを作成することです。

これにはブランチを使用する必要がありますか? VSS 2005 でこれを行うにはどうすればよいですか?

Perforceブランチで発生したすべてのファイルの名前変更と移動の履歴を表示するコード(できればWin32で実行される)を持っている人はいますか?

Fossil SCM の分岐に関するドキュメントには、閉じたタグがある場合、葉は閉じていると見なされると書かれています。しかし、私が入るとき

閉じたものは何も表示されません。でタグを追加しても同じことが起こり--propagateます。Fossil自体の閉じた葉を確認すると、リストされている葉にはclosedタグが表示されていません。私は何を誤解していますか？

'features'というSVNプロジェクトのブランチを作成しました。このプロジェクトを更新しようとすると、ブランチからのプロジェクトの別のコピーを含むfeaturesフォルダーが表示されます。

これがもう起こらないように、リポジトリからブランチを完全に削除する方法はありますか？

非常に長い間、すべての開発と展開をトランクから行ってきました。しばらくすると、新機能「B」を実稼働環境に移行するよう要求があったため、実稼働環境がトランクと同期しなくなりましたが、新機能「A」は延期されました。基本的には、トランクからチェックアウトします。一時フォルダーにファイルを選択的にマージし、一時フォルダーから実稼働フォルダーにファイルを選択的にマージします (バージョン管理下にありませんでした)。

あまりにも長い間これに取り組んだ後、最終的にリポジトリを再配置して分岐できるようにすることにしましたが、(svn mv) トランクを移動中にいくつかの間違いを犯したため、ブランチとタグフォルダー (以前はそこにありました) 用のスペースを確保できましたは「トランク」フォルダーではなく、ファイルはプロジェクトの親フォルダーにあるだけでした)、最終的な結果として、「トランク」は、そこから作成したいくつかのブランチよりも新しくなりました。そして今、ブランチからトランクへのマージを行うことができないようです。多くの変更が失われ、多くの競合が発生しています。（すでにトランクからブランチを更新しています。）

トランクで実行svn log --stop-on-copyした場合、最も古いリビジョンは r14376 であり、ブランチで実行した場合、最も古いリビジョンは r14368 です。(HEAD は r14710 にあります)

r14368 と r14376 の間のすべての変更を失わずに適切なマージを行うにはどうすればよいですか? 手動でトランクにマージしようとしましたが、ブランチ ファイルのリビジョン履歴がすべて失われました。

Our University provides web hosting to campus departments on servers we manage. Installing open-source third-party programs requires modifying file permissions and code in the program before it will run. (We're using suEXEC, if you're familiar.)

We currently offer WordPress via an installer script. The user uploads the newest stable release, and runs a server-side PHP script via SSH. This PHP script modifies file permissions of all files/folders, adds/removes some code in various files, and creates a few new files. This installer script is a cumbersome balancing act when a new stable version is released.

I want to start using version control (specifically git) to track our custom changes instead of relying on a script to make the changes, but am unsure of the workflow to use. I'm familiar with branching and merging, but not sure how to integrate our old changes when a new release is issued.

What should my git workflow be to integrate the new changes from the WordPress core, but also preserve our older custom changes?

これは私のワークフローでよく発生します。別のブランチで機能に取り組んでいます。これを実行しているときに、修正が必要な小さなものに出くわしますが、たとえば、フレームワークやサイトレイアウトの上位からのものです。

メインの開発ブランチに戻り、そこで選択したファイルから変更をコミットしてから、機能ブランチに戻ってリベースし、無関係な微調整やバグ修正を邪魔にならないように続けたいと思います。

私はこれを使用git stashしgit stash popていますが、変更したファイルの束から多くの競合が発生していますが、とにかく親ブランチにコミットする必要はありません。

競合を回避する、または現在の状態を何らかの方法で保存し、選択した作業ツリーの変更のみを別のブランチにプルしてコミットする別の方法はありますか？（git-stash-cherry-pickのようなもの;-)）

私はSVNのマージ/再統合について頭を悩ませようとしており、これらの記事/本を読んでいます:

http://svnbook.red-bean.com/en/1.5/index.html
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

同期されたリビジョンをトランクへのマージ (リフレクティブ/サイクリック マージ) に含めることが問題である理由がわからないため、明らかに完全には理解していません。リビジョンを除外しない理由はわかります。

トランクのファイル A の行がブランチのファイル A' にマージされてからトランクにマージされた場合、A と A' の間に違いはないので、競合はありませんか? 「トランクに既に存在する[merging] back changes 」 が問題になるのはなぜですか?

私は競合シナリオを複製して、再統合が私のために何をしているかを理解しようとしていますが、さらに混乱しているのは次のシナリオです。

1. トランク (r4) で変更をコミットする
2. r4 をブランチにマージしてコミットする (r5)
3. ブランチで変更をコミットする (r6)
4. 次のいずれかの方法でブランチをトランクにマージします。
   • リビジョン範囲 r5 ～ r6 をトランクにマージ - 競合が発生する、または
   • r5 をトランクにマージしてから、r6 をトランクにマージ - 競合は発生しません

SmartSVN 6.6 と SVN 1.6 を使用しています。各リビジョンを個別にマージする場合と比較して、リビジョン範囲をマージする場合に結果が異なるのはなぜですか? そして最終的に、反射マージを含めることが問題になるのはなぜですか?