問題タブ [merge]

両方のハッシュを組み合わせて %hash1 にする最善の方法は何ですか? %hash2 と %hash1 には常に一意のキーがあることを常に知っています。可能であれば、1 行のコードも希望します。

マージしたいdebianの下に2つのUNIXパーティションがあります（ディスクスペースの問題：/）。それを行う最も簡単な方法は何でしょうか？あるパーティションから別のパーティションにファイルをtarまたはコピーし、一方を削除して、もう一方のサイズを変更するのが最善だと思います。partedを使用してサイズを変更しますが、ファイルをコピーするにはどうすればよいですか？変更せずに移動する必要があるリンク、権限、およびデバイスがあります。

同じではない 2 つのプロパティ ファイルがあり、違いを見つける必要があります。2 番目のファイルはキーでソートされています。

それを助けることができるツールはありますか？私が見たところ、すべてのマージ ツールは順序を非常に気にかけています。

git-merge の man ページには、使用できるマージ戦略がいくつかあります。

• 解決- これは、3 ウェイ マージ アルゴリズムを使用して 2 つのヘッド (つまり、現在のブランチとプルした別のブランチ) のみを解決できます。交差するマージのあいまいさを慎重に検出しようとし、一般的に安全で高速であると考えられています。

• recursive - これは、3 方向マージ アルゴリズムを使用して 2 つのヘッドのみを解決できます。3 方向マージに使用できる共通の祖先が複数ある場合、共通の祖先のマージ ツリーを作成し、それを 3 方向マージの参照ツリーとして使用します。これにより、Linux 2.6 カーネルの開発履歴から得られた実際のマージ コミットで行われたテストによって、ミスマージを引き起こすことなく、マージの競合が少なくなることが報告されています。さらに、名前の変更を含むマージを検出して処理できます。これは、1 つのブランチをプルまたはマージするときのデフォルトのマージ戦略です。

• タコ- これは 2 頭以上のケースを解決しますが、手動での解決が必要な複雑なマージを拒否します。これは主に、トピックのブランチ ヘッドをまとめるために使用することを目的としています。これは、複数のブランチをプルまたはマージする場合のデフォルトのマージ戦略です。

• ours - これは任意の数のヘッドを解決しますが、マージの結果は常に現在のブランチ ヘッドになります。これは、サイドブランチの古い開発履歴に取って代わるために使用されることを意図しています。

• サブツリー- これは修正された再帰戦略です。ツリー A と B をマージするとき、B が A のサブツリーに対応する場合、同じレベルでツリーを読み取るのではなく、最初に B が A のツリー構造に一致するように調整されます。この調整は、共通の祖先ツリーに対しても行われます。

デフォルト以外のものをいつ指定する必要がありますか? それぞれどのようなシナリオに最適ですか?

プロジェクト/ソリューション ファイルのマージは、ソース管理でマージを実行する開発者/SCM 管理者の間でよく知られている災害です。

たとえば、一般的なシナリオを考えてみましょう。開発は、2 つの異なるブランチのプロジェクト/ソリューションで行われます。メインの開発ラインにマージするときが来ると、VCPROJ (および SLN) の間には非常に小さな類似点があります。

その理由は、Visual Studio がこれらのファイル内のさまざまな XML に似た要素の場所を変更する可能性がある (実際に変更する可能性がある) ためです。たとえば、構成のデバッグとリリースは、proj ファイルの保存操作ごとに順序が入れ替わる場合があります。これにより、自動マージを考慮しなくても、各開発ブランチからの変更を簡単に組み込むことができなくなります。

Microsoft は vcproj 構造を保持するために何らかの perl ハッシュ システムを使用していると推測できます。そのため、保存操作時のファイルのレンダリングは順序付けされていません。

最初に質問したいのですが、これを回避するためのエレガントな方法を見つけた人はいますか?

次に、次の 2 つの提案を行います。

• Microsoft に上記のファイルを再実装してもらい、要素の順序を厳密に制限してください。

• vcproj (xml 形式) および sln (sln 形式...) ファイルをアルファベット順に、再帰的に (要素内のすべての要素など) 並べ替えるツールを見つける (または作成する)。ソース ファイルとターゲット ファイルの両方でこのツールを使用すると、Visual Studio が並べ替えられ、マージされたプロジェクトまたは sln ファイルを読み取ることを期待して、変更を簡単にポイント (およびマージ) できます。

その他のアイデアや考えは大歓迎です。

Microsoft Visual Studio (2005 および 2008) では、ソリューションを少し変更するたびにプロジェクト ID (GUID) をシャッフルするのが楽しいようです。ソース管理で誰かがブランチをマージしなければならないたびに、この小さな詳細がフラストレーションにつながることがわかりました...

チェックイン前にこれらのプロジェクト ID をソートするための小さなツールをコーディングすることを検討しました。このように、マージはより簡単になります。それを行う Visual Studio オプションで見逃したオプションはありますか?

トランクとブランチがあるSVNリポジトリがあります。

定期的にトランクをブランチにマージするつもりですが、これを行うと、実際のファイル コンテンツの変更に加えて、多くのプロパティ ステータスの変更が表示されます。

さらに調査すると、プロパティの変更は mergeinfo プロパティです。分岐とマージは常に最上位のルート レベルから行うため、これは予想外です。

トランクをマージする前に、コマンドを使用svn propdelしてブランチ WC からすべての mergeinfo プロパティを削除し (その後、ルートの変更を元に戻しました)、問題は解決しました。

問題は、私のブランチがサブディレクトリ レベルでこれらすべての mergeinfo の変更をどのように取得したかということです。

完了した一連の作業項目があり、それらの変更を本番ブランチに移動する準備ができています。それらに添付されている変更セットを見つけて、それらをターゲットブランチと選択的にマージすることは可能ですか?

Subversion 1.4.6 を使用していますが、現在、バージョン 1.5 にアップグレードできません。

状況：

1. トランクには多くの構造上の変更があります (つまり、主にファイルの移動)。

2. 最近トランクからマージされたブランチがありますが、大きな変更はありません。

トランクをブランチにマージする最良の方法は何ですか?

私が考えていたこと：

1. 最初に、ブランチ内の変更されたファイルのみをトランクにマージすることにより、ブランチをトランクに慎重にマージします。

2. トランクをブランチにコピーします。ブランチ履歴を失わずにこれを行う最善の方法は何ですか? ブランチを非推奨にして、新しいブランチを作成する必要がありますか?

わかりました、SVN に十分なクレジットを与えていないようです。結局のところ、それは十分に賢いです。"D" と "A" の出力にちょっと気が進まなかったのですが、バックグラウンドで動きました。

2 つの .NET 構成ファイルをマージするために、このコードを作成しました。存在しないノードを追加し、既存のノードの値をオーバーライドします。私が使用しているアプリはパフォーマンスが重要ではないため、はるかに高速なリーダー/ライターの方法を使用することを避けました。これについてどう思いますか？