4

私が働いている会社には、私たちが維持している 1000 以上のアプリがあります。これらの多くは、VB6 などの古いテクノロジ、または貧弱なテクノロジ (アクセス) にあります。

Source Safe からの移行を検討しています。TFS を実行しており、dot.net プロジェクトを TFS に移行しています。他のプロジェクトは TFS と統合されず、ポータルやその他の TFS 機能 (ソース管理を除く) は必要ありません。

製品の信頼性が低いため、他のプロジェクトを Source Safe に残すことを懸念しています。

私が見る限り、2 つのオプションがあります。

1) TFS で「VB6」と呼ばれる空のプロジェクトを作成します (たとえば)。VSS にある VB6 アプリごとに分岐します。これにより、すべての VB6 アプリがそのサブフォルダーに配置されます。このようにして、すべてのアプリを TFS に含めることができます。

2) ドット ネット プロジェクトを TFS に配置します。CVSNT リポジトリを作成し、他のすべての VSS プロジェクトをそこに置きます。

3) ドット ネット プロジェクトを TFS に配置します。他のすべてのプロジェクトは VSS のままにします。すべての VSS データベースで毎週の圧縮と修復を実行します。

人々はどのオプションが最良だと思いますか? 他の誰かが同様の状況にありましたか?

4

4 に答える 4

3

3 つのオプションのどれも私には意味がありません。SourceSafe からの移行を検討しており、(少なくとも .NET プロジェクトでは) TFS への移行を既に決定している場合、基本的には、1000 のソースを移行する良い方法があるかどうかを尋ねているようです。古いテクノロジ アプリケーションを TFS に?

ソース管理エクスプローラーを TFS の SCC クライアントとして単純に使用することをお勧めします。これは、SourceSafe GUI と同様に機能します。うまくいかない理由はありますか？

于 2009-02-13T07:10:43.320 に答える
2

私見の問題は、「プロジェクト」の定義です。チーム プロジェクトは、プロセスと分離を定義するために使用される高レベルのコンテナーです。複雑なソース ツリーを持つ VB6 チーム プロジェクトを作成しない理由はありません。VB6 アプリごとに実際の「ブランチ」(ブランチとマージ) を作成する必要はありません。SCC とまったく同じフォルダー構造です。

したがって、基本的に、最初のオプションを実行しない理由はありません-分岐のオーバーヘッドを気にしないでください（実際に必要でない限り）

于 2009-07-02T15:15:00.397 に答える
0

オプション3は、VSSリポジトリのサイズが1〜2 GB未満であると仮定すると、このような状況で最も経済的な賭けのように思われます（私の理解では、リポジトリが大きくなると破損しやすくなります。これにより、メモリが失われます。 、しかし、私は間違っている可能性があります）。保険のために物理的に離れた場所にVSSのバックアップを保管し、それ以外の場合は現状のまま継続します。一般的なケースで説明するように、移動を行うためのROIは比較的低くなります。

于 2009-02-13T05:32:44.600 に答える
-3

Git > TFS、代わりにそれを使用してください。

于 2009-02-13T05:10:55.370 に答える