it-swarm.dev

Was sind Ihre bevorzugten Versionskontrollsysteme?

Dies ist eher eine Diskussionsfrage als ein tatsächlicher Versuch, das "Beste" zu ermitteln, da dies eindeutig von den Anforderungen der Organisation abhängt. Ich bin neugieriger auf die Argumente für verschiedene Systeme in verschiedenen Kategorien (zentralisiert gegen verteilt, offen gegen proprietär usw.).

Was ist Ihrer Meinung nach das beste Versionskontrollsystem?

41
Fishtoaster

Mercurial

Aufgrund seiner ausgeklügelten Fähigkeit, Code zu verzweigen und zusammenzuführen, ist es das Beste, das ich verwendet habe. Das ganze DVCS-Paradigma macht einfach so viel Sinn. Ich habe Git nicht verwendet, aber ich nehme an, dass es auch qualifiziert ist.

81
epotter

Git

Git ist fantastisch, und ich würde es besonders jedem empfehlen, der an Open Source-Projekten arbeitet: Es ist viel einfacher, eine kleine, einmalige Änderung an einem Projekt auf Git vorzunehmen, insbesondere wenn es auf GitHub gehostet wird, als wenn es sich um E- handelt. Mailing Patches über mit SVN.

Eine große Einschränkung für Windows-Benutzer: Die Windows-Tools von Git sind zwar definitiv verwendbar, aber nicht ganz auf dem neuesten Stand. Als ich gezwungen war, Windows für eine Weile zu verwenden, habe ich die Windows-Oberfläche von Mercurial mit einem Hg-Git-Integrationstool ausprobiert, damit ich meine Git-Repositorys verwenden konnte, und fand das viel einfacher zu verwenden.

72
Gaurav

Warnung: Seit diesem Beitrag habe ich Mercurial gefunden und liebe es viel besser als SVN. Daher ist dieser Beitrag mit den Pro SVN-Kommentaren und dem allgemeinen Anti-DVCS etwas veraltet, aber das Anti-Git-Zeug ist immer noch relevant


Ich bin ein Fan von SVN über Git.

Warum? Weil SVN für einen einzelnen Entwickler oder ein kleines Team viel einfacher war und git (speziell msysgit) mich mit einem schlechten Geschmack im Mund zurückließ.

Als ich in einem kleinen Laden praktizierte, wurde ich in Windows eingeführt. Ich bemerkte sofort, wie viel Arbeit nötig war, um mit Github zusammenzuarbeiten. Zuerst musste ich einen privaten SSH-Schlüssel generieren, den öffentlichen Schlüssel in Github einfügen, dann den Festzug aufrufen und meinen privaten Schlüssel jedes Mal öffnen, wenn ich Push wollte, was äußerst ärgerlich war.

Und es hat mir nie wirklich gefallen, dass ich das gesamte Repository heruntergefahren habe. Ich gebe zu, dass ich nie mit etwas Großem gearbeitet habe, aber ich hätte Angst, das KDE-Repository in Git herunterzuladen, wenn das gesamte Repo und seine Revisionen auf meiner Festplatte sind.

Dann gab es den verwirrenden Prozess, ein Commit zu machen. TMK, ich musste zuerst alle Dateien "inszenieren", die ich festschreiben wollte (was scheiße war, wenn Sie viele, viele Dateien hatten, ich brauchte eine Weile, um den manuellen Befehl zu finden, um alles zu inszenieren), dann das Festschreiben ausführen und dann zum Hauptmenü drücken Repo (warum ist das eine separate Operation?!).

Sie hatten auch die nicht (!) Sehr hilfreichen Commit-Daten. Oh schau, das ist Commit 14f74433245ae17aeeaa Teil des Baumes 2167a4934d0a4a7db0de und Eltern d7042abb4821d3faf600. Zum Teufel heißt das? Ich sollte in der Lage sein, die Dinge ziemlich schnell herauszufinden und keine seltsame Dokumentation zu konsultieren.

Apropos Dokumentation, zumindest als ich sie benutzte, schien alles im Linux-Man-Dateiformat zu sein, IE verwirrend und nutzlos für mich. Ich konnte selten viel Hilfe in den Dokumenten finden und griff einfach zurück googeln.

Und mit Commits war das einzige, was mir nicht gefallen hat, das Fehlen von Versionsnummern. Jetzt weiß ich, dass dies am Design von Git liegt, aber jede Software benötigt eine Versionsnummer. Ich erinnere mich noch an die Markierungs-Commits, die auftauchten und "Geänderte Version auf 1.8.6" oder ähnliches sagten, aber Sie konnten immer noch keine Zahlen erstellen. Für mich bedeutet die Version 1.8.6.5164 (letzter Teil ist die Revisionsnummer) viel mehr als nur 1.8.6 und eine Notiz, die besagt, dass sich etwas Kleines geändert hat. Probieren Sie es aus

Das Basisprogramm unter Windows ist msysgit, eine schreckliche Oberfläche. Es hat mich ein paar Mal blockiert, hatte eine schreckliche Oberfläche und die CLI-GUI-Integration war bestenfalls zweifelhaft. Die Kommandozeilen-Junkies um mich herum hassten die GUI noch mehr.


Schauen wir uns nun SVN an. Und da ich unter Windows bin und ein Google-Konto habe, insbesondere TortoiseSVN und Google Code.

Schließen Sie zunächst die Shell-Integration ab, um alles im Repository zu erledigen (und für Sie Linux-Benutzer macht RabbitVCS dasselbe), ohne dass eine Haupt-GUI erforderlich ist. Das Abrufen eines Repositorys ist als Checkout einfach, es wird kein SSH benötigt (ich kann mich nicht erinnern, ob Github SSH für Pulls benötigt hat) und kein vollständiges Repo + alle früheren Commits auf Ihrer Festplatte.

Das Festschreiben ist extrem einfach, hauptsächlich weil kein SSH oder Staging erforderlich ist. Sie überprüfen einfach alle gewünschten Dateien mit der sehr hilfreichen Option Alle auswählen, die in meiner msysgit-Version nicht verfügbar war, geben eine Festschreibungsnachricht ein und klicken auf Festschreiben. Google Code fragt Sie dann nach Ihren Anmeldeinformationen (die von den meisten Kunden gespeichert werden) und ist fertig. Einfach, leicht und ohne SSH

Versionsnummern? Mit etwas einfachem Code können Sie allen Kassen eine Versionsnummer und eine Festschreibungsnummer hinzufügen, was die Sache so viel einfacher macht. Sie erhalten auch verwendbare Versionsnummern, die tatsächlich eine Änderung anzeigen, z. B. 1.8.6.5165 ist neuer als 1.8.6.5164.

Dokumentation? Nun, es ist schwer zu sagen. Schildkröte ist dokumentiert, aber ich habe mich seit so langer Zeit nicht mehr auf die offizielle Dokumentation bezogen, dass ich nicht beurteilen kann. Das Lesen eines einfachen Intro-Leitfadens hat mir gereicht.

Das Zusammenführen ist etwas anderes, das ich nicht vergleichen kann. Ich musste es einmal in Git tun, als jemand anderes eine Änderung an einer Datei festlegte, an der ich arbeitete, aber nie in SVN.


Welches würde ich empfehlen? In großen Teams hat Git seine Vorteile, hauptsächlich in seinem nichtlinearen Entwicklungszyklus. In einem anderen Projekt habe ich gesehen, wie 4 Programmierer in getrennten Zweigen gestartet sind und dann den gesamten Code auf sehr seltsame Weise zusammengeführt haben, die sich irgendwie in den endgültigen Hauptzweig verwandelt haben. Github und msysgit hatten ein wirklich nettes Visualisierungstool für das gesamte Projekt, das mir sehr gut gefallen hat.

Für Einzelentwickler- oder kleine Teamprojekte ist SVN das Beste, da die meisten Gits-Funktionen nicht verwendet werden und Sie nur die negativen Teile erhalten. Einfachheit ist so eine schöne Sache

24
TheLQ

Das folgende Zitat aus Q4TD fasst es für mich ziemlich gut zusammen:

„Ich habe Git geliebt, bis ich es ausprobiert habe. Jetzt liebe ich Mercurial. “

- Tor Norbye, Der Podcast Java Posse

Außerdem ist hgsubversion ein ziemlich guter Subversion-Client für Linux (wo ich normalerweise die Befehlszeile verwende, im Gegensatz zu Windows, wo ich normalerweise TortoiseSVN verwende). Der größte Vorteil: nein .svn Unterordner in jedem Ordner, nur ein .hg auf der obersten Ebene.

Update: Als Antwort auf Alex 'Bitte in den Kommentaren, "mehr darüber zu sagen, warum Git bei dir nicht funktioniert hat und wie Mercurial besser funktioniert hat":

Ich würde nicht sagen, dass Git bei mir nicht funktioniert, aber Murcurial funktioniert IMO besser.

Kurz gesagt, das ist Mercurial:

alt text

und das ist Git:

alt text

Und ich behaupte, dass Mercurial alles tun wird, was die meisten Entwickler benötigen, ohne das Handbuch nachschlagen zu müssen, um herauszufinden, wie die alltäglichen Dinge zu tun sind.

Zugegeben, ich habe Git nur gelegentlich verwendet, aber die Programmier-Community hat sich über Sprachen wie Ruby und Python, teilweise wegen ihrer Prägnanz und Eleganz) lustig gemacht, während Git sich wie ein Kamel anfühlt wurde von einem Komitee von Kamelen entworfen.

Bah, schau dir jetzt an, was du getan hast? Überall wird geschimpft. Bewegen Sie sich, nichts zu sehen ... nichts zu sehen ...

Update 2: Und noch ein Apropos Tweet Ich bin gerade auf Folgendes gestoßen:

"Git wird einfacher, wenn man die Grundidee hat, dass Zweige homöomorphe Endofunktoren sind, die Untervielfalt eines Hilbert-Raums abbilden."

22
Evan

Ich habe kein einziges "bestes" Versionskontrollsystem, sondern ein einziges bestes VCS-Paradigma.

Ich habe mehrere verschiedene zentralisierte Versionskontrollsysteme und mehrere verschiedene verteilte Versionskontrollsysteme verwendet. Und ich kann ohne zu zögern sagen, dass niemand sich jemals ein CVCS zufügen sollte.

Es ist mir egal welches DVCS, das Sie wählen (mein besonderer Favorit ist Git), aber bitte tun Sie sich selbst einen Gefallen und verwenden Sie ein DVCS. Zum einen: Sie werden viel flexibler sein. DVCSs können einen CVCS-Workflow trivial emulieren (verzweigen Sie das Repository nur niemals und behandeln Sie Ihre lokalen Repositorys nur als Chache anstelle einer unabhängigen Verzweigung), während das Gegenteil unmöglich ist. Und während ich logischerweise diese Emulation mache sollte etwas Overhead mit sich bringen (und tatsächlich tut es das), finde ich immer noch es einfacher zu benutzen (ganz zu schweigen von der viel leistungsfähigeren aufgrund der lokalen Caching) als alle von mir verwendeten CVCS.

14
Jörg W Mittag

Ich kann nicht sagen, dass ich auf die beste Versionskontrollsoftware gestoßen bin, aber ich kann Ihnen sagen, dass Sie sich von VSS und MKS fernhalten sollen. Beide sind Hunde, die unbedingt vermieden werden sollten.

11
Walter

Ich würde nicht das Beste sagen, aber eines mit sehr interessanten Funktionen und Konzepten.

Fossil ist ein verteiltes Versionskontroll-, Fehlerverfolgungs- und Wiki-Projekt, das auf einer SQLite-Datenbank als Repository basiert.

7
Maniero

Team Foundation Server

Weil:

  1. Es ist ein gutes, solides VCS. (Ich würde es auf keinen Fall als das Beste betrachten, aber es hat nette Extras.)
  2. Die integrierte Aufgaben- und Fehlerverfolgung, die in Visual Studio integriert ist, hilft mir, konzentriert zu bleiben und zu wissen, woran ich an einem Ort arbeiten muss (das automatische Einchecken eines Fehlers oder einer Aufgabe und das Schließen ist ziemlich gut, obwohl Sie dies können Holen Sie sich dazu Plugins für andere Systeme/Eclipse/etc.)
  3. Es integriert Aufgaben/Fehlerverfolgung/Projekte direkt in Project Server, sodass ich selten Projektpläne oder Arbeitszeittabellen auf dem neuesten Stand halten muss. Aktualisierungen des Projekts in Project Server werden automatisch als Aufgaben in TFS und in Visual Studio gefiltert, damit ich sie automatisch sehen kann.
5
Ryan Hayes

Ich habe in meiner langen Geschichte eine Vielzahl von Versionskontrollsystemen verwendet:

  • RPPT Rollen aus gestanztem Papierband). In einem Schuhkarton. Ich scherze nicht.
  • PVCS - (Polytron Versionskontrollsystem). Das erste echte VCS, das ich benutzt habe.
  • SCCS - vor so langer Zeit erinnere ich mich an nichts außergewöhnlich Gutes oder Schlechtes.
  • RCS - wie andere betont haben, würde lieber verschwitzte Eselbälle lutschen.
  • CVS - es war nur ein Schmerz, wenn es mit mehr als 2 Programmierern verwendet wurde. beste Eigenschaft: rcs2cvs.
  • VSS - es funktioniert, außer an Dienstagen, wenn es Ihr gesamtes Repository beschädigt.
  • Perforce - kostet mehr als mein Auto. Das VCS selbst ist akzeptabel, aber die dickköpfigen IT-Mitarbeiter, die jeden Aspekt der Verwendung kontrollieren, werden es niemals auf meiner "bevorzugten" Liste landen.
  • SVN - Verzweigen und Zusammenführen ist eine Hündin, aber im Allgemeinen ist es besser als alle vorherigen. Nicht so gut mit vielen kleinen herausragenden Änderungen, die auf eine Überprüfung warten.
  • Mercurial - die wenig Erfahrung, die ich damit habe, mag ich. Ich könnte es bei meinem nächsten Projekt versuchen.
  • Git - hatte nie die Gelegenheit, es zu benutzen.

Obwohl ein Paar Horror war, waren die meisten "in Ordnung". Sie sind mir nicht in die Quere gekommen. Solange ein Werkzeug --- (macht mein Leben nicht wesentlich schwieriger, macht es mir nichts aus.

Die wirkliche Sache ist, die Stärken und Schwächen eines jeden zu verstehen. Verstehen Sie die Zielumgebung:

  • verteilt oder lokal
  • kleines Team oder großes
  • gehosteter VCS-Dienst oder nicht
  • einfache Integration in andere Tools

Joel kam auch mit einer wichtigen Beobachtung heraus: Lernen Sie das Werkzeug und sein wahres Verwendungsmodell. Er kämpfte mächtig darum, Mercurial dazu zu bringen, sich wie Subversion zu verhalten.

4
brettmjohnson

Ein neueres System, das wir in meinem Büro verwenden, ist Plastic SCM (http://www.plasticscm.com/). Es funktioniert sehr gut für unser kleines Team und gibt uns eine großartige Kontrolle über jeden Aspekt des Quellmanagements.

2
Tom A

SCCS .

Oder wenn Sie in den letzten 38 Jahren keine Höhle mehr bewohnt haben, CSSC .

Im Ernst, meine Firma verwendet TeamWare , eine Art Pseudo-DVCS, das auf SCCS basiert.

Nein, ich mache keine Witze.

Sun ist erst vor wenigen Jahren von TeamWare zu Mercurial gewechselt. Jetzt sollten Sie verstehen, warum Java schien sich so langsam zu bewegen.

1
Geoffrey Zheng

MPW: Nun, ich kann es trotz meiner Bemühungen nicht wirklich bewerten.

Dies war damals, als ich in der High School Programmieren lernte, und der einzige wirklich kostenlose C++ - Compiler war die Macintosh Programming Workbench, die ich auf einer Zip-Disk aufbewahrte und in die Performa steckte, die im Labor verfügbar war.

MPW wurde mit Dutzenden von Tools geliefert (von denen keines erneut bearbeitet wurde, dh als separater Download), und eines davon war ein Versionskontrolldienstprogramm. Es öffnete sich ein kleines Fenster mit einer einzigen Textzeile, und Sie sollten Ihre Projekte oder Dateien per Drag & Drop darauf ziehen. Es gab keine Dokumentation, die ich jemals entdecken konnte, ungewöhnlich, wenn man bedenkt, dass alles andere großartige Dokumente zu haben schien, und deshalb habe ich nie ganz herausgefunden, wie man es benutzt.

Das war mein erster Pinsel mit VC und der letzte für eine lange Zeit. Jetzt benutze ich Git für alles.

RCS - Revisionskontrollsystem

Solo-Codierung so einfach gemacht.

0
Jé Queue

Ich habe Visual SourceSafe verwendet und es gehasst, aber es war besser als nichts, aber nicht viel. In den letzten Jahren wurde QCVS von Qumasoft.com verwendet, das von Jim Voris, dem Programmierer, geschrieben, besessen und unterstützt wurde. Einfache GUI, günstiger Preis, gute Unterstützung.

Macht einfach den Job.

0
crosenblum

Nicht ClearCase, zumindest für ein Unix/Linux-System (möglicherweise ist das Installationsprogramm unter Windows einfacher). Es war für mich einfacher, ein neues Tool, Perforce, zu erlernen, als unseren ClearCase-Server zu aktualisieren.

Ich benutze derzeit Perforce bei der Arbeit und es gefällt mir, aber ich habe keine Ahnung, ob es das Beste ist. Das Einrichten der Befehlszeilenumgebung und des Perforce-Servers ist etwas umständlich, die Verwendung des Visual Clients ist jedoch recht einfach. Ich denke gerne, dass die Benutzer es für alltägliche Aufgaben ziemlich leicht haben. Es ist nur die anfängliche Einrichtung, die einige Arbeit erfordert.

0
Chance