数か月前、私のチームはソース管理をVisual SourceSafeからApache Subversionに切り替えましたが、これまでにないほど満足しています。
最近、私はTeam Foundation Serverを見てきましたが、少なくとも表面的には非常に印象的です。Visual Studio との優れた統合と、DBA、テスター、プロジェクト マネージャーなどのための優れたツールが多数あります。
これら2つの製品の最も明白な違いは価格です。Apache Subversion (無料) に勝るものはありません。Team Foundation Server は非常に高価なので、余分な機能を追加するには、Subversion のズボンを蹴る必要があります。
私にとって2つの最大の違いは次のとおりです。私は両方を使用しました。
1）TFSは、開発を行う「Visual Studioの方法」とかなり密接に結びついています。 これは、TFS が VS IDE に緊密に結合されていると言っているわけではありません。つまり、TFS は、Visual SourceSafe の使い慣れた「チェックイン」/「チェックアウト」パラダイムを維持するのに苦労していることを意味します。Subversion の「コミット」/「更新」の概念は、開発者がネットワークから切断されて時間を費やす可能性がある場合に、より現実的になります。TFS は、開発者が常にサーバーに接続されていることを想定しています。それは大きなマイナスです。個人的には、TFS は、Visual Studio と緊密に統合されているため、サーバー上およびローカル ディスク上でファイルがどのように編成されているかについて透明性が低いと感じています。TFS の強力な支持者でさえ、その接続されたチェックイン/チェックアウト モデルは、ネットワークに接続されていない開発者にとって魅力的なオプションではないことを認めています。
2)コスト。 TFS が高くないという人は、おそらく非常に小規模なショップであるか、TFS のライセンス条項に準拠していないかのどちらかです。ほとんどすべてのことを行うには、クライアント アクセス ライセンスが必要です。あなたはバグを管理するだけのマネージャーですか? ~250 ドルの CAL が必要です (製品版の TFS ライセンスには 5 つ含まれています)。問題を報告したいだけのビジネス ユーザーですか? $250 CAL. 開発者？250 ドル (ただし、MSDN が含まれている場合を除きます)。サーバー？500 ドル (MSDN をお持ちの場合は含まれています)。もちろん、TFS のコピーを販売している人は、作業項目の追跡は追加のユーザーに対しては無料であると言うでしょうが、これらの追加のユーザーは、チーム全体の作業項目ではなく、自分自身が作成した作業項目のみを見ることができます。チーム指向のアジャイル環境では役に立ちすぎます。中規模の組織の場合、これらすべてが加算され、SVN や CruiseControl.net の増分コストが 0 ドルのような多くの最高の製品を正当化するのは難しくなります。(ただし、TFS に公平を期すために、私はまだ非常に優れた OSS 課題トラッカー)
3)プロジェクト構造。 プロジェクトの数が少ない大規模なチームでは、TFS はおそらくうまく機能します。小規模な、接続されていない、または緩く接続された基幹業務アプリを社内で多数使用している場合、TFS の構造は威圧的になり始める可能性があります。まず、プロジェクト自体の分類法を定義することはできません。プロジェクト内に「エリア」を設定することはできますが、すべての問題とドキュメントは「プロジェクト」の基本的なコンテキスト内で一緒に追跡されます。新しい「プロジェクト」の作成には多くの場合時間がかかり、小さな労力ではやり過ぎです。もちろん、SVN はソース コード管理のみに焦点を当てているため、そのようなものは何もありませんが、小規模プロジェクトの柔軟性が必要な場合は、SVN と別の問題追跡ツールを使用することをお勧めします。
私の意見、それが価値があるものについて：
大規模で十分な予算のプロジェクトを持つ大規模なチームの場合、開発者がほぼ独占的に IDE 内で作業する Microsoft ショップでは、TFS が勝者です。プロジェクトにポリシーを一元的に適用する必要がある場合にも、TFS は優れています。
多数の小規模なチーム、多数の多様な小規模プロジェクト、コストが問題となるショップ、またはソース管理から切り離されて作業する開発者がいるチームの場合は、SVN を使用します。
過去に Subversion を使用したことがある人が、TFS ソース管理を必要としていることに驚きました。
TFS (2005) での私の経験はかなりひどいものでした。さまざまな開発ニーズに合わせてソースを適切に構成する方法について、あらゆる種類のホワイトペーパーとガイダンスを読みました。
メインライン開発のトランク、変更を統合して展開する統合ブランチ、過去のリリースを追跡するリリース ブランチがある単純な状況は、非常に一般的で簡単ですが、継続的に問題に遭遇しています。
TFS に関する私の主な問題:
...リストは続きます。すべての統合があっても、はるかに優れた無料の代替手段があると思います.
最近、CodePlex でオープン ソース プロジェクトに参加しました。彼らはソース管理に TFS を使用していますが、これは非常に優れていると言わざるを得ません。これまでのところ、私はそれに非常に感銘を受けています。私は IDE 統合の大ファンであり、コードの分岐とタグ付けがいかに簡単かを知っています。ソース管理へのソリューションの追加は、すべてが適切に構成されている場合、2 回のクリックのようなものです。
今。それは多額の値札の価値がありますか？私はそうは思わない。CodePlex でプロジェクトに取り組む利点は、後でどこかで TFS を使用する必要がある場合に、必要な TFS の経験を積むことができることです。ソース管理に優れた IDE 統合が必要な場合は、VisualSVN統合パッケージを入手してください。多くの同じ機能を取得するのは、はるかに安価な投資です (ところで、ドメイン以外のコンピューターでは無料です)。
私たちは VS.NET ショップであり、以下を実装しました。
コスト: $0 メリット: プライスレス
小規模なチームであるか、who TFS プロセスを受け入れる準備ができていない場合は、SVN とオープン ソース ツールが最適です。
他の人が指摘しているように、TFSは、プロジェクト管理などの形でSVNよりもはるかに多くの機能を提供します。両方を使用し、TFSの実装で非常に大規模な企業と協力してきたので、これが私の2セントです。
1）TFS 2005を使用している場合は、TFS2008にアップグレードしてください。ありがとうございます。TFS 2008には、実行可能にするための多くの改善点があります。
2）Visual Studioに住んでいて、IDE統合が必要な場合は、TFSを使用してください。私はSVN統合を使用しましたが、ほとんどの場合、TortoiseSVNの使用に戻ります。
3）アカウントをWindows認証と統合するというアイデアが気に入った場合は、TFSを使用してください。その端からの管理性は素晴らしいです。SVNにはフックがあるかもしれません-私は前向きではありませんが、GUI主導の管理が好きなら、TFSに勝るものはありません。
4）メトリックを追跡する必要がある場合、またはチェックインポリシーなどを実装する簡単な方法がある場合は、TFSを使用します。
5）MSFTでない場合に実装しない人がいる場合は、TFSを使用してください。
6）.NET（Java作業、Eclipseなど）以外のことを行う場合は、SVNを使用してください。はい、TFSでうまく機能する非常に優れた製品（Teampriseなど）があります。しかし、他の言語があなたの店のごく一部でない限り、SVNに固執するだけです。
それ以外では、両方のSCM機能はほぼ同等です。どちらも分岐とマージを行い、どちらもアトミックチェックインを行い、どちらも名前の変更と移動をサポートします。分岐とマージの概念を始めたばかりの人にとっては、ソース管理エクスプローラーで分岐を表示できるようにするのは良いことだと思います。
TFSは実際にはそれほど高価ではありません（おそらく1200ドル？）。SVNと比較すると、おそらくそうです。レポートサービスとSharePointの統合は優れていますが、それを使用していない場合は問題ありません。
私が言いたいのは、TFSの180日間の試用版をダウンロードして試してみることです。トライアルを並べて実行します。どちらに行っても幸せになると思います。
Ubiguchi が指摘するように、TFS はバージョン管理製品ではありません。バージョン管理のみを目的として TFS を購入するのは明らかにお金の無駄です。TFS は、アプリケーション ライフサイクル管理のすべての側面を自動化するためのツールの統合スイートです (そして、ほぼ「エンタープライズ」向けです。
また、Ben S の投稿によると、ロックに関するあなたのコメントがわかりません。TFS ではロックはまったく必要ありません。管理者は、TFS を VSS (一部の「愚かな」顧客が要求する機能) のように機能するように構成して、チェックアウト ロックも行うと思われる「チェックアウト時に最新のものを取得」することができます。
しかし、TFS の「通常の」使用を通じて、「チェックアウト」はユーザーにロックの種類を求めるプロンプトを表示します。デフォルトは「なし」である必要があります。ユーザーはチェックアウト (またはチェックイン ロック) を選択できますが、必須ではありません。ロックが必要ない場合は、使用しないでください。
TFS は、さまざまなパフォーマンス上の理由 (get-latest を高速化する) とプロジェクト管理 (どの開発者がファイルをチェックアウトしているか、チェックアウトにどのくらいの時間を費やしているかを確認したい) の両方で、どのユーザーがサーバー上でチェックアウトしたかを追跡します。
私はSVNにあまり詳しくありません（使用したことはありません）-「TFSではマージが悪い」とコメントすることはできません-そして、Ben Sが報告したマージバグにヒットしていません-しかし、私は素晴らしい経験をしましたTFS を使用した分岐とマージの成功。
TFSがまだかなり弱いと私が知っているユースケースの1つは、定期的に「オフライン」になっているユーザー向けです。TFS は、ユーザーがほとんどの時間接続していることを前提とした「サーバー製品」です。オフライン エクスペリエンスは 2008 リリースで改善されましたが (2005 年には悲惨でした)、まだ長い道のりがあります。長時間ネットワークから頻繁に切断する必要がある (または望んでいる) 開発者がいる場合は、SVN を使用する方がよいでしょう。
TFS を使用している SVN ファンが考慮すべきもう 1 つの機能は、ユーザーが TortiseSVN を使用して TFS に接続できるようにするコードプレックスであるSVN ブリッジです。私の良き友人であり同僚である私は、それを広範囲に使用し、愛しています。
また、コマンド ラインがないというコメントには驚かされます。
Ben のコメントは、明らかに「Microsoft V1.0」製品であった 2005 リリースの評価に基づいているのではないかと思います。この製品は現在 2.1 で、バージョン 3 は近い将来にリリースされます。
TFSは凶悪です。この時点で、TFSに多くの問題があるため、SVN（バックアップ用のLive Mesh付き）を使用してローカルでバージョン管理を行っています。主な問題は、TFSがタイムスタンプを使用して最新バージョンを使用しているかどうかを記録し、これらのタイムスタンプをサーバーに保存することです。ローカルコピーを削除し、TFSから最新のものを取得すると、すべてのファイルが最新であると表示されます。それはあなたが正しいバージョンのファイルを持っているという保証をあなたに与えないばかげたシステムです。これにより、多くの煩わしさが生じます。
TFSはマージをサポートしていますが、実際にはチェックイン/チェックアウトシステムです。ファイルを編集すると、他の開発者にロックされていることがよくあります。それを回避する方法はいくつかありますが、システムは非常に複雑なので、常に問題が発生します。たとえば、開発者は、すべてのファイルに排他ロックを設定するソリューション全体をチェックアウトすることで、NTFSで読み取り専用に設定されているすべてのファイルを回避できることを発見しました。subversionのチェックアウトの構文は同じであり、ロックを取得しないため、これを数回行いました。
最後に、Team Explorer（クライアント）はなんと400 MBであり、TFSサーバーのインストールにはSharePointと2日が必要です。Subversionのワンクリックインストーラーは約30MBで、1分以内にサーバーがインストールされます。TFSには多くの機能がありますが、その基盤は非常に不安定であるため、それらを使用したり気にしたりすることはありません。TFSはライセンスの点で高価であり、開発者はコードを書く代わりにスタックオーバーフローで暴言を無駄にするでしょう：P
私のお勧めは、Team System はお金の価値がないということです。私は両方を使用しており、Team System を使用した後、同様の代替品を見つけようとしました。基本的にあなたが支払っているのは統合であり、カスタマイズのサポートについて議論することもできますが、少しの時間とツールを統合することで Team System の代替品を作成することができました.
私は最近、Team System の代替案を考え出すために他の人が何をしたかについて質問しました。また、代替品の作成に使用した開発ツールもリストします。うまくいけば、この回答と私が尋ねた質問で、あなたに合ったものを見つけることができます.
私は Team System が嫌いというわけではありません。これは非常に優れたツールであり、その代価を支払うことを厭わないのであれば、ぜひ使用してください。それが、私が思いついた代替品を作成した理由です。Team System が提供する機能が欲しかったのです。
これは、 Ankhsvnと呼ばれる VisualSVN のオープン ソース バージョンです。collabnet がそれを引き継いだので、はるかに良くなりました。
ソース管理だけが必要な場合、TFS はやり過ぎです。私の以前の雇用主の 1 つは、社内で TFS、VSS、および Subversion を使用していました。私たちの企業には Active Directory も Exchange Server 2003 もありませんでした。そのため、開発者が使用できるように TFS サーバー上に別のユーザーを作成することになりました。Ben Schierman が言及したのと同じ種類の問題がマージにあり、Subversion に移行する原因となった他のバグのある動作もありました。
TFS が適切かどうかは、予算、開発チームの規模、およびソリューションの構成/保守に利用できる時間と人員によって異なります。TFS が提供する追加の問題追跡、作業項目、およびプロジェクト統計機能が必要な場合は、他の代替手段を検討する価値があるかもしれません。JIRA (Atlassian Systems 製) や Trac などの製品は、Subversion とうまく統合され、プロジェクトまたはプログラム マネージャーが低価格で監視できるようなものを提供します。
Active Directory、Exchange Server 2003 以降、およびリポジトリ専用のスタッフがいる理想的な環境では、TFS が適している可能性が高くなります。
私は仕事と家庭の両方で使用しました。どちらもそれ自体が非常にクールです。ただし、TFSの使用をお勧めするのは、ソース管理だけでなく、より多くの機能を使用する場合のみです。必要なのがソース管理だけである場合、SVNを間違えることはできません。これが理由です。
VisualSVNサーバーこれは、それを管理するための優れたプラグインを備えた完全なSVNサーバーです。UIから直接Windows認証を使用できます。簡単。
亀その亀、十分に言った。
ankhsvnこれは素晴らしいSCCプラグインです。完全なVSIDE統合が必要な場合、最新バージョンは完全なSCCプラグインです。したがって、完全な統合を無料で利用できるようになりました。
上記の設定は100％無料で、ソース管理に必要なすべてを実行できます。
TFS はソース管理だけではありません。TFS が提供するパッケージ全体、バグ追跡、ビルド、レポートなどを使用する場合、TFS は非常に堅実な選択肢です (確かに Rational よりも優れています)。TFS は、Active Directory ともうまく統合されます。
ただし、SCM について話しているだけなら、SubVersion の方が好みです。私はIDE統合があまり好きではありません。また、Trunk/Tags/Branches 構造の SVN の規則と、ブランチ間の切り替えの比較的容易さも気に入っています。ただし、マージは TFS の方が簡単に見えました。ただし、特にレポへのファイルの追加に関しては、Tortoise の UI の方が TFS よりも優れています。
それは本当にあなたのニーズに依存すると思います。TFSは非常に優れており、私はこれを幅広く使用していますが、エンタープライズレベルを対象としています。これらの機能のすべてが必要でない場合は、必要ない場合があります。これらの機能（特に分岐、スケーラビリティ、作業項目の追跡など）が必要な場合は、1ペニーの価値があります。TFSには、バグトラッキング、作業項目のトラッキング、およびソース管理を超えたその他の機能が含まれていることに注意してください。複数のブランチがある場合、またはSubversionの機能の欠如などに苦労している場合は、切り替えることをお勧めします。ただし、切り替える正当な理由がなければ、ソース管理システムを切り替えることによるコストと生産性の低下を回避する必要があります。
私はSVNとTFSの両方を使用しました。TFS を使用する主な利点は、Visual Studio との緊密な統合です。バグ追跡、タスク追跡はすべて 1 か所にまとめられます。また、これらの項目について生成されたレポートは、利害関係者がプロジェクトのステータスを常に把握するのに役立ちます。
両方を広範囲に使用したことから、「TFS には、バグ追跡、作業項目追跡、およびソース管理を超えたその他の機能が含まれている」ことに注目して、Wedge はお金に見合っていたと思います。
ただし、SVN と TFS はスケーラビリティに関してかなり同等に見えます。SVN のソース管理は、その固有の単純さにより、TFS より優位に立っていると正直に言えます。
ソース管理と並行して作業項目とバグ追跡が必要な場合は、TFS を使用するか、SVN と、bugzilla などの他の無料のツールを使用します。TFS はソース管理と作業項目追跡の両方を統合していますが、MS は長年 VSS を使って非常に多くの開発者を悪用したことに対する謝罪として、TFS を無料で提供するべきだったと正直に思います。
TFS はプロジェクト管理と追跡には優れていますが、ソース管理は SVN ほど良くないと感じています。これが私のTFSのビーフです：
チェックイン・チェックアウトモデル
これは、TFS ソース管理にとって大きな欠点です。残念ながら、VS は、ユーザーが望まなくても、アイテムを自動的にチェックアウトします。私は、誰かがいくつかのファイルをチェックアウトしてから休暇を取ったという状況にありました。私はディレクトリ構造の再構築を担当していましたが、その人に大量のファイルがチェックアウトされていたため、できませんでした。GUI でチェックアウトを元に戻す方法はありません。つまり、コマンド ラインで 1 つずつ実行する必要がありました。または、このための強力なシェル スクリプトを作成する方法を見つけなければなりませんでした。
すべてを行うにはVSが必要です
ときどき、テキスト ファイルを編集してチェックインしたいことがあります。ファイルを編集してチェックインするためだけに、巨大な獣である VS 2010 を起動する必要があります。SVN では数秒かかったことが、今では 1 分で済みます.
他の人が指摘したように、ファイルがチェックアウトされていない場合、ファイルは読み取り専用としてマークされます。書き込み可能にして VS の外部で編集すると、TFS はこれを認識しません。これにより、VS の外部で何かを編集するのが煩わしくなります。これは、VS を起動し、ファイルをチェックアウトし、別のエディターで編集し、VS にチェックインすることを意味します。
SVN では簡単だったいくつかの操作が今では面倒です
まだ理解していないかもしれませんが、チェンジセットをロールバックするのは TFS では非常に面倒であることがわかりました。
ソリューションの一部ではないファイルをソース管理に追加するのは、非常に面倒です。TFSソース管理エクスプローラーは、ソース管理にあるファイルのみを表示し、そうでないファイルは表示しません（おそらく、どこかに設定があるかもしれませんが、わかりません）。Tortoise SVN を使用すると、フォルダで [コミット] を押して、追加するファイルを選択するだけで済みました。
私は現在、現在使用している Rational Suite に対して会社で TFS を評価する取り組みを主導しています。これまでのところ、TFS 2008 は clearcase + clearquest を実行しています。開発環境の統合は、それが本当に輝くところです。
また、TFS はサーバー ハードウェアからさらに多くの処理能力を必要とすることにも注意してください。もちろん、少なくとも 1 つの Windows サーバー ライセンス。
当社が従ったベスト プラクティスは、フロントエンド (共有ポイントが統合されている) とバックエンドの専用 SQL サーバー (エンタープライズ クラスターを使用) の 2 つのサーバーを使用することです。TFS は 1 台のマシンにインストールできますが、インストールしないでください。
比較すると、私たちの svn サーバーは 256 MB の RAM と 1 つの CPU を備えた仮想 Linux サーバーにインストールされており、checkout-all などの一般的なタスクを実行するときはさらに数倍高速です。仮想ハードウェアは、vshpere が割り当てることができる最低のものでした! ただし、ディスクは高速です (SAN)。
TFSには少なくとも5000ドルの専用ハードウェアが必要であり、svnサーバー（Linux上）は現在のWindowsベースのOSでは廃止された任意のハードウェアで実行できることをお勧めします.
私の10セント：
TFS2005 は冗談でした - インストールが難しく、維持するのはさらに困難でした. TFS2010 はエピックです! ・取り付けはイヌイースです。管理は非常に簡単です。それはすべてうまくレイアウトされたUIです。vs2008 でプロジェクトを作成できないため、vs2010 を使用する必要があるため、VS2008 との統合はそれほど簡単ではありません (これはばかげています)。TFS2010 では、TFS2008 のひどいサブフォルダーの代わりに、sharepoint プロジェクトの場所を変更することもできます。TFS2010 には、プロジェクト管理に非常に役立つバーンダウン チャートなどのツールもあります。TFS2010 は、クライアントを含む制作チーム全体のためのものです。それでもコストがかかりすぎます:(
私たちは、SVN から TFS2010 に移行中の小さなチームです。そうする最大の理由は、現在 TFS の一部となっているバグ追跡のための Visual Studio と WebAccess の統合です。
@Adam: より良い体験ができることを願っています。まだ言えない…
私の意見では、プロジェクトが行われる状況と環境に依存します。シンプルで小さなプロジェクトの場合は、SVN が最適です。すでに一部の人が書いているように、VisualSVN は Visual Studio st にうまく統合されており、ネイティブ ファイル システムでチェックイン/チェックアウトを行う必要はありません。
TFS はバージョン管理に優れていますが、そのすべての機能を実際に使用するとさらに優れたものになります。私の目には、たとえば、ワークアイテムを統合リポジトリとして使用して、顧客のバグレポート、新機能のリクエストを処理し、タスクとそれに応じた推定時間、使用時間、および時間を管理することでプロジェクトの進捗を追跡する場合に、本当に価値があります。残り時間表示。
また、非常に興味深いのは、作業項目をソース コード チェックインに関連付ける機能を使用することです。詳細については、こちらを参照してください。
私は過去 3 年間 SVN を使用しており (以前は VSS から来ていました)、最近 TFS2010 に切り替える必要がありました。全体的な感覚としては、SVN よりもバグが多く、タスク/バグとの統合が優れていることを除けば、SVN に対して優位性があるとは思えません。速度もSVNより若干遅いようです。
今ソース管理を選択する場合でも、SVN を使用します。
ツールに関して: - AnkhSVN Visual Studio Plugin は TFS ソース管理と同じくらい優れています - Tortoise は TFS の対応物よりもはるかに優れています
TFSは、開発者以外の人が必要ない場合は、午後のものを入手するのに最適です。
私たちのヘルプデスクはプロセスに関与する必要があり、それはそれをカットしていませんでした。
また、少なくともtfs 2005のビルド管理は面倒であり、2008slnと比較してビルドすることさえできません。ソース管理の選択がデプロイメントの選択に影響を与えることは本当に好きではありません。これが私のチームがsvnショップではない理由です。
ソース管理のみに基づいている場合は、SVN を使用します。Visual Studio 用の無料の AnkhSVN アドインは、新しいリリースで大幅に改善されました。また、SVN のソース コードも入手でき、ドキュメントも充実しています。彼らは TFS 2010 ソース管理で難解な部分を変更しました。ソース コードがないと、トラブルシューティングが非常に困難になる可能性があります。さらに、ドキュメントの作成は MSDN チームに依存しており、MSDN チームは独自のスケジュールと独自の深さでそれを行っています。
そうは言っても、TFS は明らかにソース管理以上のものを提供します。ALMツールです。それを作業項目、レポート、自動ビルド、ゲート チェックイン、自動テストなどと組み合わせることで、さまざまなツールを SVN に接続することによってのみ得られる非常に豊富な価値を提供できます。そしてもちろん、SVN のソースを持つことはフェイルセーフではありません。私は、何が起こっているのかを完全に理解するのにまだ数週間かかるという SVN のシナリオに入りました。
そのため、ALM の観点から見て、あなたの会社がすべての TFS 機能を使用する予定なのか、それとも最高の組み合わせの戦略 (JIRA など) を使用する予定なのかを確認することをお勧めします。
1マイルのTFS。
私は、SVNのファイルベースのアプローチで、うっかりしてあまりにも多くの問題を引き起こしました。経験したソース管理の問題：TFS –2年間で0の問題SVN–カウントが失われました...
はい、私はTFSの価格が、ほとんどの企業にとってそれを考慮に入れていることを知っています。これは非常に残念なことです。MSは、妥当な価格設定モデルがあれば、はるかに多くの市場シェア（および利益）を持つ可能性があります。