Was sind Ihre bevorzugten Versionskontrollsysteme? [geschlossen]


41

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?


1
en.wikipedia.org/wiki/Comparison_of_revision_control_software ist genau dafür eine großartige Vergleichstabelle. Diskussionsfrage ... Community-Wiki?
Chris

4
Der erste, der den Namen veröffentlicht, erhält den Repräsentanten. Dies sollte ein Community-Wiki sein.
Takeshin


Ich habe nicht bemerkt, dass dies bereits ein Community-Wiki ist .
Takeshin

Antworten:


81

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.


Ich muss Mercurial einige Zeit ausprobieren, da ich bereits 2 der großen 3 ausprobiert habe. Und da Google Code es unterstützt ...
TheLQ

2
Mercurial ist süß, wenn Sie Netbeans verwenden. Die IDE-Integration ist perfekt.
Seun Osewa

4
Ich bevorzuge Mercurial einfach, weil TortoiseHg ausgereifter ist als TortoiseGit :-) (die gesamte Erfahrung unter Windows ist auch in Mercurial viel besser)
Dean Harding

+1, ich schlage vor, Mercurial fett und größer zu machen (wie Gaurav es in seiner Antwort getan hat)
Tim Post

Mercurial ist ziemlich süß. Ich und mein Team haben es für ungefähr 2 Monate benutzt und es ist ein Hauch frischer Luft im Vergleich zu SVN.
Gary Willoughby

72

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.


5
Ich denke, es ist wichtig zu sagen, dass Schwachkopf schwer ist. Ich liebe es wirklich, aber es ist nicht etwas, das man an ein paar Tagen lernen kann. Sie müssen es für eine Weile benutzen und wütend werden, bis Sie etwas dagegen haben zu wechseln ... ;-)
Khelben

1
@Khelben - Da ist etwas Wahres dran, ja. Es scheint jedoch auch die größte Menge an Literatur / Artikeln / Tutorials im Internet zu haben. Ich finde regelmäßig Git-Bücher heraus, Mercurial - nicht so sehr (mit Mercurial als Kontrast, da es Git in vielerlei Hinsicht ähnlich ist). Ich kann nicht sagen, ob das gut oder schlecht ist, aber es scheint, dass die Leute es benutzen.
Rook

2
msysgit ist unter Windows verwendbar.

1
Ich gehe davon aus, dass Git, Mercurial usw. alle recht gut sind, aber ich habe mich hauptsächlich wegen auf GitHub für Git entschieden. GitHub fühlt sich besser an als vergleichbare Websites und viele wichtige Projekte werden dort gehostet. GitHub senkt die Barriere, um viel zu Open Source beizutragen.
LennyProgrammers

2
Mercurial braucht kein Buch.
Warren P

24

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


6
Das Zusammenführen mit SVN ist ziemlich riskant (verglichen mit Git). Das ist eine Sache, die bei jedem Vergleich beachtet werden muss.
Khelben,

5
Warum müssen Sie jedes Mal einen Festzug erziehen? Es ist ein Schlüsselagent. Sie müssen es nur einmal aufrufen, wenn Sie sich auf Ihrem Computer anmelden. Sie fügen Ihren Schlüssel hinzu und sind fertig . (Und Sie können es noch einfacher machen, indem Sie Ihre Schlüsseldatei mit pageant verknüpfen und diese Ihrem Startordner hinzufügen. Beim Anmelden wird ein Dialogfeld angezeigt, in dem Sie zur
Eingabe

3
@Thorbjoern @Frank Shearer: Ich denke schon die Tatsache, dass Sie sagen "Sie können das, oder Sie können das, und haben diese Probleme nicht", unterstreicht den Punkt: Das sind Lösungen für ein Problem oder ein Problem. Bei einigen anderen VCS ist dies kein Problem.
Steven Evers

4
Diese Antwort fällt mir sehr auf, als ich mich über etwas beschwerte und darüber jammerte, dass das Poster offensichtlich nicht die Zeit brauchte, um es zu verstehen. Ich habe viel Zeit in git und svn verbracht, sowohl unter Linux als auch unter Windows, und werde beweisen, dass git svn in Konzept, Datenmodell, Verständlichkeit und Nützlichkeit weit überlegen ist.
Gahooa

4
@TheLQ Nein. Es ist überhaupt nicht "Ihre Linux-Mentalität". Es ist einfach einzurichten, gut dokumentiert und PuTTY ist eine hervorragende Windows-Anwendungssuite, mit der die Bedienung wirklich sehr einfach ist. Und Sie sollten Ihre Codeübertragung wirklich verschlüsseln, wenn Sie über ein öffentliches Netzwerk arbeiten. Und es ist eine Beleidigung für Windows-Benutzer, anzunehmen, dass sie zu dumm sind, um zu lernen, wie man die Tools verwendet, die sie verwenden sollten. Ich bitte die Leute nicht, in Sachen zu schälen. Ich bitte sie, ihre wichtigen Informationen zu verschlüsseln.
Frank Shearar

22

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:

Alt-Text

und das ist Git:

Alt-Text

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


Schon mal RabbitVCS ausprobiert?
TheLQ

Nein, aber ich benutze KDE, nicht Gnome, also würde es mir sowieso nicht passen. Ich verwende gelegentlich einen grafischen SVN-Client unter Linux, aber nur dann, wenn ich etwas Esoterisches mache, wie das Durchsuchen eines Repositorys oder das Vergleichen früherer Revisionen. Nicht für das einfache Hinzufügen / Entfernen / Festschreiben / Protokollieren. Die Befehlszeile ist schneller.
Evan,

2
Könnten Sie mehr darüber sagen, warum git bei Ihnen nicht funktioniert hat und wie Mercurial besser funktioniert hat? Das wäre ziemlich interessant zu lesen.
Alex Feinman

Ich bin mir ziemlich sicher, dass in der Git-Darstellung ein 6-Zoll-Rasiermesser fehlt ...
Tim Post

2
@ Tim: Rebase? Es ist wahrscheinlich auf der anderen Seite.
Alan Pearce

14

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.


3
Das ist eine großartige Antwort. Es gibt kein "bestes" VCS, aber ich stimme vollkommen zu, dass man ein DVCS verwenden sollte.
Nick Hodges

Machen Sie aus meiner einen DVCS, aber halten Sie die homöomorphen Endofunktoren, die die Untervielfalt eines Hilbert-Raums abbilden, bitte. Ergo, Mercurial.
Warren P

11

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.


7

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.


5

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.

2
Ich bin gespannt, wie Sie sich gefühlt haben, als Ihr Workflow für fast alle Entwicklungsarbeiten auf Visual Studio beschränkt war. Mussten Sie auch die Infrastruktur für TFS einrichten? Meine Erfahrung war in dieser Hinsicht anders als Ihre: # 1 - VCS war nicht einfach zu bedienen, oft flockig und der Offline-Modus wurde von Satan selbst erstellt. # 2 Das integrierte Task- und Bug-Tracking war im Vergleich zu anderen Tools umständlich, so dass # 3 für uns irrelevant war und doppelte Arbeit erzeugte. Ich habe es jetzt drei Mal verwendet und jedes Mal die gleichen schlechten Ergebnisse erzielt.
Jordanien

1. Ich bin mit dem Offline-Modus einverstanden. Ich hatte zwar online nicht viele Probleme, aber ich bin immer verbunden. Viele der VCS-Steuerelemente, insbesondere bei der Neuzuordnung von Ordnern, sind tatsächlich tief in den Menüs verborgen. Ist das das Problem, das Sie haben? 2. Es ist definitiv umständlicher, spart aber insgesamt Arbeit für mein in Project Server integriertes Team. 3. Wie wird eine doppelte Arbeit erstellt? Duplizieren Sie die Aufgaben in Project Server und TFS? Es gibt ein Open Source-Plugin für 2007 und eine Beta für 2010, mit der sie miteinander synchronisiert werden können.
Ryan Hayes

1
Es hat mich auf VS eingeengt, aber wir sind ein totaler .NET-Shop. Ich verwende TFS jedoch bei meinen Java-Projekten zu Hause. Probieren Sie SVNBridge unter svnbridge.codeplex.com aus, mit dem Sie Tortoise mit TFS verwenden können. Wenn Sie Tortoise verwenden (wie die meisten Java-, Ruby- und Nicht -.net-Benutzer), sollte es Ihnen bei der Arbeit in anderen Projekten helfen.
Ryan Hayes

4

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.


1
Wenn nur der Kommentar zu VSS ein Witz wäre ... meide wie die Pest.
DevSolo

Ah, PVCS, die Erinnerungen, die zurückbringen :) Was für ein Stück Müll das war.
Henry

Diese Liste erinnerte mich an die Sprache "Schieß dich in den Fuß". +1
Orbling

Ich erinnere mich an schlechte Dinge über SCCS, aber es war allgemein verwendbar. Ich erinnere mich, dass ich versucht habe, mit SCCS und anderen Programmierern gleichzeitig an Dateien zu arbeiten, und deshalb habe ich mich in CVS verliebt, als ich es sah.
David Thornley

Visual SourceSafe, ein VCS speziell für Programmierer, die sich mit Löffeln die Augen ausstechen wollen .
Mark Booth

2

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.


1

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.


1

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.


Beamer! Während einer Teilzeitbeschäftigung am College habe ich eine (ausgetrickste) Version davon verwendet. Gute Zeiten.
RyanWilcox

0

RCS - Revisionskontrollsystem

Solocodierung so einfach gemacht.


Du machst Witze, oder Xepoch? Bitte, Gott scherze.
Marc W

Ihr bringt mich zum Lachen. Eigentlich benutze ich RCS aber NUR für meine persönlichen Webseiten, & c. Ich habe auf halbem Weg Spaß daran gemacht, es für die Hauptentwicklung zu verwenden, ABER ich habe gesehen, dass es auf Unix-Systemen für die gemeinsame Entwicklung ausschließlich verwendet wird (und nicht CVS). Ehrlich gesagt hatten wir überhaupt keine Probleme damit, aber es eignet sich NICHT für etwas anderes als eine einzelne Serverfunktion.
Warteschlange

1
@Xepoch, vielleicht lernst du besser Git oder Mercurial - DCVS eignet sich hervorragend für die Solo-Entwicklung.
Fishtoaster

1
Wissen Sie, was das Schöne an RCS ist? Sie können alle Ihre RCS, v-Dateien in einer geeigneten Verzeichnisstruktur ablegen, und Sie haben ein CVS-Repository, das fast einsatzbereit ist. Es gibt viele Tools, mit denen Sie CVS in ein beliebiges modernes System wie Mercurial konvertieren können.
David Thornley

@Xepoch, die einfache Möglichkeit, verteilte vcs zu sichern, ist unschlagbar.

0

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.


0

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.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.