Frage SVN vs. Team Foundation Server [geschlossen]


Vor ein paar Monaten hat mein Team unsere Quellcodeverwaltung auf Apache Subversion von Visual SourceSafeund wir waren nicht glücklicher.

Kürzlich habe ich mich angeschaut Team Foundation Serverund zumindest auf der Oberfläche scheint es sehr beeindruckend. Es gibt eine großartige Integration mit Visual Studio und viele großartige Tools für DBAs, Tester, Projektmanager usw.

Der offensichtlichste Unterschied zwischen diesen beiden Produkten ist der Preis. Es ist schwer Apache Subversion (kostenlos) zu schlagen. Team Foundation Server ist ziemlich teuer, daher müssten die zusätzlichen Funktionen Subversion wirklich in die Hosen spielen.

  • Hat jemand praktische Erfahrung mit beiden?
  • Wie vergleichen sie?
  • Ist Team Foundation Server tatsächlich die Kosten wert?

75
2017-08-07 00:43


Ursprung


Antworten:


Ich bin kürzlich zu einem Open-Source-Projekt bei CodePlex gekommen. Sie benutzen TFS für ihre Quellcodeverwaltung und ich muss sagen, dass es absolut großartig ist. Ich bin unglaublich beeindruckt davon. Ich bin ein großer Fan der IDE-Integration und wie einfach es ist, Ihren Code zu verzweigen und zu markieren. Das Hinzufügen einer Lösung zur Quellcodeverwaltung ist etwa zwei Klicks, wenn Sie bereits alles richtig konfiguriert haben.

Jetzt. Ist es das saftige Preisschild wert? Ich denke nicht. Der Vorteil bei der Arbeit an Projekten bei CodePlex ist, dass ich die Erfahrung mit TFS, die ich brauche, für den Fall, dass ich es später irgendwo verwenden muss, bekomme. Wenn Sie eine gute IDE-Integration für Ihre Quellcodeverwaltung wünschen, greifen Sie nach VisuelleSVN Integrationspaket. Es ist eine viel, viel billigere Investition, um viele der gleichen Funktionen zu erhalten (kostenlos auf Nicht-Domänen-Computern BTW).


46
2017-08-07 00:52



Hier sind die größten Unterschiede zwischen den beiden für mich, und ich habe beide verwendet:

1) TFS ist ziemlich eng mit dem "Visual Studio-Weg" der Entwicklung verbunden.  Das heißt nicht, dass TFS eng mit der VS-IDE gekoppelt ist, was bedeutet, dass TFS Mühe hat, das vertraute "Einchecken" / "Auschecken" -Paradigma von Visual SourceSafe beizubehalten, selbst wenn es wirklich kein passendes Modell mehr ist. Subversions Konzept von "commit" / "update" ist viel realistischer, wenn Sie Entwickler haben, die ihre Zeit außerhalb des Netzwerks verbringen könnten. TFS erwartet, dass Entwickler immer mit dem Server verbunden sind. Das ist ein großes Minus. Ich persönlich finde TFS aufgrund der engen Integration von Visual Studio nicht so transparent, wie Dateien auf dem Server und auf Ihrer lokalen Festplatte organisiert sind. Selbst die größeren Befürworter von TFS räumen ein, dass das damit verbundene Check-in / Check-out-Modell keine überzeugende Option für Entwickler darstellt, die nicht mit dem System arbeiten. In einem Klima, in dem die Leute anfangen, DVCS-Optionen wie Git und Mercurial über SVN zu betrachten, erscheint das "Check-out" -Modell von TFS ein bisschen wie ein Dinosaurier.

2) Kosten.  Diejenigen, die sagen, dass TFS nicht teuer ist, sind entweder sehr kleine Läden oder entsprechen nicht den Lizenzbedingungen von TFS. Sie benötigen eine Clientzugriffslizenz für alle Ihre Aufgaben. Sind Sie ein Manager, der nur die Fehler verwaltet? Sie benötigen eine $ 250 CAL (Es gibt 5 mit einer Einzelhandels-TFS-Lizenz enthalten). Ein Business-Benutzer, der nur über seine Probleme berichten möchte? A $ 250 CAL. Ein Entwickler? $ 250 (Es sei denn, sie haben MSDN in diesem Fall ist es enthalten). Der Server? $ 500 (inklusive, wenn Sie MSDN haben). Natürlich wird Ihnen jemand, der Ihnen eine Kopie von TFS verkauft, mitteilen, dass das Tracking von Arbeitsaufgaben für zusätzliche Benutzer kostenlos ist, aber diese zusätzlichen Benutzer können nur die Arbeitselemente sehen, die sie selbst erstellen, und nicht die gesamten Arbeitselemente des Teams zu nützlich in einer teamorientierten, agilen Umgebung. All dies summiert sich, wenn Sie eine mittelgroße Organisation haben, und wird schwer zu rechtfertigen, wenn so viele der besten Produkte wie SVN und CruiseControl.net inkrementelle Kosten $ 0 sind. (In Fairness gegenüber TFS warte ich immer noch auf eine Ja wirklich guter OSS-Problemverfolger)

3) Projektstruktur  In großen Teams mit einer kleineren Anzahl von Projekten wird TFS wahrscheinlich gut funktionieren. Wenn Sie eine Reihe kleiner, unverbundener oder lose verbundener Geschäftsanwendungen im eigenen Haus haben, kann die Struktur von TFS zu übertrieben werden. Zum einen ist es nicht möglich, eine Taxonomie von Projekten selbst zu definieren - Sie können "Bereiche" innerhalb eines Projekts einrichten, aber alle Probleme und Dokumente werden zusammen im Basiskontext eines "Projekts" verfolgt. Das Erstellen neuer "Projekte" ist oft zeitaufwendig und für kleine Anstrengungen übertrieben. Natürlich hat SVN nichts davon, da es sich nur auf die Quellcodeverwaltung konzentriert, aber wenn Sie eine gute Flexibilität für kleine Projekte benötigen, ist SVN und ein anderes Tool zur Fehlerverfolgung möglicherweise die bessere Wahl.

Meine Meinung, für was es wert ist:

  • Für große Teams mit großen, budgetgerechten Projekten, in einem Microsoft-Shop, in dem Entwickler fast ausschließlich innerhalb der IDE arbeiten, ist TFS der Gewinner. TFS gewinnt auch, wenn Sie Richtlinien für Ihre Projekte zentral durchsetzen müssen.

  • Für eine Reihe von kleinen Teams mit vielen verschiedenen, kleineren Projekten oder Geschäften, bei denen Kosten ein Problem darstellen, oder bei Teams, deren Entwickler nicht mit der Quellcodeverwaltung arbeiten, sollten Sie SVN verwenden.


87
2017-10-25 14:33



Ich bin überrascht, dass jemand, der in der Vergangenheit Subversion benutzt hat, sogar einen Bedarf an TFS-Quellcode haben könnte.

Meine Erfahrung mit TFS (2005) war ziemlich schrecklich. Ich habe alle Arten von Whitepapers und Anleitungen gelesen, wie Sie Ihre Quelle für verschiedene Entwicklungsanforderungen richtig strukturieren können.

Unsere einfache Situation, in der wir einen Stamm mit Mainline-Entwicklung haben, und den Integrationszweig, in den wir Änderungen und Deployes integrieren, und ein Release-Zweig, um frühere Releases zu verfolgen, ist sehr üblich und unkompliziert, aber wir stoßen ständig auf Probleme.

Meine Hauptprobleme mit TFS:

  • Zusammenführen ist ein SCHMERZ im Vergleich zu Subversion.
  • Es gibt nicht behobene Fehler. Ich stieß auf eine über Umbenennung / Zusammenführung, die seit 2 Jahren bekannt ist und eine Korrektur wird nie für 2005 veröffentlicht werden. Wir endeten schließlich unseren Zweig in einen "defekten" Ordner und wir ignorieren es jetzt.
  • Wenn Sie Ihre Dateien schreibgeschützt sperren, entsteht Reibung. Wer sagt, dass ich Batchdateien bearbeiten und Skripte in TFS erstellen muss, damit es für mich "ausgecheckt" wird? Subversion weiß es welche Dateien sich geändert haben. Es gibt keine schreibgeschützten Schlösser.
  • Geschwindigkeit. TFS ist langsam über ein WAN, und es ist wirklich nur brauchbar, wenn ich in meinen Arbeitscomputer einspache, was meine Entwicklungserfahrung insgesamt sehr langsam macht.
  • Mangel an guter Kommandozeilen- und Explorer-Integration. IDE-Integration ist wirklich nett für die täglichen Get-Latest, Hinzufügen von Dateien und Einchecken, aber wenn Sie Dinge in vielen Projekten tun müssen, ist es schön, gute Tools zu Ihrer Verfügung zu haben. Und bevor jemand mir die Kehle herunterspringt und behauptet, tf.exe funktioniert gut ... es ist nicht wirklich ein cmd line tool. Zum Beispiel sollte beim Einchecken von Code kein modaler Dialog angezeigt werden.

...Die Liste geht weiter. Ich denke, sogar mit der ganzen Integration gibt es kostenlose Alternativen, die weit überlegen sind.


48
2017-08-29 20:19



Wir sind ein VS.NET-Shop und haben Folgendes implementiert:

  1. Bugzilla zur Fehlerverfolgung
  2. Apache Subversion als Quellcode-Repository-Back-End
  3. VisualSVN-Server zum Verwalten von SVN auf dem Server
  4. SchildkröteSVN (im Windows Explorer) und AhnkSVN oder VisuelleSVN (in Visual Studio) auf dem Client
  5. CruiseControl.NET für automatisierte Builds

Kosten: 0 € Vorteile: unbezahlbar

Wenn Sie ein kleines Team sind oder nicht bereit sind, in den TFS-Prozess zu investieren, sind SVN und Open Source-Tools der richtige Weg.


42
2017-08-14 21:11



Wie andere darauf hingewiesen haben, bietet TFS viel mehr Funktionen als SVN in Form von Projektmanagement und so. Nachdem ich beide benutzt habe und mit sehr großen Firmen bei der Implementierung von TFS gearbeitet habe, hier sind meine zwei Cent.

1) Wenn Sie TFS 2005 verwenden, führen Sie ein Upgrade auf TFS 2008 durch. Sie werden mir danken. Es gibt eine Menge Verbesserungen in TFS 2008, die es machbar machen.

2) Wenn Sie in Visual Studio leben und die IDE-Integration wünschen, gehen Sie mit TFS. Ich habe SVN-Integration verwendet und fast immer wieder auf TortoiseSVN zurückgreifen.

3) Wenn Sie möchten, dass Konten mit der Windows-Authentifizierung integriert werden, verwenden Sie TFS. Die Verwaltbarkeit von diesem Ende ist nett. Es kann Haken für SVN geben - ich bin nicht positiv, aber wenn Sie die GUI-gesteuerte Verwaltung mögen, ist TFS schwer zu schlagen.

4) Wenn Sie Metriken verfolgen oder einfachere Methoden wie Check-in-Richtlinien implementieren möchten, gehen Sie mit TFS.

5) Wenn Sie Leute haben, die es nicht implementieren, wenn es nicht MSFT ist, gehen Sie mit TFS.

6) Wenn Sie mehr als nur .NET (Java-Arbeit, Eclipse, etc.) tun, gehen Sie mit SVN. Ja, es gibt sehr gute Produkte (wie Teamprise), die gut mit TFS funktionieren. Aber wenn die anderen Sprachen nicht ein kleiner Teil Ihres Shops sind, bleiben Sie einfach bei SVN.

Abgesehen davon sind die SCM-Merkmale von beiden ungefähr gleichwertig. Sie verzweigen und verschmelzen beide, die beiden tun atomare Check-Ins, beide unterstützen Umbenennungen und Bewegungen. Ich denke, für Leute, die gerade mit dem Verzweigungs- und Zusammenführungskonzept beginnen, ist es schön, die Zweige im Source Control Explorer sichtbar zu haben.

TFS ist wirklich nicht so teuer ($ 1200 vielleicht?). Im Vergleich zu SVN ist es vielleicht. Die Integration in Reporting Services und SharePoint ist nett, aber wenn Sie das nicht verwenden, spielt es keine Rolle.

Was ich sagen würde ist, die 180-Tage-Testversion von TFS herunterzuladen und es auszuprobieren. Führen Sie eine Testversion nebeneinander aus. Ich denke, du wirst glücklich sein, egal wie du gehst.


23
2017-09-07 14:00



Wie Ubiguchi darauf hinweist, ist TFS kein Produkt zur Versionskontrolle. Der Kauf von TFS mit der Absicht, es nur für die Versionskontrolle zu verwenden, wäre eindeutig eine Verschwendung von Geld. TFS ist eine integrierte Suite von Tools zur Automatisierung aller Aspekte des Application Lifecycle Managements (und weitgehend auf "The Enterprise" ausgerichtet).

Auch per Post von Ben S - ich verstehe deinen Kommentar zu Schlössern nicht. Sperren sind in TFS überhaupt nicht erforderlich. Administratoren können TFS so konfigurieren, dass es wie VSS funktioniert (Funktionen, die von einigen "unklugen" Kunden verlangt werden), um "Get-Latest on Checkout" zu erhalten, was meiner Meinung nach auch eine Checkout-Sperre darstellt.

Aber durch die "normale" Verwendung von TFS fordert ein "Auschecken" einen Benutzer zum Sperrtyp auf - und der Standardwert sollte "keine" sein. Ein Benutzer kann einen Check-Out (oder eine Check-In-Sperre) auswählen, ist aber nicht erforderlich. Wenn Sie keine Sperren wünschen, verwenden Sie sie nicht.

TFS verfolgt, welche Benutzer Check-Outs auf dem Server haben, aus verschiedenen Leistungsgründen (make Get-neuesten schneller) und Projektmanagement (Ich sehe gerne, was Entwickler Dateien ausgecheckt haben und wie lange ihre Check-outs sind).

Ich bin nicht wirklich vertraut mit SVN (ich habe es nie benutzt) - so kann ich nicht sagen, dass "Zusammenführen ist schlimmer mit TFS" - und nicht den Zusammenführungsfehler Ben S gemeldet hat - aber ich hatte großartig Erfolg beim Verzweigen und Zusammenführen mit TFS.

Ein Anwendungsfall, von dem ich weiß, dass TFS immer noch ziemlich schwach ist, ist für Benutzer, die regelmäßig "offline" sind. TFS ist ein "Server-Produkt", das davon ausgeht, dass die Benutzer die meiste Zeit verbunden sind. Die Offline-Erfahrung verbesserte sich im Jahr 2008 (es war im Jahr 2005 düster), aber es ist noch ein weiter Weg. Wenn Sie Entwickler haben, die oft für längere Zeit vom Netzwerk getrennt werden müssen (oder wollen) - Sie sind wahrscheinlich besser dran mit SVN.

Eine weitere zu berücksichtigende Funktion für SVN-Fans, die TFS verwenden, ist die SVN-Brücke ein Codeplex, mit dem Benutzer TortiseSVN für die Verbindung mit TFS verwenden können. Ich bin ein guter Freund und Kollege von mir nutzt es ausgiebig und liebt es.

Auch der Kommentar über eine fehlende Befehlszeile überrascht mich - die Befehlszeilenwerkzeuge sind umfangreich (obwohl viele einen separaten Download von benötigen) TFS-Elektrowerkzeuge

Ich vermute, Bens Kommentare basieren auf einem Testbericht von 2005, der eindeutig ein "Microsoft V1.0" -Produkt war. Das Produkt ist derzeit in 2.1 mit Version 3 in naher Zukunft.


16
2017-09-07 13:31



TFS ist abscheulich. An dieser Stelle kontrolliere ich die Version lokal mit SVN (mit Live Mesh für Backups), weil ich einige Probleme mit TFS habe. Das Hauptproblem ist, dass TFS Zeitstempel verwendet, um aufzuzeichnen, ob Sie die neueste Version haben, und diese Zeitstempel auf dem Server speichert. Sie können Ihre lokale Kopie löschen, die neueste Version von TFS erhalten und alle Dateien auf dem neuesten Stand halten. Es ist ein albernes System, das Ihnen keine Garantie gibt, dass Sie die richtige Version der Dateien haben. Dies führt zu zahlreichen Ärgernissen:

  • TFS muss informiert werden, wenn eine Datei bearbeitet wird. Daher müssen Sie immer mit dem Server verbunden sein.
  • TFS wird verwirrt, wenn Sie Dateien außerhalb der IDE bearbeiten. Außerdem werden alle Dateien in NTFS schreibgeschützt.

Während TFS das Zusammenführen unterstützt, ist es wirklich ein Checkin / Checkout-System. Wenn Sie eine Datei bearbeiten, werden Sie oft feststellen, dass sie für andere Entwickler gesperrt ist. Es gibt Möglichkeiten, aber das System ist so verworren, dass Sie immer auf das Problem stoßen. Unsere Entwickler haben beispielsweise festgestellt, dass sie alle Dateien, die nur in NTFS gelesen werden sollen, umgehen können, indem sie eine ganze Lösung auschecken, die eine exklusive Sperre für alle Dateien festlegt. Ich habe das ein paar Mal gemacht, weil Subversion dieselbe Syntax für das Auschecken hat, die keine Sperre erhält.

Schließlich Team Explorer (der Client) ist eine kolossale 400 MB, TFS-Server benötigt SharePoint und zwei Tage zu installieren. Das Subversion-Ein-Klick-Installationsprogramm ist ungefähr 30 MB groß und installiert den Server für Sie in weniger als einer Minute. TFS hat viele Funktionen, aber seine Grundlage ist so wackelig, dass Sie sie nie benutzen oder sich um sie kümmern. TFS ist teuer in Bezug auf die Lizenz, und in der Zeit verschwenden Entwickler Verschwendung von Stackoverflow, anstatt Code zu schreiben: P


10
2017-08-14 21:02



Meine Empfehlung, Team System ist das Geld nicht wert. Ich habe beide verwendet und nach der Verwendung von Team System habe ich versucht, einen ähnlichen Ersatz zu finden. Im Grunde ist es die Integration, für die Sie bezahlen, und Sie könnten die Unterstützung für die Anpassung argumentieren, aber ich war in der Lage, einen Team-System-Ersatz mit ein wenig Zeit zu schaffen und Werkzeuge zusammen zu integrieren.

Ich habe neulich hat eine Frage gestellt darüber, was andere getan haben, um eine Team-System-Alternative zu entwickeln. Ich liste auch die Entwicklungstools auf, mit denen ich den Ersatz erstellt habe. Hoffentlich können Sie mit dieser Antwort und der Frage, die ich gestellt habe, herausfinden, was für Sie funktioniert.

Ich bin kein Team System Hasser, ich denke nur nicht, dass es das Geld wert ist. Es ist ein sehr nettes Werkzeug und wenn es Ihnen nichts ausmacht, den Preis dafür zu zahlen, dann benutzen Sie es auf jeden Fall. Es war der ganze Grund, warum ich den Ersatz kreierte, den ich mir ausgedacht hatte. Ich wollte die Funktionalität Team System zur Verfügung stellen.


8
2017-08-17 02:30



Hier ist eine Open-Source-Version von VisualSVN aufgerufen Ankhsvn. Es ist jetzt viel besser, dass Collabnet es übernommen hat.


8
2017-08-29 20:51



Wenn Sie nur die Quellcodeverwaltung benötigen, ist TFS Overkill. Einer meiner früheren Arbeitgeber hatte TFS, VSS und Subversion in ihrem Unternehmen. Wir hatten in unserem Unternehmen kein Active Directory oder Exchange Server 2003. Daher erstellten wir am TFS-Server separate Benutzer, damit Entwickler sie verwenden konnten. Wir hatten die gleichen Probleme mit der Verschmelzung, die Ben Schierman erwähnt hat, zusammen mit anderen Buggy-Verhaltensweisen, die uns zu Subversion getrieben haben.

Ob TFS der richtige Anruf für Sie ist, hängt zum Teil von Ihrem Budget, der Größe Ihres Entwicklungsteams und dem Zeit- und Personalaufwand für die Konfiguration / Wartung Ihrer Lösung ab. Wenn Sie die zusätzlichen Funktionen zur Fehlerverfolgung, Arbeitsaufgabe und Projektstatistik, die TFS bietet, haben möchten, lohnt es sich möglicherweise, sich andere Alternativen anzusehen. Produkte wie JIRA (von Atlassian Systems) oder Trac lassen sich gut in Subversion integrieren und bieten die Art von Kontrolle, die ein Projekt- oder Programmmanager möglicherweise zu einem niedrigeren Preis erhält.

In einer idealen Umgebung mit Active Directory, Exchange Server 2003 oder höher und engagierten Mitarbeitern für das Repository ist TFS mit größerer Wahrscheinlichkeit eine gute Wahl.


7
2017-09-08 18:35