ソリューションでフォルダーとプロジェクトの名前が変更された場合、マージはどの程度効果的ですか?
4 に答える
ファイルの削除/名前変更に関しては、TFS 2005 で多くの成功を収めてきましたが、いくつかの非常に特殊な例外があります。
- ソース ブランチとターゲット ブランチの両方で名前が変更されたファイル (これは通常、[サーバーの変更を無視する] をクリックすることで簡単に解決されます)。
- ターゲット ブランチで名前が変更されたが、ソース ブランチで削除されたファイル。何を試してもマージが機能せず、ソース ブランチの変更を「元に戻し」、マージ後にやり直すことを余儀なくされた 1 つのケースを思い出します。
TFS 2008 はこれらの問題の多くを解決すると思われますが、正直なところ、時折発生するマージの問題を除けば、TFS は安定しており、階層的なマージは SVN よりもはるかにシンプルで高速です。
私の経験では、SourceControlExplorer (TFS) 内ですべての名前変更を行う限り、TFS は名前変更を追跡できます。
この問題は、他の人が元のファイルに変更を加えているときに、他の人が大規模な名前変更/移動を行っているときに、他の人が名前が変更されたバージョンを編集しているときに発生する傾向があります。
可能であれば、大規模な名前の変更と移動を行う場合は、チームメイトに知らせる価値があり、可能であれば、あなたがチェックインするまで変更を保留してもらう.
すべてのブランチ/マージの問題と同様に、チェックインとマージを少しずつ頻繁に行うことで、問題は大幅に軽減されます。
私は TFS 2008 で大量のファイルとフォルダーを移動した経験があります。これは、ソース コード構造の一貫性を高めるために行われました。私がしなければならなかったのは、チーム エクスプローラーでドラッグ アンド ドロップ (および待機) し、変更をコミットすることだけでした。
TFS 2005 と一般的な削除に関しては、多くの問題がありました。原因はまだ特定できていませんが、多くのチーム メンバーが、フォルダーの名前変更または削除に関連する変更をマージする際に問題に遭遇しました。これは、名前が変更されたブランチで多くのリファクタリング (および名前の変更と再名前の変更) が行われた場合に特に当てはまります。うまくいかなかった状況に個人的に関与したことがないため、理由や再現手順はわかりません。
私は次のような他の一般的な削除の問題を見てきました: 1 ブランチ A で、サブディレクトリ 1 のアクセス許可を読み取り専用に減らします 2. ブランチ B を作成します (A から B に分岐) (チェックイン) 3. ブランチ B を削除します (チェックイン) ) 4. A から新しいブランチを作成し、ブランチ B と同じ名前を付けます。
これを回避する唯一の方法は、ステップ 2a を挿入することです。Branch B の名前を _Branch B に変更します (チェックイン)。
全体として、TFS は私たちにとって素晴らしいものでしたが、削除、名前の変更、およびマージに関して不安定なことが起こっています。まもなく 2008 にアップグレードしたいと考えており、それによって私たちの問題が解決されることを願っています。