Was sind Ihre bevorzugten Versionskontrollsysteme? [geschlossen]

Dies ist mehr eine Diskussionsfrage als ein tatsächlicher Versuch, das "Beste" zu bestimmen, da dies eindeutig von den Bedürfnissen der Organisation abhängt. Ich bin eher neugierig auf die Argumente für verschiedene Systeme in verschiedenen Kategorien (zentral oder verteilt, offen oder proprietär usw.).

Was ist Ihrer Meinung nach das beste Versionskontrollsystem?

Mercurial

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

Git

Es 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, besonders wenn es auf GitHub gehostet wird, als wenn es sich um E-Mails handelt. Patches mit SVN versenden.

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 eine Weile gezwungen war, Windows zu verwenden, habe ich die Windows-Oberfläche von Mercurial mit einem Hg-Git-Integrationstool ausprobiert, damit ich meine Git-Repositorys verwenden konnte.

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) einen schlechten Geschmack in meinem Mund hinterließ.

Als ich in einem kleinen Laden ein Praktikum machte, wurde ich mit Windows vertraut gemacht. Ich bemerkte sofort, wie viel Arbeit nötig war, um es mit Github zum Laufen zu bringen. 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 einen Push ausführen wollte, was äußerst ärgerlich war.

Und es hat mir nie wirklich gefallen, dass ich das gesamte Repository abgerissen habe. Ich gebe zu, dass ich nie mit großen Dateien gearbeitet habe, aber ich hätte Angst, das KDE-Repository in Git herunterzuladen, wenn sich das gesamte Repo und seine Revisionen auf meiner Festplatte befinden.

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

Sie hatten auch die nicht (!) Sehr hilfreichen Festschreibedaten. Oh schau, das ist ein Commit 14f74433245ae17aeeaa Teil des Baumes 2167a4934d0a4a7db0de und der 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 verwendete, schien alles im Linux-Man-Dateiformat zu sein, dh verwirrend und für mich nutzlos. Ich konnte selten viel Hilfe in den Dokumenten finden und griff einfach auf Google zurück.

Und bei Commits hat mir das Fehlen von Versionsnummern nicht gefallen. 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, bei denen "Geänderte Version auf 1.8.6" oder ähnliches angezeigt wurde, aber Sie konnten trotzdem keine Build-Nummern erstellen. Für mich ist 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 geringfügiges geändert hat, probieren Sie es aus

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

Nun schauen wir uns SVN an. Und da ich auf Windows bin und ein Google-Konto habe, speziell TortoiseSVN und Google Code.

Erstens, vollständige Shell-Integration, um alles im Repository zu erledigen (und für Linux-Benutzer macht RabbitVCS dasselbe), es ist keine Haupt-GUI erforderlich. Das Abrufen eines Repositorys ist ein Kinderspiel, es wird kein SSH benötigt (ich kann mich nicht erinnern, ob Github SSH für Pulls benötigt) und es wird kein gesamtes Repository + alle bisherigen Commits auf Ihrer Festplatte gespeichert.

Das Festschreiben ist äußerst einfach, vor allem, 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 Sie eine Commit-Nachricht ein und klicken Sie auf Commit. Google Code fragt Sie dann nach Ihren Anmeldeinformationen (die von den meisten Kunden gespeichert werden) und danach, ob Sie fertig sind. Einfach, leicht und ohne SSH

Versionsnummern? Mit etwas einfachem Code können Sie allen Kassen eine Versionsnummer und eine Commit-Nummer 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 seit so langer Zeit nicht mehr auf die offizielle Dokumentation verwiesen, dass ich sie nicht beurteilen kann. Es hat mir gereicht, eine einfache Einführung zu lesen.

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

Welches würde ich empfehlen? In großen Teams hat git seine Vorteile, hauptsächlich im nichtlinearen Entwicklungszyklus. In einem anderen Projekt habe ich 4 Programmierer in getrennten Zweigen starten sehen, die dann auf sehr seltsame Weise den gesamten Code zusammengeführt haben, der sich irgendwie in den endgültigen Masterzweig verwandelt hat. Github und msysgit hatten ein wirklich schönes Visualisierungstool für das gesamte Projekt, das mir sehr gut gefallen hat.

Für einzelne Entwickler 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

Das folgende Zitat aus Q4TD bringt es für mich auf den Punkt :

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

        - Tor Norbye, Der Java Posse Podcast

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: Kein .svnUnterordner in jedem Ordner, nur eine .hgoberste 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":

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

Kurz gesagt, das ist Mercurial:

und das ist Git:

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

Zugegeben, ich habe Git nur gelegentlich benutzt, aber die Programmierer-Community hat Sprachen wie Ruby und Python teilweise wegen ihrer Prägnanz und Eleganz in den Schatten gestellt, während Git sich wie ein Kamel anfühlt, das von einem Komitee von Kamelen entworfen wurde.

Bah, sieh dir jetzt an, was du getan hast. Es wird überall geschimpft. Gehen Sie weiter, nichts zu sehen ... nichts zu sehen ...

Update 2: Und noch ein Tweet, auf den ich gerade gestoßen bin:

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

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

Ich habe mehrere verschiedene zentrale Versionskontrollsysteme und mehrere verschiedene verteilte Versionskontrollsysteme verwendet. Und ich kann ohne zu zögern sagen, dass sich niemand ein CVCS auferlegen sollte.

Es ist mir egal, welches DVCS Sie auswä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. DVCSs können einen CVCS-Workflow trivial emulieren (nur niemals das Repository aufteilen und Ihre lokalen Repositorys nur als Chache statt als unabhängige Aufteilung behandeln), wohingegen das Gegenteil unmöglich ist. Und während logisch, diese Emulation tun sollte tragen einige Overhead (und in der Tat ist es), ich noch finden es einfacher zu bedienen (nicht viel mehr performant aufgrund des lokalen Caching ganz zu schweigen) als eine der CVCSs ich verwendet habe.

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. Beides sind Hunde, die man unbedingt meiden sollte.

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

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

Team Foundation Server

Weil:

1. Es ist ein gutes, solides VCS . (Ich würde es auf keinen Fall für das Beste halten, aber es hat nette Extras.)
2. Die in Visual Studio integrierte Aufgaben- und Fehlerverfolgung hilft mir, konzentriert zu bleiben und zu wissen, woran ich arbeiten muss (das automatische Anwenden eines Eincheckvorgangs auf einen Fehler oder eine Aufgabe und das Schließen ist recht 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.

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

• RPPT - (Rollen gelochtes 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 besonders Gutes oder Schlechtes.
• RCS - wie andere betont haben, würde lieber verschwitzte Eselbällchen lutschen.
• CVS - es war nur ein Schmerz, wenn es mit mehr als 2 Programmierern verwendet wurde. beste Eigenschaft: rcs2cvs.
• VSS - funktioniert, außer dienstags, wenn das gesamte Repository beschädigt wird.
• Perforce - kostet mehr als mein Auto. Das VCS selbst ist akzeptabel, aber die IT-Experten, die jeden Aspekt seiner 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 ausstehenden Änderungen, die noch geprüft werden müssen.
• Mercurial - was für wenig Erfahrung ich damit habe, mag ich. Ich könnte es bei meinem nächsten Projekt versuchen.
• Git - hatte nie die Gelegenheit, es zu nutzen.

Obwohl ein paar Horror waren, waren die meisten "in Ordnung". Sie haben mich nicht behindert. Solange ein Werkzeug mein Leben nicht wesentlich erschwert , macht es mir nichts aus.

Im Grunde geht es darum, die Stärken und Schwächen eines jeden zu verstehen. Verstehen Sie die Zielumgebung:

• verteilt oder lokal
• kleines team oder großes
• gehosteter vcs service oder nicht
• einfache Integration in andere Tools

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

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 Quellcodemanagements.

SCCS .

Oder, falls Sie in den letzten 38 Jahren nicht mehr in einer Höhle gelebt 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 ein paar Jahren von TeamWare auf Mercurial umgestiegen. Jetzt sollten Sie verstehen, warum Java sich so langsam zu bewegen schien.

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

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

MPW wurde mit Dutzenden von Tools ausgeliefert (keines davon wurde erneut bearbeitet, das war ein separater Download), und eines davon war ein Dienstprogramm zur Versionskontrolle. Es öffnete sich ein kleines Fenster mit einer einzelnen Textzeile und Sie mussten Ihre Projekte oder Dateien darauf ziehen und ablegen. Es gab keine Dokumentation, die ich jemals entdecken konnte, ungewöhnlich, wenn man bedenkt, dass alles andere großartige Dokumente zu haben schien, und ich habe nie ganz herausgefunden, wie man es benutzt.

Das war meine erste Bürste mit VC und die letzte für eine lange Zeit. Jetzt benutze ich Git für alles.

RCS - Revisionskontrollsystem

Solocodierung so einfach gemacht.

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

Ich verwende 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 Client ist jedoch recht einfach. Ich denke gern, dass die Benutzer eine ziemlich leichte Zeit damit für alltägliche Aufgaben haben; es ist nur die anfängliche Einrichtung erfordert etwas Arbeit.

Ich habe Visual SourceSafe benutzt und es gehasst, aber es war besser als nichts, aber nicht viel. In den letzten Jahren verwendete Qumasoft.com QCVS, das von Jim Voris, dem Programmierer, geschrieben, besessen und unterstützt wurde. Einfache gui, günstigen preis, gute unterstützung.

Macht einfach den Job.