Inwiefern ist Mercurial besser/schlechter als TFS?

Question

Ich bin gerade einer neuen Firma beigetreten und im Moment verwenden wir Microsoft SourceSafe als unser Repository. Die Einstellungen sind nicht ideal und es ist ein großer Schmerz im Nacken.

Ich habe kürzlich Mercurial verwendet und dachte, es sei erstaunlich, also befürworte ich den Wechsel zu diesem, aber es sieht so aus, als ob das Unternehmen bereits eine Team Foundation Server-Lizenz hat und diese stattdessen verwenden möchte.

Kann mir jemand eine Liste von Punkten geben, wo einer besser ist als der andere? Ich habe TFS nicht benutzt und weiß daher nicht, wo es gut/schlecht ist.

Answer 1

Sie können TFS und ein DVCS nicht direkt vergleichen.

Wenn Ihr Unternehmen in Richtung TFS lehnt sich, dass aufgrund der other features TFS comes with sein kann (Datenerfassung, Reporting und Projektverfolgung, die alle gut integriert mit Microsoft-Produkten)

---

Auf der reinen Version-Control Seite, Die Team Foundation Server 2010, mit seiner Team Foundation Version Control (TFVC) 2010, führt Filialen als erstklassige Bürger.
Siehe Team Foundation Server and branching characteristics, compared to others.

Ich finde immer noch ihre verzweigenden Modelle komplexer als eine Mercurial oder Git ein.
Siehe TFS2010 Branching into a subfolder of another branch vs. Guide to Branching Model in Mercurial (und diese SO question die auch verschmilzt und Zweige mit DVCS Details)

Dass gesagt wird, bleibt es eine CVCS (Zentrale VCS), das heißt, Sie verschiedene Arbeitsprozesse erhalten als mit einem DVCS: siehe Describe your workflow of using version control (VCS or DVCS) .

Die true killer feature of a DVCS bleibt ihre Zusammenführungsfunktion (einfacher und schneller als jeder CVCS). Aber introducing a DVCS in a corporate environment remains hard.

Answer 2

Ich empfehle Joel auf Software http://hginit.com für eine Liste von sehr guten Gründen, um auf verteilte Versionskontrolle zu wechseln.

Answer 3

Ich habe ein paar Fehler mit TFS gefunden, die es ein wenig anders als andere CVCS machen.

• TFS ist sehr schwierig außerhalb von Visual Studio zu verwenden. Sogar Diffing-Versionen sind in VS gemacht. Persönlich verwende ich VS nur zum Schreiben von Code.
• Wir hatten viele Probleme mit DLLs und anderen Binärdateien, die nicht auf die neueste Version aktualisiert wurden.
• TFS macht alle Ihre Dateien unter Versionskontrolle schreibgeschützt. Dies macht das Ändern von Dateien außerhalb von VS sehr schmerzhaft. Tatsächlich verursacht dies immer noch Probleme mit Silverlight-Projekten in unserer Continuous Integration in TFS.
• Das Befehlszeilentool für TFS ist nicht einfach über die Befehlszeile zu verwenden. (Persönlich Ich mag die Befehlszeile verwenden)

Hintergrund: Meine Firma wechselte von SVN und TFS und ich benutze Mercurial/Git für meine Seite Projekte. Ich folgte auch diesem blog about using Mercurial with TFS und es hat meine Arbeit mit TFS viel angenehmer gemacht.

Answer 4

TFS ist ein Application Lifecylce-Management-Tool nicht nur ein Quellcode-Repository/Versionierungssystem.

Es ist Stärke ist:

-It's natural integration into Visual Studio (+100) 
-It's Full App Lifecycle support from Work Item through Q/A acceptance. 
-It's integration with MS Project/Sharepoint, and all the other 
hoo-ha's you get 
-And now TFS 2012 has added support for "Local Workspaces" which allows 
    for off-line working, but also allows "Server Workspaces" which is 
    similiar to TFS 2010. 
-Diff on every Check-in/Commit 

Die Quelle Steuerseite davon ist auch sehr stark, aber persönlich, solange ich die ganze Geschichte sehen kann, keinen Code verlieren, und nicht meinen Code haben " trat auf". Ich könnte einen Fehler machen.

Ich benutze TFS seit 2008 und die jüngste Runde der Verbesserungen zeigt Microsofts Engagement für die Weiterentwicklung ihrer Produkte und die Anpassung an Veränderungen in der Branche. Persönlich liebe ich es, aber ich bleibe in der Microsoft-Umgebung (die ich auch liebe) .. außerhalb davon kann es nicht mit allen Bedürfnissen funktionieren.

Nun, ein paar Tage in die Arbeit mit Mercurial professionell (BitBucket/Mercurial/TortoiseHG/VisualHG), muss ich sagen, die Werkzeuge scheinen ein bisschen veraltet. Die Integration mit Visual Studio ist wie lauwarmer Kaffee (ho-hum), und die Integration des Explorers bringt mich zurück zu den "guten alten Tagen", als ich das Glück hatte, NICHT an Visual Source Safe zu arbeiten.

Eine andere Sache zur Kenntnis zu nehmen ist die Leichtigkeit der Migration von Visual Source Safe in TFS, es ist ziemlich schmerzlos .. Ich habe vor kurzem meine letzten Unternehmen gesamte Geschichte in VSS in TFS verschoben und es dauerte nur ein paar Befehlszeilen-Utils und über Nacht um die gesamte Änderungshistorie zu verschieben. Ich war schockiert (wie bei meinen Kollegen), wie einfach die Migration war, sie hat sogar die ganze Geschichte seit Beginn behalten (auf Bitte der zuständigen Stellen)

Ich bin definitiv voreingenommen mit MS-Tools für eine gearbeitet Lange Zeit, aber es gibt nicht viel zu kontrollieren, so lange es funktioniert.

Wenn Ihre Organisation wirklich alle Aspekte der Anwendungsentwicklung verwalten will, und sie noch keine integrierten Werkzeuge oder Prozesse haben, wird TFS sie leisten die Fähigkeit, von Anfang an zu wachsen und zu managen.

beginnt mit Source Control, Ende mit specs up entstand in MS Project, gebunden Artikel arbeiten gebunden an Unit Test gebunden an Akzeptanztests gebunden automatisierten Builds und Deployments

Und schließlich: Burn Down/Geschwindigkeit Charts