SVN vs. Team Foundation Server [geschlossen]

Vor ein paar Monaten hat mein Team unsere Quellcodeverwaltung von Visual SourceSafe auf Apache Subversion umgestellt , und wir waren nicht zufriedener.

Vor kurzem habe ich mir Team Foundation Server angesehen , und zumindest an der Oberfläche scheint es sehr beeindruckend zu sein. Es gibt eine großartige Integration in Visual Studio und viele großartige Tools für Datenbankadministratoren, 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 Hose machen.

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

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

Jetzt. Lohnt sich der hohe Preis? Das glaube ich nicht. Der Vorteil der Arbeit an Projekten bei CodePlex besteht darin, dass ich die Erfahrung mit TFS sammeln kann, die ich benötige, falls ich sie später irgendwo verwenden muss. Wenn Sie eine gute IDE-Integration für Ihre Quellcodeverwaltung wünschen, greifen Sie zum VisualSVN- Integrationspaket. Es ist eine viel, viel billigere Investition, viele der gleichen Funktionen zu erhalten (übrigens kostenlos auf Nicht-Domain-Computern).

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

1) TFS ist ziemlich eng mit der "Visual Studio-Methode" der Entwicklung verbunden. Das heißt nicht, dass TFS eng mit der VS-IDE verbunden ist, sondern dass TFS Schwierigkeiten hat, das bekannte Paradigma "Einchecken" / "Auschecken" von Visual SourceSafe beizubehalten, auch wenn es wirklich kein geeignetes Modell mehr ist. Das Konzept von Subversion "Commit" / "Update" ist viel realistischer, wenn Sie Entwickler haben, die möglicherweise Zeit damit verbringen, vom Netzwerk getrennt zu sein. TFS erwartet, dass Entwickler immer mit dem Server verbunden sind. Das ist ein großes Minus. Ich persönlich finde TFS aufgrund der engen Visual Studio-Integration weniger transparent darüber, 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 verbundene Check-in / Check-out-Modell für Entwickler, die nicht verbunden arbeiten, keine überzeugende Option ist.

2) Kosten. Diejenigen, die sagen, dass TFS nicht teuer ist, sind entweder sehr kleine Geschäfte oder entsprechen nicht den Lizenzbestimmungen von TFS. Sie benötigen eine Clientzugriffslizenz für fast alles, was Sie tun. Sind Sie ein Manager, der nur die Fehler verwaltet? Sie benötigen eine CAL von ca. 250 USD (in einer TFS-Einzelhandelslizenz sind 5 enthalten). Ein Geschäftsbenutzer, 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 Kellner? $ 500 (inklusive, wenn Sie MSDN haben). Natürlich wird Ihnen jemand, der Ihnen eine Kopie von TFS verkauft, mitteilen, dass die Nachverfolgung von Arbeitselementen für zusätzliche Benutzer kostenlos ist. Diese zusätzlichen Benutzer können jedoch nur die von ihnen selbst erstellten Arbeitselemente sehen und nicht die Arbeitselemente des gesamten Teams, was nicht der Fall ist zu nützlich in einer teamorientierten, agilen Umgebung. All dies summiert sich, wenn Sie ein mittelständisches Unternehmen haben, und ist schwer zu rechtfertigen, wenn so viele erstklassige Produkte wie SVN und CruiseControl.net zusätzliche Kosten in Höhe von 0 US-Dollar verursachen. (Um TFS gerecht zu werden, warte ich immer noch auf einewirklich guter OSS Issue Tracker)

3) Projektstruktur. In großen Teams mit einer geringeren Anzahl von Projekten wird TFS wahrscheinlich gut funktionieren. Wenn Sie eine Reihe kleiner, nicht verbundener oder lose verbundener Branchen-Apps im eigenen Unternehmen haben, kann die Struktur von TFS überheblich 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 im Grundkontext eines "Projekts" zusammen verfolgt. Das Erstellen neuer "Projekte" ist oft zeitaufwändig und für kleine Anstrengungen zu viel des Guten. Natürlich hat SVN nichts dergleichen, da es sich nur auf die Quellcodeverwaltung konzentriert. Wenn Sie jedoch eine gute Flexibilität für kleine Projekte benötigen, sind SVN und ein anderes Tool zur Problemverfolgung möglicherweise die bessere Wahl.

Meine Meinung, für was es wert ist:

• Für große Teams mit großen, gut budgetierten 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 kleiner Teams mit vielen verschiedenen, kleineren Projekten oder Geschäften, in denen die Kosten eine Rolle spielen, oder für Teams, deren Entwickler von der Quellcodeverwaltung getrennt arbeiten, entscheiden Sie sich für SVN.

Ich bin überrascht, dass jemand, der Subversion in der Vergangenheit verwendet hat, sogar eine TFS-Quellcodeverwaltung haben möchte / muss.

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 Trunk mit Mainline-Entwicklung und einen Integrationszweig haben, in dem wir Änderungen integrieren und bereitstellen, sowie einen Release-Zweig, um frühere Releases zu verfolgen, ist sehr häufig und unkompliziert, aber wir stoßen ständig auf Probleme.

Meine Hauptprobleme mit TFS:

• Das Zusammenführen ist ein Schmerz im Vergleich zur Subversion.
• Es gibt nicht behobene Fehler. Ich bin auf einen Artikel über das Umbenennen / Zusammenführen gestoßen, der seit 2 Jahren bekannt ist, und ein Fix wird für 2005 nie veröffentlicht. Am Ende haben wir unseren Zweig in einen "kaputten" Ordner verschoben und ignorieren ihn jetzt.
• Das Setzen von schreibgeschützten Sperren für Ihre Dateien ist reibungslos. Wer sagt, dass ich Batch-Dateien bearbeiten und Skripte in TFS erstellen muss, damit es für mich "ausgecheckt" wird? Subversion weiß, welche Dateien geändert wurden. Es gibt dort keine schreibgeschützten Sperren.
• Geschwindigkeit. TFS ist über ein WAN sehr langsam und kann nur verwendet werden, wenn ich ein VPN in meinen Arbeitscomputer einbinde, was meine Entwicklererfahrung insgesamt sehr langsam macht.
• Mangel an guter Kommandozeilen- und Explorer-Integration. Die IDE-Integration ist sehr hilfreich für das tägliche Get-Latest, das Hinzufügen von Dateien und das Einchecken. Wenn Sie jedoch in vielen Projekten Aufgaben ausführen müssen, ist es hilfreich, über gute Tools zu verfügen. Und bevor mir jemand in die Kehle springt und behauptet, dass tf.exe gut funktioniert ... ist es nicht wirklich ein cmd-Linienwerkzeug. Zum Beispiel sollte beim Einchecken von Code kein modaler Dialog angezeigt werden.

...Die Liste geht weiter. Ich denke, trotz der gesamten Integration gibt es kostenlose Alternativen, die weit überlegen sind.

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

1. Bugzilla zur Problemverfolgung
2. Apache Subversion als Quellcode-Repository-Backend
3. VisualSVN-Server zum Verwalten von SVN auf dem Server
4. TortoiseSVN (im Windows Explorer) und AhnkSVN oder VisualSVN (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, sich in den who TFS-Prozess einzukaufen, sind SVN- und Open Source-Tools der richtige Weg.

Wie andere bereits betont haben, bietet TFS Ihnen viel mehr Funktionen als SVN in Form von Projektmanagement und dergleichen. Nachdem ich beide verwendet und mit sehr großen Unternehmen bei der Implementierung von TFS zusammengearbeitet habe, sind hier meine zwei Cent.

1) Wenn Sie TFS 2005 verwenden, aktualisieren Sie auf TFS 2008. Sie werden mir danken. Es gibt eine Menge Verbesserungen in TFS 2008, die es funktionsfähig machen.

2) Wenn Sie in Visual Studio leben und die IDE-Integration wünschen, wählen Sie TFS. Ich habe die SVN-Integration verwendet und fast immer wieder TortoiseSVN verwendet.

3) Wenn Sie die Idee mögen, Konten in die Windows-Authentifizierung zu integrieren, wählen Sie TFS. Die Handhabbarkeit von diesem Ende ist schön. Es mag Haken für SVN geben - ich bin nicht sicher, aber wenn Sie das GUI-gesteuerte Management mögen, ist TFS schwer zu schlagen.

4) Wenn Sie Metriken verfolgen müssen oder einfachere Möglichkeiten zum Implementieren von Check-in-Richtlinien haben, entscheiden Sie sich für TFS.

5) Wenn Sie Leute haben, die es nicht implementieren, wenn es nicht MSFT ist, wählen Sie TFS.

6) Wenn Sie mehr als nur .NET (Java-Arbeit, Eclipse usw.) ausführen, entscheiden Sie sich für SVN. Ja, es gibt sehr gute Produkte (wie Teamprise), die gut mit TFS zusammenarbeiten. Aber wenn die anderen Sprachen nicht ein kleiner Teil Ihres Shops sind, bleiben Sie einfach bei SVN.

Abgesehen davon sind die SCM-Funktionen beider ungefähr gleichwertig. Beide führen Verzweigungen und Zusammenführungen durch, beide führen atomare Check-Ins durch, beide unterstützen Umbenennungen und Verschiebungen. Ich denke, für Leute, die gerade erst mit dem Verzweigungs- und Zusammenführungskonzept beginnen, ist es schön, wenn die Verzweigungen im Versionsverwaltungs-Explorer sichtbar sind.

TFS ist wirklich nicht so teuer (1200 Dollar 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 auszuprobieren. Führen Sie eine Testversion nebeneinander aus. Ich denke, Sie werden glücklich sein, egal welchen Weg Sie gehen.

Wie Ubiguchi betont, 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 Geldverschwendung. TFS ist eine integrierte Suite von Tools zur Automatisierung aller Aspekte des Application Lifecycle Management (und weitgehend auf "The Enterprise" ausgerichtet).

Auch per Beitrag von Ben S - Ich verstehe Ihren Kommentar zu Sperren nicht. Sperren sind in TFS überhaupt nicht erforderlich. Administratoren können TFS so konfigurieren, dass es wie VSS (von einigen "unklugen" Kunden geforderte Funktionen) für "Get-Latest on Checkout" funktioniert, was meiner Meinung nach auch eine Check-out-Sperre bewirkt.

Durch "normale" Verwendung von TFS fordert ein "Auschecken" einen Benutzer zur Eingabe des Sperrtyps auf - und die Standardeinstellung sollte "keine" sein. Ein Benutzer KANN einen Check-out (oder eine Check-in-Sperre) auswählen - dies ist jedoch nicht erforderlich. Wenn Sie keine Schlösser möchten, verwenden Sie diese nicht.

TFS verfolgt aus verschiedenen Gründen der Leistung (schnellere Aktualisierung) und des Projektmanagements (ich möchte sehen, welche Entwickler Dateien ausgecheckt haben und wie lange ihre Auscheckvorgänge dauern), welche Benutzer auf dem Server auschecken.

Ich bin mit SVN nicht wirklich vertraut (ich habe es nie verwendet) - daher kann ich nicht sagen, dass "Zusammenführen mit TFS schlechter ist" - und habe den von Ben S gemeldeten Zusammenführungsfehler nicht getroffen - aber ich hatte großartige Ergebnisse Erfolg beim Verzweigen und Zusammenführen mit TFS.

Ein Anwendungsfall, von dem ich weiß, dass TFS immer noch ziemlich schwach ist, betrifft Benutzer, die regelmäßig "offline" sind. TFS ist ein "Serverprodukt", bei dem davon ausgegangen wird, dass die Benutzer die meiste Zeit verbunden sind. Die Offline-Erfahrung hat sich in der Version 2008 verbessert (sie war 2005 düster), hat aber noch einen langen Weg vor sich. Wenn Sie Entwickler haben, die häufig für längere Zeit vom Netzwerk getrennt werden müssen (oder möchten), sind Sie mit SVN wahrscheinlich besser dran.

Eine weitere Funktion für SVN-Fans, die TFS verwenden, ist die SVN Bridge, ein Codeplex, mit dem Benutzer TortiseSVN verwenden können, um eine Verbindung zu TFS herzustellen. Ich, ein guter Freund und Kollege von mir, benutze es ausgiebig und liebe es.

Auch der Kommentar zu einem Mangel an Befehlszeile überrascht mich - die Befehlszeilentools sind umfangreich (obwohl viele einen separaten Download von TFS Power Tools erfordern

Ich vermute, Bens Kommentare basieren auf einer Bewertung der Version 2005, bei der es sich eindeutig um ein "Microsoft V1.0" -Produkt handelte. Das Produkt ist derzeit in 2.1 mit Version 3 in naher Zukunft.

TFS ist abscheulich. Zu diesem Zeitpunkt kontrolliere ich die Version lokal mithilfe von SVN (mit Live Mesh für Backups), da ich einige Probleme mit TFS habe. Das Hauptproblem ist, dass TFS Zeitstempel verwendet, um aufzuzeichnen, ob Sie über die neueste Version verfügen, und diese Zeitstempel auf dem Server speichert. Sie können Ihre lokale Kopie löschen, die neuesten Informationen von TFS erhalten und alle Dateien sind auf dem neuesten Stand. Es ist ein dummes System, das Ihnen keine Garantie dafür gibt, dass Sie die richtige Version von Dateien haben. Dies führt zu zahlreichen Belästigungen:

• TFS muss informiert werden, wenn eine Datei bearbeitet wird, sodass Sie jederzeit mit dem Server verbunden sein müssen.
• 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 Check-In / Check-Out-System. Wenn Sie eine Datei bearbeiten, werden Sie häufig feststellen, dass sie für andere Entwickler gesperrt ist. Es gibt Möglichkeiten, dies zu umgehen, aber das System ist so kompliziert, dass Sie immer auf das Problem stoßen. Zum Beispiel haben unsere Entwickler festgestellt, dass sie alle Dateien umgehen können, die in NTFS schreibgeschützt sind, indem sie eine gesamte Lösung auschecken, die eine exklusive Sperre für alle Dateien festlegt. Ich habe dies einige Male getan, weil Subversion dieselbe Syntax für das Auschecken hat, wodurch keine Sperre erhalten wird.

Schließlich ist Team Explorer (der Client) satte 400 MB groß. Für die Installation des TFS-Servers sind SharePoint und zwei Tage erforderlich. Das Subversion-One-Click-Installationsprogramm ist ungefähr 30 MB groß und installiert den Server in weniger als einer Minute für Sie. TFS hat viele Funktionen, aber seine Grundlage ist so wackelig, dass Sie sie niemals verwenden oder sich darum kümmern werden. TFS ist in Bezug auf die Lizenz teuer, und in der Zeit werden Entwickler das Stanting über den Stackoverflow verschwenden, anstatt Code zu schreiben: P.

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. Grundsätzlich zahlen Sie für die Integration und Sie könnten die Anpassungsunterstützung argumentieren, aber ich konnte mit ein wenig Zeit einen Team-System-Ersatz erstellen und Tools zusammen integrieren.

Ich habe kürzlich eine Frage gestellt, was andere getan haben, um eine Team-System-Alternative zu finden. 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 glaube einfach nicht, dass es das Geld wert ist. Es ist ein sehr schönes Werkzeug, und wenn es Ihnen nichts ausmacht, den Preis dafür zu zahlen, dann verwenden Sie es auf jeden Fall. Es war der ganze Grund, warum ich den Ersatz geschaffen habe, den ich mir ausgedacht habe. Ich wollte die Funktionalität von Team System.

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

Wenn Sie nur die Quellcodeverwaltung benötigen, ist TFS ein Overkill. Einer meiner früheren Arbeitgeber hatte TFS, VSS und Subversion in seinem Unternehmen. Wir hatten kein Active Directory oder Exchange Server 2003 in unserem Unternehmen, daher haben wir separate Benutzer auf dem TFS-Server erstellt, damit Entwickler es verwenden können. Wir hatten die gleichen Probleme beim Zusammenführen, die Ben Schierman erwähnte, zusammen mit anderen fehlerhaften Verhaltensweisen, die uns in Richtung Subversion trieben.

Ob TFS der richtige Anruf für Sie ist, hängt zum Teil von Ihrem Budget, der Größe Ihres Entwicklungsteams und der Zeit und dem Personal ab, die für die Konfiguration / Wartung Ihrer Lösung zur Verfügung stehen. Wenn Sie die zusätzlichen Funktionen für Problemverfolgung, Arbeitselemente und Projektstatistik von TFS nutzen möchten, lohnt es sich möglicherweise, nach anderen Alternativen zu suchen. 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 zu einem niedrigeren Preis haben könnte.

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

Ich habe sowohl bei der Arbeit als auch zu Hause verwendet. Sie sind beide sehr cool für sich. Das einzige Mal, dass ich die Verwendung von TFS empfehlen würde, ist, wenn Sie mehr Funktionen als nur die Quellcodeverwaltung verwenden. Wenn Sie nur die Quellcodeverwaltung benötigen, können Sie mit SVN nichts falsch machen, und deshalb.

1. VisualSVN-Server Dies ist ein vollständiger SVN-Server mit einem netten Plugin, mit dem Sie ihn verwalten können. Sie können die Windows-Authentifizierung direkt über die Benutzeroberfläche verwenden. Einfach.

2. Schildkröte Seine Schildkröte, sagte genug.

3. ankhsvn Es ist ein großartiges SCC-Plugin. Für diejenigen, die eine vollständige VS IDE-Integration wünschen, ist die neueste Version ein vollständiges SCC-Plugin. So erhalten Sie jetzt die vollständige Integration kostenlos.

Das oben beschriebene Setup ist 100% kostenlos und führt Sie durch alles, was Sie für die Quellcodeverwaltung benötigen.

Bei TFS geht es nicht nur um Quellcodeverwaltung. Wenn Sie das gesamte von TFS angebotene Paket, Fehlerverfolgung, Builds, Berichte usw. verwenden, ist TFS eine ziemlich solide Wahl (sicherlich besser als Rational). TFS lässt sich auch gut in Active Directory integrieren.

Wenn Sie nur über SCM sprechen, bevorzuge ich SubVersion. Ich mag die IDE-Integration nicht wirklich. Ich mag auch die SVN-Konvention der Trunk / Tags / Branches-Struktur und die relativ einfache Umschaltung zwischen Zweigen. Das Zusammenführen schien in TFS jedoch einfacher zu sein. Die Benutzeroberfläche von Tortoise schlägt TFS zweifellos, insbesondere was das Hinzufügen einer Datei zu einem Repo betrifft.

Ich würde sagen, es hängt wirklich von Ihren Bedürfnissen ab. TFS ist sehr schön, ich habe es ausgiebig genutzt, aber es richtet sich vor allem an Unternehmen. Wenn Sie nicht alle diese Funktionen benötigen, ist es möglicherweise nicht erforderlich. Wenn Sie diese Funktionen benötigen (insbesondere Verzweigung, Skalierbarkeit, Nachverfolgung von Arbeitselementen usw.), sind sie jeden Cent wert. Beachten Sie, dass TFS Fehlerverfolgung, Workitem-Verfolgung und andere Funktionen umfasst, die über die Quellcodeverwaltung hinausgehen. Wenn Sie mehrere Zweige haben oder Probleme mit dem Mangel an Funktionen oder anderen in Subversion haben, ist es möglicherweise eine gute Idee, zu wechseln. Wenn Sie jedoch keinen guten Grund für einen Wechsel haben, sollten Sie wahrscheinlich die Kosten- und Produktivitätseinbußen beim Wechsel von Versionsverwaltungssystemen vermeiden.

Nachdem Wedge beide ausgiebig genutzt hat, war er der Meinung, dass "TFS Fehlerverfolgung, Verfolgung von Arbeitselementen und andere Funktionen außerhalb der Quellcodeverwaltung umfasst".

Ich kann jedoch ehrlich sagen, dass SVN und TFS in Bezug auf die Skalierbarkeit ziemlich gleich zu sein scheinen, und wenn überhaupt, hat die Quellcodeverwaltung von SVN aufgrund ihrer inhärenten Einfachheit einen Vorteil gegenüber TFS.

Wenn Sie Workitem- und Bug-Tracking neben Ihrer Quellcodeverwaltung wünschen, entscheiden Sie sich entweder für TFS oder für SVN und andere, möglicherweise kostenlose Tools wie Bugzilla. Obwohl TFS sowohl die Quellcodeverwaltung als auch die Nachverfolgung von Arbeitselementen integriert, denke ich ehrlich, dass MS es als Entschuldigung für den Missbrauch so vieler Entwickler mit VSS im Laufe der Jahre kostenlos hätte verschenken sollen.

Ich habe sowohl SVN als auch TFS verwendet. Der Hauptvorteil der Verwendung von TFS ist die enge Integration in Visual Studio. Fehlerverfolgung, Aufgabenverfolgung werden alle an einem Ort durchgeführt. Die für diese Elemente erstellten Berichte helfen den Beteiligten, über den Projektstatus auf dem Laufenden zu bleiben.

Ich arbeite an einem Projekt mit 5 Personen und wir haben kürzlich von SVN zu TFS gewechselt. Der gesamte Prozess war ein Albtraum. Wir haben automatisch Code aus XMLSpy generiert und TFS erkennt keine Dateien, die außerhalb von VS2008 geändert wurden. Die TFS Power Tools können Ihre Kasse scannen und dieses Problem beheben. Es ist jedoch schwierig, sich daran zu erinnern, diese Tools zu verwenden. Ein weiteres Problem, auf das wir ständig stoßen, ist das Standard-Zusammenführungswerkzeug in TFS. Es ist mit Abstand das schlechteste Zusammenführungswerkzeug, das ich je verwendet habe. Man würde denken, dass TFS in der Lage wäre, grundlegende Lösungszusammenführungen durchzuführen, aber bisher war dies nicht der Fall.

Die eingebaute Benutzeroberfläche ist sehr nützlich, weist aber auch Mängel auf. Wenn ich aus meinem Lösungs-Explorer auschecke, werden manchmal hinzugefügte Dateien nicht ausgecheckt. Wenn ich es über das Team Source Control-Fenster mache, funktioniert es perfekt. Warum das? Ich freue mich auf TFS in VS2010, da ich großartige Dinge darüber gehört habe und SVN alles andere als perfekt ist, aber ich hätte erwartet, dass einige dieser Funktionen etwas intuitiver funktionieren.

Adam

TFS eignet sich hervorragend für das Projektmanagement und die Projektverfolgung. Ich bin jedoch der Meinung, dass die Quellcodeverwaltung nicht so gut ist wie SVN. Hier sind meine Rinder mit TFS:

Check-in / Check-out-Modell

Dies ist ein großer Nachteil für die TFS-Quellcodeverwaltung. Leider checkt VS Artikel automatisch für Sie aus, auch wenn Sie dies nicht möchten. Ich war in einer Situation, in der jemand einige Dateien ausgecheckt hat und dann in den Urlaub gefahren ist. Ich war für die Umstrukturierung der Verzeichnisstruktur verantwortlich, konnte dies jedoch nicht, da eine Reihe von Dateien für diese Person ausgecheckt wurden. In der GUI gibt es keine Möglichkeit, das Auschecken rückgängig zu machen, was bedeutete, dass dies einzeln in der Befehlszeile erfolgen musste. Oder ich musste herausfinden, wie man ein Power-Shell-Skript dafür schreibt.

VS muss alles tun

Manchmal möchte ich eine Textdatei bearbeiten und einchecken. Dazu muss ich VS 2010 starten, ein riesiges Biest, nur um eine Datei zu bearbeiten und einzuchecken. Etwas, das mit SVN einige Sekunden gedauert hat, dauert jetzt eine Minute .

Wie einige andere betonten, werden Dateien als schreibgeschützt markiert, wenn sie nicht ausgecheckt sind. Wenn Sie es beschreibbar machen und außerhalb von VS bearbeiten, erkennt TFS dies nicht. Dies macht das Bearbeiten von etwas außerhalb von VS ärgerlich. Dies bedeutet, VS zu starten, die Datei auszuchecken, einen anderen Editor zu bearbeiten und in VS einzuchecken.

Einige Operationen, die in SVN einfach waren, sind jetzt ein Schmerz

• Vielleicht habe ich es noch nicht herausgefunden, aber ich fand, dass das Zurücksetzen eines Änderungssatzes mit TFS sehr mühsam war.

• Das Hinzufügen von Dateien zur Quellcodeverwaltung, die nicht Teil einer Lösung sind, ist ein großer Schmerz. Der TFS-Versionsverwaltungs-Explorer zeigt nur an, welche Dateien sich in der Versionsverwaltung befinden, nicht welche (möglicherweise gibt es dafür irgendwo eine Einstellung, ich weiß nicht). Mit Tortoise SVN konnte ich einfach Commit für einen Ordner drücken und auswählen, welche Dateien hinzugefügt werden sollen.

Ich bin derzeit führend in der Bewertung von TFS in meinem Unternehmen anhand der Rational Suite, die wir derzeit verwenden. Bisher pwning TFS 2008 Clearcase + Clearquest. Die Integration der Entwicklungsumgebung ist genau dort, wo sie wirklich glänzt.

Meine 10 Cent:

TFS2005 war ein Witz - schwer zu installieren und noch schwerer zu warten. TFS2008 war stabil - einfacher zu installieren, einfacher zu warten und automatisierte Builds, die funktionieren. TFS2010 ist EPISCH! - Installation ist Hund eassssyyy. Das Management ist sehr einfach; Es ist alles eine schön gestaltete Benutzeroberfläche. Die Integration in VS2008 ist nicht so einfach, da Sie in vs2008 keine Projekte erstellen können. Sie müssen vs2010 verwenden (was dumm ist). Mit TFS2010 können Sie auch den Speicherort des Sharepoint-Projekts ändern, anstatt über diese schrecklichen Unterordner von TFS2008 zu verfügen. TFS2010 verfügt auch über Tools wie ein Burndown-Diagramm, das für das Projektmanagement sehr nützlich ist. Es ist, als ob TFS2010 für das gesamte Produktionsteam einschließlich der Kunden ist! Es kostet aber immer noch viel zu viel :(

Denken Sie auch daran, dass TFS viel mehr Leistung von der Serverhardware benötigt. Und mindestens eine Windows Server-Lizenz natürlich.

Wie unser Unternehmen befolgt hat, empfiehlt es sich, zwei Server zu verwenden: Front-End (mit integriertem Sharepoint) und einen dedizierten SQL-Server im Back-End (wir verwenden einen Unternehmenscluster). TFS kann auf einem Computer installiert werden, sollte es aber nicht.

Im Vergleich dazu ist unser SVN-Server auf einem virtuellen Linux-Server mit 256 MB RAM und 1 CPU installiert und bei allgemeinen Aufgaben wie dem Auschecken immer noch um einige Größenordnungen schneller. Die virtuelle Hardware war die niedrigste, die vshpere zuweisen konnte! Die Festplatte ist jedoch schnell (SAN).

Ich würde vorschlagen, dass TFS dedizierte Hardware für mindestens 5000 US-Dollar benötigt, während SVN-Server (unter Linux) mit jeder Hardware ausgeführt werden kann, die für aktuelle Windows-basierte Betriebssysteme veraltet ist.

Meiner Meinung nach hängt es von der Situation und dem Umfeld ab, in dem das Projekt durchgeführt wird. Wenn Sie nur ein einfaches, kleines Projekt haben, ist SVN großartig. Wie bereits einige geschrieben haben, lässt sich VisualSVN gut in Visual Studio integrieren. Sie müssen das Ein- und Auschecken nicht über das native Dateisystem durchführen.

TFS eignet sich hervorragend für die Versionskontrolle, ist aber noch besser, wenn Sie wirklich alle Funktionen nutzen. In meinen Augen lohnt es sich wirklich, wenn Sie beispielsweise die Arbeitselemente als integriertes Repository verwenden, um Kundenfehlerberichte, neue Funktionsanforderungen zu bearbeiten und den Fortschritt Ihres Projekts durch Verwalten von Aufgaben und der entsprechenden geschätzten Zeit, verwendeten Zeit und zu verfolgen verbleibende Zeitangaben.
Was auch wirklich interessant ist, ist die Verwendung der Funktion zum Verknüpfen von Arbeitselementen mit Quellcode-Checkins. Weitere Infos dazu finden Sie hier .

Wir sind ein kleines Team bei der Migration von SVN zu TFS2010. Unser Hauptgrund dafür ist die Integration in Visual Studio und WebAccess für das Bugtracking, das jetzt Teil des TFS ist.

@Adam: Hoffentlich haben wir eine bessere Erfahrung. Kann noch nicht sagen ...

Ich habe SVN in den letzten 3 Jahren verwendet (früher von VSS) und musste kürzlich auf TFS2010 umsteigen. Das allgemeine Gefühl ist, dass es fehlerhafter als SVN ist und abgesehen von der netten Integration mit den Aufgaben / Fehlern sehe ich keinen Vorteil gegenüber SVN. Die Geschwindigkeit scheint auch etwas langsamer zu sein als bei SVN.

Wenn ich jetzt eine Quellensteuerung wählen würde, würde ich immer noch mit SVN gehen.

In Bezug auf Tools: - Das AnkhSVN Visual Studio Plugin ist so gut wie die TFS-Quellcodeverwaltung. - Tortoise ist viel besser als das TFS-Gegenstück

TFS ist großartig, wenn Sie keine Nicht-Entwickler benötigen, um zu pm-Sachen zu gelangen.

Unser Helpdesk muss in den Prozess einbezogen werden, und er hat ihn einfach nicht gekürzt.

Auch das Build-Management in tfs 2005 ist zumindest attraktiv und kann nicht einmal im Vergleich zu 2008 slns erstellen. Ich mag es wirklich nicht, dass meine Quellcodeverwaltungsauswahl meine Bereitstellungsoptionen beeinflusst. Deshalb ist mein Team kein SVN-Shop.

Wenn es nur auf der Quellcodeverwaltung basiert, würde ich mich für SVN entscheiden. Das kostenlose AnkhSVN-Add-In für Visual Studio wurde in seiner neuen Version erheblich verbessert. Außerdem erhalten Sie den Quellcode für SVN und die Dokumentation ist großartig! Sie haben einige arkane Dinge in TFS 2010 Source Control geändert , und ohne den Quellcode kann die Fehlerbehebung sehr entmutigend sein. Außerdem sind Sie auf das MSDN-Team angewiesen, um die Dokumente herauszupumpen, und sie tun dies nach ihrem eigenen Zeitplan und in ihrer eigenen Tiefe.

That being said, TFS offensichtlich bietet viel mehr als nur die Quellcodeverwaltung . Es ist ein ALM- Tool. Die Kombination mit Arbeitselementen, Berichten, automatisierten Builds, gated Check-in , automatisierten Tests usw. kann einen sehr reichen Wert bieten, den Sie nur erhalten können, wenn Sie unterschiedliche Tools mit SVN verbinden. Und natürlich ist es nicht ausfallsicher, die Quelle für SVN zu haben. Ich bin mit SVN in Szenarien geraten, in denen es noch Wochen gedauert hätte, um herauszufinden, was los war.

Ich empfehle Ihnen daher, es aus einer ALM-Perspektive zu betrachten und zu prüfen, ob Ihr Unternehmen alle TFS-Funktionen nutzen oder eine Best-of-Breed-Strategie (z. B. JIRA) anwenden wird.

TFS um eine Meile.

Ich verursache mir versehentlich zu viele Probleme mit dem dateibasierten Ansatz von SVN. Probleme mit der Quellcodeverwaltung sind aufgetreten: TFS - 0 Probleme über 2 Jahre SVN - verlorene Anzahl ...

Ja, ich weiß, dass der Preis von TFS für die meisten Unternehmen eine Rolle spielt, was sehr schade ist. MS könnten viel mehr Marktanteile (und Gewinne) haben, wenn sie ein vernünftiges Preismodell hätten.