3

Visual Studio 2005 と 2008 の別々のバージョンのライブラリを維持しながら、一方のブランチへの変更が常に他方のブランチにレプリケートされるようにするワークフローを開発しようとしています。

現時点では、変更はデフォルト (VS2005) ブランチに対してのみ行い、完了したら VS2008 ブランチにマージすることをお勧めします。残念ながら、これは、問題が見つかったときや危機に瀕しているときに問題を修正するだけでなく、それが難しい場合があるという規律に依存しています。これにより、あるブランチからの変更を後でデフォルトに戻すことを試みる必要が生じました。

VS2005 と VS2008 プロジェクトの間の変更をパッチ キューに保存できることはわかっていますが、コマンド ラインの使用に慣れているのはチーム内で私だけであり、同僚は Tortoise HG を使用してすべてを行うことを好みます。

そのため、私は事後の問題の修正に依存しています。私の現在の手順では、VS2008 ブランチのすべての変更セットのパッチをエクスポートし、それらをデフォルト ブランチに適用しています。これには時間がかかりますが、VS2008 ブランチのヒントをデフォルトのヒントとマージしてから、手動で VS2005 に戻すよりもエラーが発生しにくくなります。

この記事を読んで、「アップグレード」チェンジセットを取り消そうとしましたが、結果のバックアウトチェンジセットは常に VS2008 ブランチの新しいヒントとして終わります。さらに、変更をマージして元に戻すことはできません。 VS2008 ブランチでは、コミット時にブランチを明示的に閉じようとしても。

さまざまな方法でこれを試してみましたが、常に新しい VS2008 ブランチのヒントになり、変更をデフォルトのブランチにマージする方法がありません。そのため、ここで明らかな何かを見逃していることに気づき始めています。

結局のところ、プロジェクト ファイルとソリューション ファイルに埋め込まれた Visual Studio のバージョン番号だけが必要なライブラリの 2 つのバージョンを維持しようとするとき、他の人は何がベスト プラクティスだと感じるでしょうか?

編集:私が回避しようとしている問題は、VS2005 プロジェクトを VS2008 ソリューションに追加すると (デバッグを容易にするために)、VS2005 プロジェクトが VS2008 に自動的に「アップグレード」され、その結果、「変更された」作業コピーと飛散が発生することです。不要な「変換」ファイルの。したがって、人々がメインラインへの「アップグレード」をコミットしたくなるよりも、ブランチを別々に保ち、ユーザーがクローン後の最初の更新で必要なバージョンを選択するように要求することを好みます。


さらに編集して、解決策を示します。

さらにいじって、このワークフローを標準の TortoiseHg ツールで動作させる方法を見つけました。コマンド ラインの介入は、セットアップのみに必要でした。

まず、プロジェクトが VS2005 から VS2008 に変換された変更セットに更新しました。そのリビジョンをバックアウトし、バックアウトのパッチを作成し、バックアウトされた変更セットを削除しました (デフォルト ブランチにあったため)。次に、変換変更セットにバックアウト パッチを適用し (hg patch --no-commit patch を使用)、新しい「VS2005」ブランチ名でパッチをコミットしました。次に、(名前のない) VS2005 ブランチの先端にマージしました。

次のステップは、(変更されていない) VS2008 ブランチの古いヒントに更新し、重要でない変更を加えて、新しい「VS2008」ブランチとしてコミットすることでした。次に、VS2005 のヒントからの変更をマージしましたが、コミットしたときに、csproj ファイルへの変更をコミットできませんでした。次に、コミット後にこれらのファイルを元に戻しました。

最後に、VS2005 のヒントに更新し、VS2008 のヒントにマージしました。

これにより、VS2005 から VS2008 への変換による違いを除いて、同じコードを持つ 2 つのヒントが得られました。

新しいワークフロー:

  • 必要に応じて、VS2005 または VS2008 ブランチで作業します。
  • 1 つのブランチで更新が完了したら、他のブランチを更新し、変更されたブランチからの変更をマージして、独自のブランチにコミットします。次に、好みのブランチに更新します。
  • 両方のブランチで同時に更新が発生する場合は、両方のブランチを別々に実行します。VS2005 のヒントに更新して VS2008 のヒントにマージしてから、VS2008 のヒントに更新して以前の (マージ前の) VS2005 のヒントにマージします。
4

5 に答える 5

2

問題を解決する代わりに、問題を解決しようとすることもできます: premakeを試してください。

Premake はビルド前のシステムです (その名前が示すように、必要に応じて pre-make または pre-MSBuild を実行することを目的としています)。Lua スクリプト言語の上に構築された宣言型の内部 DSL でプロジェクトを一度記述すると、premake は VS2008、2005、2003、および 2002、MonoDevelop、SharpDevelop、Code::Blocks、CodeLite、または GNU Makefile のソリューションとプロジェクトを自動的に生成できます。 Unix、Cygwin、または MinGW のいずれかです。現在、32/64 ビット、OSX ユニバーサル バイナリ、PlayStation 3 および XBox 360 のクロスコンパイルを含む、C++、C、および C# プロジェクトのビルドをサポートしています。

構成言語は非常にクリーンで宣言的です。ただし、Lua の上に内部 DSL として構築されているため、非常に強力で美しく、表現力豊かな (そして最も重要なのはチューリング完全な) スクリプト言語を指先で完全にサポートすることもできます。構成言語の構造と用語は両方とも、Visual Studio に直接基づいています。ソリューション、プロジェクト構成、およびプラットフォームについて説明しています。

プリメイク ツール自体は、Lua インタープリター、Lua 標準ライブラリ、そしてもちろんプリメイク スクリプト自体を含む単一の .exe として配布されます。外部の依存関係はまったくなく、構成ファイルを作成したり、レジストリを作成したり、読み取ったりすることはありません。

必要なことは、VS2008 ソリューションを手動で一度プリメイクに変換することだけです。

于 2009-12-04T15:41:46.997 に答える
1

The Mercurial: The Definitive Guide book には、Mercurial Patch Queues を使用して古い Linux カーネルのバックポートを維持する方法に関する章全体があります。mq 拡張機能が役立つと思います。

于 2009-12-04T14:17:48.890 に答える
1

個別のソリューション ファイルとプロジェクト ファイルを使用します。.sln と .csproj/.vcproj/.vbproj をコピーし、メモ帳で編集して新しいファイルを使用します。クラスを追加するときは、他のソリューションにファイルを追加することを覚えておく必要がありますが、それ以外の場合は、修正をコピーすることを覚えておく必要はありません。

于 2009-12-04T14:16:16.880 に答える
0

ソース コードと Visual Studio 2005 プロジェクト ファイルを含むブランチは 1 つだけにして、2 つの異なるブランチを維持する必要があるかもしれません。2 番目のブランチには、ソース コードではなく、Visual Studio 2008 プロジェクト ファイルのみを含める必要があります。Visual Studio 2008 バージョンをコンパイルするには、ローカル ドライブにすべてのソース ファイルのハード リンクを作成して、それらが両方のフォルダー ツリーに表示されるようにします (リポジトリから最新の更新プログラムを取得するためのコマンドと共にハード リンクの作成をバッチ ファイルに入れます)。 )。このアプローチには、NTFS ファイル システムと適切な「ln」コマンド ライン ツールが必要です

そのため、必要ないずれかのフォルダーでソース コードをデバッグ/編集できます。すべての変更は、他のフォルダーにもすぐに表示されます。

編集:はい、私は自分でそれを試しましたが、うまくいきます。C++ アプリケーションを Visual Studio 2008 と古い Borland コンパイラでコンパイルするという非常によく似たシナリオがあります。

于 2009-12-04T23:34:44.393 に答える
0

It seems a little odd to answer my own question, but without doing this I can't indicate to StackOverflow that this question has an accepted answer.

For full details, see my question - after the horizontal rule.

I should add my thanks for everyone elses answers though. I may still find a use for premake, and seperate project/solution files could work in other situations. One day I will undoubtedly find a use for Mercurial Queues myself, but I doubt I will ever get the rest of my development team to use them. I've never been comfortable with hard links on Windows, so I probably won't ever try that, but it's good to be reminded of their existance.

Take care & thanks again to everyone who took the time to respond.

于 2010-01-15T12:42:42.447 に答える