興味深いソース管理ワークフローの問題があります。
私の会社は、現在活発に開発されている製品を追跡するためにSVNを使用しているサードパーティの請負業者と協力しています。今後数か月以内にこのリポジトリを引き継ぐ予定ですが、プロジェクト内の他の機能の作業を開始したいと思います。明らかな理由で、私たちの請負業者は私たちがアクセスをコミットすることを拒否しましたが、彼らのSVNリポジトリへのアクセスを読み取ることに同意しました。
Windows開発マシンには、Mercurialリポジトリを使用します。 どういうわけか、SVNリポジトリを新しいHGリポジトリにコピーし、SVNにコミットされた変更を定期的にHGにマージしたいと思います。 つまり、2つの異なるリポジトリで並行して作業します。
誰かがこのようなことをしましたか？アプローチに関する提案はありますか？
ありがとう。
水銀の変更が増加し、水銀の変更と決してマージされないSVNの変更からさらに離れていくにつれて、プロセスは最悪になるだけだと思います。しかし、Mercurial がどのようにその複雑さと公平に融合するかを知りたいと思います。私はこのようにアプローチします：
1) svn からエクスポートして hg リポジトリを作成します。この/SvnExportCleanHG
Clone を呼び出して、会社のすべての新機能が移動する作業コピーにします。/WorkingHG
2) SVN から新しい変更を取り込みたい場合は、svn update/SvnExportCleanHGを実行し、これをクリーン リポジトリにコミットします。これには、svn からのオリジナルと最新の 2 つのリビジョンがあります。内部から/WorkingHG実行し、hg pull /SvnExportCleanHGすべての必然的な変更をマージします。それを WorkingHG リポジトリにコミットします。
これで、mercurials マージを最大限に活用しようとしましたが、/SvnExportCleanHG競合することなく SVN から次の変更をプルできるクリーンな状態が残っています。
svn から再度更新したいときはいつでも、ステップ 2 を実行します。svn からの更新とクリーンなリポジトリでのコミットは、svn のみを反映するため競合することはありませんが、作業コピー HG からプルしてマージすることは常に許可されます。同じに基づいています。
Mercurial のマージで多くのメリットが得られるかどうかは、変更のレベルと SVN からの変更によって異なります。コードのさまざまなベースラインにとどまる場合、これは優れたワークフローであり、手作業を大幅に節約できます。重複が多い場合でもこれは機能しますが、多くのマージの問題を解決するのではなく、ワークフローを容易にするだけです。
あなたが試してみたら、これがどのように機能するのか、私は本当に興味があります.