新しい構造を新しいTFSリポジトリに設定し、チームプロジェクトを次のような構造のサブフォルダーにマップしようとしています。
根
- トランク
- (TeamProject)Proj1
- SubProj1
- SubProj2
- SubProj..。
- (TeamProject)Proj2
- ..。
- (TempProject)..。
- グローバル
- (TeamProject)Proj1
- リリース
- Proj1
- SubProj1 V3.5
- Proj1(ブランチ)
- SubProj2(ブランチ)
- SubProj4(ブランチ)
- グローバル(支店)
- Proj1(ブランチ)
- SubProje1 V3.6
- Proj1(ブランチ)
- SubProj2(ブランチ)
- SubProj4(ブランチ)
- グローバル(支店)
- Proj1(ブランチ)
- SubProje2 V2.1
- Proj1(ブランチ)
- SubProj1(ブランチ)
- SubProj7(ブランチ)
- グローバル(ブランチ)..。
- Proj1(ブランチ)
- SubProj1 V3.5
- Proj2..。
- Proj1
- サードパーティのライブラリ
- Lib1
- Lib2
これは、これまでの差分sccシステムでの作業に使用されている構造に関するものであり、それらすべてを新しいTFSリポジトリに統合しようとしています。
私たちの見解では、この構造にはいくつかの利点があります。
- TFS(作業項目、ビルド)のチームプロジェクト機能は、社内のチームごとに分けられており、ビルドのリストは、特定のサブプロジェクトを検索するのにそれほど長くはありません。
- リポジトリをローカルハードドライブにマップするには、リポジトリの「Trunc」パスと「サードパーティライブラリ」パスを同期するだけで、過去15年間のすべてのブランチを各ハードディスク(ギガバイトのゴミ箱)にロードしないようにする必要があります。Truncのメインサブフォルダーには、私たち一人一人が毎日使用するアクティブなソースコードのみが含まれています。
- certailブランチをbufix/recompileするために、リリース内の特定のサブフォルダー(つまり、/ Release / Proj4 / SubProj2 V4.5 / *)のみをチェックアウトします。これは、サイズが数メガバイトしかないものです。再構築後、このサブフォルダーのマッピングをハードディスクから削除できます...
Webを見て回ったのですが、TFSの構造が厳しすぎて、チームプロジェクトはリポジトリのルートにしか配置できないようです。それは可能ですか?ある場所でチームプロジェクトを管理し、別の場所でリリースブランチを処理する方法はありませんか?そして、いくつかのチームプロジェクトから使用される自己開発の共通ライブラリはどうですか?
私たちのリポジトリ(いくつか)では、さまざまなトピックにグループ化されたプロジェクトが何百もあります。トピックのチームプロジェクトを作成し、個別の.slnファイルを使用して、チームプロジェクト内のさまざまなサブフォルダーによって実際のプロジェクトを管理したいと思います。しかし、私は本当にすべてのアクティブなソースからリリースブランチを分離したいと思います...
これを処理する方法はありますか?
あなたの答えをありがとう、私はあなたが残酷に答えたものを聞くのが怖かった...
同じベースライブラリを使用するチームプロジェクトがいくつかあります。リリースブランチでは、通常、これらのベースライブラリもブランチして、これらのライブラリを安定してサポートします。TFSで、アプリケーションに異なるチームプロジェクトを使用し、ベースライブラリに別のチームプロジェクトを使用する場合、App1のリリースブランチ、つまりアプリのパスが分岐した「App1V3.2」を作成できますか?使用されているライブラリのパス?または、アプリケーションのリリースブランチを作成するたびに、ベースライブラリチームプロジェクトもブランチする必要がありますか?次に、App1の適切なリリースからベースlib3およびベースlib5の適切なリリースを見つけるにはどうすればよいですか?
なぜMSのすべてがそれほど複雑でなければならないのですか?一見クールなシステムですが、使ってみると、働き方を完全に変えないといけないことがわかります...
TFSは、PERFORCE、SubversionなどのSCCとしてのみ使用できますか?team-project-root-levelを取り除く方法はありますか?または、サブチームプロジェクトを定義する方法はありますか?
さて、私が1つの大きなチーム、つまり「開発」を作成し、最初のドラフトと同様のサブフォルダー構造を持つことにした場合、アイテム/ビルドはどうですか?つまり、実際の好みを表すグループにビルドを入れることはできますか(ドラフトではサブプロジェクトと名付けました)?それ以外の場合は、「開発」チームプロジェクトのビルドの数百のリストと、社内のまったく異なるチームに属する何千ものアイテムがあります...