問題タブ [merge]

a.gz と b.gz があるとしましょう。

$ gzip_merge a.gz b.gz -output c.gz

このプログラムをやりたいです。もちろん、

$ 猫 a.gz b.gz > c.gz

動作しません。a.gz の最後の DEFLATE ブロックには BFINAL があり、b.gz の GZIP ヘッダーがあるためです。(RFC1951、RFC1952 を参照) ただし、BFINAL の設定を解除し、2 番目の GZIP ヘッダーを破棄して、2 番目の gzip ファイルのバイト境界を通過すると、マージできます。

実は、この件についてオープンソース プログラムを書こうと思ったのですが、それを公開する方法がわかりませんでした。そこで私は Joel に私のプログラム マネージャーを依頼し、私の説明と弁明について説明しました。彼は最終的に私がやりたいことを理解してくれましたが、忙しすぎると言いました。:(

もちろん、自分で書いて、自分のやり方で公開することもできます。しかし、私の日中の仕事は雇用主の所有物であるため、これを一人で行うことはできません。

ボランティアはいますか？プログラマー（私）、パブリッシャー（あなた）、またはプログラマー（あなた）、パブリッシャー（私）として働くことができます。私が必要とするのは、いくらかの信用です。RFC3320 で説明されている Universal Decompressor Virtual Machine を実装したことがあります。だから私はこれが実現可能であることを知っています。

または、そのプログラムを教えてください。365 (日) の gzip 圧縮されたログ ファイルを 1 つにマージするなど、ログ ファイルの管理に非常に役立ちます。;)

ありがとう。

3 つのテキスト ファイル (A、B、C) があり、それぞれに数百の電子メール アドレスが含まれています。リスト A とリスト B を 1 つのファイルにマージし、大文字と小文字の違いと空白を無視したいと考えています。次に、リスト C にある新しいリストのすべてのメールを削除します。大文字と小文字の違いと空白は無視します。

私が選んだプログラミング言語は通常 C++ ですが、このタスクにはあまり適していないようです。比較的少ない行でこれ (および同様のタスク) を実行できるスクリプト言語はありますか?

または、それを可能にするソフトウェア (無料または商用) が既に存在しますか? たとえば、Excelでそれを行うことは可能ですか？

1 つのファイルにマージ (結合) する必要がある Word ファイルが多数あり、Word マージを (1 つずつ) 使用するには時間がかかります。この仕事を処理できるツールを経験したことがありますか?

Dictionary<T1,T2>C#で2つ以上の辞書()をマージする最良の方法は何ですか? (LINQ のような 3.0 機能は問題ありません)。

私は次の行に沿ったメソッド署名を考えています:

また

編集: JaredPar と Jon Skeet からクールな解決策を得ましたが、重複したキーを処理するものを考えていました。衝突が発生した場合、一貫性がある限り、どの値が dict に保存されるかは問題ではありません。

現在、私は 2 つの MediaWiki を持っています。一方は他方より少し古いバージョンです。重複ページを排除せずに、両方のコンテンツをマージしたい。これまでのところ、私が考えることができる最良のオプションは、ボット (pywikipedia など) を使用して 1 つの wiki のすべてのページを調べ、それらを別の wiki に挿入して、重複するページの名前を変更することです。

ただし、この解決策を達成するにはしばらく時間がかかるようです。私が気付いていない、これを行うためのより快適な方法はありますか? 私は MediaWiki データベースを直接操作したことがあまりないので、自分が何をしているのかを知らずにそれをいじるのはあまり快適ではありません。

Word テンプレートを読み取り、差し込み印刷機能を使用してそのコピーを n 個作成する C# プログラムを作成したいだけです。置き換えるデータは名前とアドレスであり、テンプレートの残りの部分は同じままにする必要があります。誰でもこれを行う方法を教えてもらえますか?

優れた無料のバージョン管理とSubversionの本を使用して、Subversion1.5との分岐/マージについて読んでいます。Subversionコマンドラインクライアントを使用して、最も頻繁に必要なアクションを実行する方法を理解していると思います。

トランクからの変更でブランチを更新

ブランチの作業ディレクトリから次のコマンドを実行します。

svnマージhttp://svn.myurl.com/proj/trunk

ブランチをトランクにマージ

トランクの作業ディレクトリから次のコマンドを実行します。

svn merge --reintegrate http://svn.myurl.com/proj/branches/mybranch

ただし、SubversionへのインターフェースとしてTortoiseSVN1.5を使用しています。TortoiseSVNでこれらの操作を実行するための最良の方法を知りたいです。新しいダイアログには、メインメニューに3つの異なるオプションがあります。

1. 一連のリビジョンをマージする
2. ブランチを再統合します
3. 2つの異なるツリーをマージします

私が収集できることから、TortoiseSVNは常に次の構文でsvnを実行します。

svn merge [--dry-run] --force From_URL @ revN To_URL @ revM PATH

さらに、ブランチの再統合は、一部のターゲットがマージされていないため続行できないことを示すメッセージで失敗することがよくあるため、オプション＃3を使用する必要がありました。

私の質問は次のとおりです。

1. TortoiseSVN 1.5を使用して、トランクからブランチへの変更をマージするにはどうすればよいですか？
2. TortoiseSVN 1.5を使用して、reintegrateメソッドを使用する場合と使用しない場合で、ブランチをトランクにマージするにはどうすればよいですか？
3. 上記のオプションのどれをそれぞれに使用する必要がありますか、またその理由は何ですか？

編集

「ドライラン」テストを通じて、コマンドラインのSubversion操作が

svnマージhttp://svn.myurl.com/proj/trunk

リビジョン範囲を空白のままにする限り、TortoiseSVNのオプション＃1（リビジョンの範囲をマージする）に類似しています。

メイン ブランチ (黒) と機能ブランチ (黄色) の 2 つのブランチがあります。

ご覧のとおり、フィーチャー ブランチがフォークされたため、main から変更を取得して最新の状態に保たれています。

代替テキスト http://azkotoki.org/images/stackoverflow/tgh-reintegrate1.gif

フィーチャー ブランチをメイン ブランチに再統合すると、ログ ウィンドウに次の醜いグラフが表示されます。

代替テキスト http://azkotoki.org/images/stackoverflow/tgh-reintegrate2.gif

各マージ ポイントは、フィーチャー ブランチとマージされた新しいブランチとして表示されます。複数の機能ブランチがあれば、これを読むのはほとんど不可能になります。私も試してみましhg viewたが、結果はさらに奇妙です。

上の図に関係なく、最終的なマージ結果は問題ありませんが、再統合されたブランチのグラフが気になります。

機能ブランチに何度もマージして何か間違ったことをしていますか? それとも、tortoisehg のログ ウィンドウに期待しすぎですか :) ?

前もって感謝します

極端な嘲笑の可能性を受け入れて、私は本当に Sun Teamware のファイルマージ ツールが恋しいことを認めなければなりません。私はsolarisからred hat linuxに切り替えました.filemerge（同じ名前のAppleツールと混同しないでください）とsolarisバージョンのpstack（pidと同様にコアファイルでも機能しました）が定期的に不足していることに気付きました）。

そこに慰めのアドバイスを持っている専門家はいますか？祖先を組み込んだより良いマージツールはありますか? コア ファイルのコール スタックを 1 行で表示する方法はありますか?

助けてください！

2 つのブランチがあります: 1. HEAD - 最新バージョン (別名 Trunc) 2. PROD - リリース済みバージョン

リリースされたバージョンのバグを修正する場合、次のうちどれを行いますか:

1. PROD で修正してから、HEAD にマージします
2. HEAD で修正してから、PROD にマージします

(1) の利点は、この方法では、HEAD からテストされていないコードを誤って持ち込んで、リリースされたバージョンに害を与えることが絶対にできないことです (PROD は常に HEAD よりも安定しており、テスト済みであるという前提があります)。

(2) の利点は、PROD よりも HEAD の方がコード片の使用法が多い可能性があることです。そのため、PROD でのみ修正すると、そのような使用法をすべて見つけることができず、バグを HEAD に滑り込ませる可能性があります。

個人的には(1)です。どう思いますか？