GIT vs.Perforce - Zwei VCS geben wird... man wird verlassen [geschlossen]

https://stackoverflow.com/questions/222782

03-07-2019
|

Frage

Also ich bin in den Prozess der Einführung GIT verkauft bei der Arbeit.Erste, was ich brauche, ist, jeden davon zu überzeugen, dass GIT ist besser auf, was Sie bereits tun.Wir verwenden derzeit Notgedrungen.Jemand anderes gehen durch eine ähnliche Verkauf?Jeder gute links/Beratung?

Einer der großen Siege ist, dass wir können Arbeit mit Sie es vom Netz getrennt.Ein weiterer Sieg IMO ist die Art und Weise Hinzugefügt/Check-out verarbeitet werden.Mehr Punkte sind herzlich willkommen!Auch wir haben über 10-20 devs total.

Lösung

Der Perl 5-Interpreter Quellcode befindet sich derzeit in den Wirren von Perforce der Umwandlung zu git. Vielleicht Importeur Sam Vilain des git-p4raw von Interesse ist.

Auf jeden Fall einer der wichtigsten Siege Sie gehen über alle zentralen VCS haben und die meisten auch verteilt diejenigen ist roh, blasenbild Geschwindigkeit . Sie können sich nicht vorstellen, wie befreiend es ist, die gesamte Projektentwicklung bei der Hand, nur Bruchteile von Bruchteilen einer Sekunde entfernt haben, bis Sie es erlebt haben. Selbst Erzeugung Geschichte ein Commit-Log des gesamten Projekts, die eine vollständige diff enthält für jede begehen kann in Bruchteilen einer Sekunde gemessen werden. Git ist so schnell, Ihr Hut fliegen wird. VCS, die einfach über das Netzwerk Roundtrip haben keine Chance hat, im Wettbewerb, nicht einmal über eine Gigabit-Ethernet-Verbindung.

Auch git macht es sehr einfach sorgfältig selektiv bei Commits machen, wodurch Änderungen in der Arbeitskopie (oder sogar innerhalb einer einzigen Datei) verteilt über mehrere Commits werden - und in den verschiedenen Zweigen, wenn Sie das brauchen. Auf diese Weise können Sie weniger mentale Notizen machen während der Arbeit - Sie müssen so sorgfältig Ihre Arbeit nicht planen, zu entscheiden, was vorne Satz von Änderungen werden begehen Sie und sicherstellen, dass irgendetwas anderes zu verschieben. Sie können nur Änderungen vornehmen Sie, wie sie sich auftreten wollen, und sie noch entwirren - fast immer ganz einfach - wenn es Zeit ist, zu begehen. Das Versteck hier eine sehr große Hilfe sein kann.

Ich habe das zusammen gefunden, diese Tatsachen Ursache ich natürlich viel mehr und viel gezieltere Commits als zu machen, bevor ich verwenden git. Dies wiederum macht nicht nur Ihre Geschichte im Allgemeinen nützlich, aber ist besonders vorteilhaft für Werkzeuge Value-Add wie git bisect .

Ich bin sicher, es gibt mehr Dinge, die ich von diesem Augenblick nicht denken. Ein Problem mit dem Vorschlag Ihr Team auf git des Verkaufens ist, dass viele Vorteile miteinander verbunden sind und sich gegenseitig auszuspielen, wie ich oben angedeutet, so dass es schwierig ist, einfach in einer Liste der Funktionen aussehen und Vorteile von git und schließen, wie sie werden Sie Ihren Workflow ändern, und die Änderungen bonafide Verbesserungen sein werden. Sie müssen dies berücksichtigen, und Sie müssen auch ausdrücklich darauf hinzuweisen.

Andere Tipps

Ich benutze Notgedrungen bei der Arbeit.Ich habe auch Git verwenden, da möchte ich noch eine form der Versionskontrolle, wenn ich arbeite-code und kann nicht mit dem server verbinden.Nein, versöhnen offline-arbeiten ist einfach nicht das gleiche.Hier ist, wo ich gefunden habe git ein großer Vorteil:

Verzweigung-speed - git dauert ein paar Sekunden.
Konflikte - P4Merge ist automatisch beheben zerstört eine Woche im Wert von Arbeit einmal.Seit dann würde ich eher beheben von hand bei der Zusammenführung.Wenn Git fordert mich über einen Konflikt, ist es eigentlich ein Konflikt.Den rest der Zeit, git löst Sachen richtig und ich save heaps of time.
Verfolgen Sie führt - Wenn Sie haben ein Zweig kontinuierlich Empfang Zusammenführungen von zwei anderen Branchen, wissen Sie, was ein Kopfschmerz kann dies mit perforce.Mit git, die Kopfschmerzen minimiert, da das Ergebnis eines merge in git ist eigentlich ein neues commit, das weiß, wer seine Vorfahren sind.
Berechtigungen - ich habe den überblick verloren, wie oft ich versucht habe an einer Datei arbeiten, konnte aber nicht, weil es nicht aktiviert wurde, in Perforce.Wenn Sie arbeitete mit XCode (oder einem beliebigen editor, der nicht über eine solide Perforce SCM-plugin) offline, wissen Sie, wie irritierend diese bekommen können.Ich don ' T haben zu befürchten, dass mit Git.Ich meine änderungen vorzunehmen.Git hält mich nicht und verfolgt Sie in den hintergrund.
Halten Sie die wichtigsten Baum ordentlich Mit git kann ich Sortiere meine verpflichtet und ordentlich den code so einrichten, dass die Geschichte sieht nett und ordentlich.Keine, die "überprüfung in dieser Datei, denn es war eigentlich ein Teil der früheren checkin" Quatsch.Ich squash begeht, wie der, die, weil Sie helfen, niemand.
Stashing - Ihrem perforce-server muss version 2010.1 oder neuer) verwenden Sie die p4-Regal-Befehl.
Patches erstellen - Einfach im git.Weiß nicht, ob es möglich ist Auch ohne Verwendung der Befehlszeile.
Mailing-patches von der GUI - wieder, git gewinnt hier.
Speicherplatz - Mit perforce, jeder Zweig ist eine Kopie.Das bedeutet, dass, wenn Ihre Quell-Baum ist riesig, Ihr Speicherplatz wird gegessen bis schnell.Dies ist nicht einmal zählen, den zusätzlichen Platz, sobald Sie mit dem Bau beginnen.Warum haben Sie sogar eine Verknüpfung zwischen Zweigen und Speicherplatz?Mit git können Sie 100 Niederlassungen und nur einen Zweig zu einem Zeitpunkt immer existiert.Wenn Sie möchten gezielt arbeiten an zwei Versionen gleichzeitig können Sie Klonen, machen Ihre Arbeit, und dann loszuwerden von einem Klon, wenn Sie wollen, ohne etwas zu verlieren.
Wenn Sie auf XCode4, perforce-support wurde fallen gelassen, und git-Unterstützung ist nun eingebaut.Wenn Sie cross-Plattform arbeiten, wie ich es Tue, das eine Menge Fragen.Mit Visual Studio verwenden, können Sie git extensions.Mit perforce, es ist auch igitt, die auf beiden Betriebssystemen.Na ja, vielleicht ein wenig mehr auf dem mac jetzt mit XCode4 auf die Szene.
Zu finden, die fehlerhafte checkin (oder git halbieren Regeln) - Jemals versucht zu tun, eine binäre Suche mit perforce, um herauszufinden, wo ein Fehler eingeführt wurde?Ziemlich umständlich, ja?Noch mehr ärger, wenn es wurden integriert, die aus anderen Branchen in die Mitte.Warum?Weil es keine Automatisierung für solche Aufgaben.Sie brauchen, um schreiben Ihre eigenen Tools zu sprechen, perforce und Sie haben normalerweise nicht die Zeit.Mit git, Sie geben Sie die Start-Punkte (die "guten" Punkt-und der "schlecht" - Punkt) und automatisiert die Suche für Sie.Noch besser, wenn Sie haben ein Skript, dass können automatisieren build-und test-Prozess, können Sie git-hook-up auf dem Skript und den gesamten Prozess des Findens der Check-in ist automatisiert.Das ist, wie es sein sollte.
Tracking changes in refactors - teilen Sie BigClass in SmallClass1 und SmallClass2.Auf Perforce, BigClass hat jetzt aufgehört zu existieren, und zwei neue Klassen (SmallClass1 und SmallClass2 haben sich den Quellcode).Auf Perforce, es besteht kein Zusammenhang zwischen BigClass und SmallClass1 und SmallClass2.Git, auf die andere hand, ist smart genug, um zu wissen, dass x% der BigClass ist jetzt in SmallClass1 und y% von BigClass ist in SmallClass2 und BigClass hat aufgehört zu existieren.Nun, aus der Sicht von jemandem, der Beurteilung von Veränderungen über mehrere Niederlassungen, sagen Sie mir, welche Vorgehensweise würden Sie finden weitere nützliche - Git oder Perforce ist.Ich persönlich bevorzuge Git ' s Ansatz, da es genauer spiegelt die tatsächliche änderung im code.Git ist in der Lage, dies zu tun, weil es Spuren Inhalte in der Datei und nicht die Datei selbst.
Zentral oder dezentral:Git ist ein DVCS system, während man sich zwangsläufig zentralisiert.Eine zentralisierte VCS nicht dezentral später, aber ein DVCS (insbesondere git) zentralisiert werden kann.Es gibt verschiedene Produkte, fügen Sie sehr feinkörnige Zugriffskontrolle auf git, wenn das ist etwas, was das Unternehmen braucht.Ich persönlich würde mit einem system, das gibt mir mehr Flexibilität in der langen Begriff.
Zweig Zuordnungen:Wenn Sie wollen zu tun Verzweigung rechts in Perforce, müssen Sie zum erstellen einer Zweig-mapping.Es gibt Gründe für diese, aber Sie sind verbunden, wie Perforce entwirft ein Zweig.Als Entwickler oder ein team, das bedeutet einfach, einen Schritt mehr in die Arbeit fließen, das halte ich nicht für effizient auf allen.
Sharing-Arbeit zwischen den teams:Mit Perforce, Sie kann nicht brechen, eine Vorlage.Team A arbeitet auf feature-A.Team B feature-B.Team C arbeitet auf bug-fixes.Nun, Teams A und B haben fix ein paar bugs damit der Umsetzung Ihrer features.Die einzige Sache ist, Sie waren nicht so diszipliniert beim Begehen Ihrer änderungen (wahrscheinlich, weil Sie sind hetzen, um einen Termin) und damit Ihre "bug fixes" sind Teile von größeren Veröffentlichungen, die enthalten auch neue Sachen, die so weit wie Versionskontrolle auf Ihre äste betroffen sind.Jedoch, Team-C ist jetzt eine point-release und möchte die Fehlerkorrekturen aus den anderen teams.Wenn Sie mit Git, Team-C könnte cherry-pick die anderen teams, die' relevanten Veränderungen, zu trennen und nur das nehmen, was Sie brauchten, ohne sich Gedanken über die Einführung einer teilweise implementierten features.Mit Perforce, Team C können die betroffenen Dateien, aber Sie würde haben zu trennen die relevanten änderungen mit einem viel mehr manuelle Prozess.
Ändern Plattform - Wenn, für was auch immer Grund, Sie in der Zukunft, entscheiden Sie ändern Ihre Plattform der Wahl, mit Perforce sind, sind Sie an der Gnade der Perforce.com und die Verfügbarkeit des tools für die Plattform Ihrer Wahl.
Wechsel auf die Zukunft erstaunlich, source control Motor X - Wenn Sie sich entscheiden, um zu ändern, was du für die Quellcodeverwaltung, extrahieren Sie Ihre Quelle Steuerung Geschichte von Perforce und bewegen es zu einem neuen system X werde zu einem Alptraum, denn es ist closed source und das beste Sie tun können, ist zu erraten - nur Google für Perforce auf Git migration zu bekommen ein Gefühl von dem, was ich bin reden über.Zumindest mit Git, offen Quelle, damit es beseitigt viel von dem Rätselraten beteiligt.

Nun, das ist meine 2 Cent.In Perforce Verteidigung, ich muss sagen, Ihre Kunden-support-Regeln-und so Ihre Time-Lapse-View-tool.Ich weiß nicht, wie man ein Zeitraffer-Ansicht mit git.Aber für die Bequemlichkeit und Zeitersparnis, würde ich gehen mit git jeden Tag.

Es würde eine Menge Überzeugungs nehmen mich von notgedrungen zu wechseln. In den beiden Unternehmen war ich es benutzt es mehr als ausreichend. Das waren die beiden Unternehmen mit unterschiedlichen Büros, aber die Büros wurden mit vieler Infrastruktur aufgebaut, so gibt es keine Notwendigkeit, die disjunkt / getrennt Eigenschaften haben sollte.

Wie viele Entwickler reden Sie Umstellen?

Die eigentliche Frage ist - was ist es über notgedrungen, dass Ihre Organisation ist nicht Bedürfnisse zu erfüllen, die git bieten kann? Und in ähnlicher Weise, welche Schwächen hat git haben im Vergleich zu notgedrungen? Wenn Sie nicht antworten, dass sich dann hier gefragt wird nicht helfen. Sie benötigen einen Business Case für Ihr Unternehmen zu finden. (Z Vielleicht ist es mit geringer Gesamtbetriebskosten ist (das schließt Produktivitätsverlust für die Zwischenlernphase, höhere Verwaltungskosten (zumindest anfangs) usw.)

Ich glaube, Sie in für eine harte verkaufen sind - notgedrungen ein ziemlich gut ist, zu versuchen zu ersetzen. Es ist ein Klacks, wenn Sie zu booten aus pvcs oder SSAFE versuchen.

Ich denke, in Bezug auf den Menschen glücklich während / Post wechseln, eines der Dinge zu halten früh zu vermitteln ist nur, wie privat eine lokale Niederlassung in Git sein kann und wie viel Freiheit, gibt ihnen Fehler zu machen. Holen sie sich alle ein paar privaten Zweige aus dem aktuellen Code zu klonen und dann dort wild gehen, zu experimentieren. Benennen Sie einige Dateien, überprüfen Sachen in, fusionieren die Dinge aus einem anderen Zweig, Geschichte Zurückspulen, rebase eine Reihe von Änderungen auf den anderen, und so weiter. Zeigen Sie, wie auch ihre schlimmsten Unfälle vor Ort keine Folgen für ihre Kollegen haben. Was Sie wollen, ist eine Situation, in der Entwickler sicher fühlen, so können sie lernen schneller (da Git eine steile Lernkurve hat, die wichtig ist) und dann schließlich so dass sie effektiver als Entwickler sind.

Wenn Sie versuchen, ein zentrales Tool zu lernen, natürlich werden Sie besorgt über einige Patzer machen, die Probleme für andere Benutzer des Repository verursacht. Die Angst vor Verlegenheit allein ist genug, um die Menschen davon abzuhalten, zu experimentieren. Auch eine spezielle „Ausbildung“ Repository helfen, die nicht, weil zwangsläufig werden die Entwickler eine Situation, in dem Produktionssystem begegnen, dass sie nie im Training gesehen, und so sind sie wieder zu sorgen.

Aber Gits verteilte Natur tut mit diesem weg. Sie können in einem lokalen Zweig jedes Experiment versuchen, und wenn es schief geht, werfen nur den Zweig weg und niemand muss wissen. Da Sie eine lokale Niederlassung von etwas schaffen können, können Sie ein Problem replizieren Sie mit dem realen Live-Repository sind zu sehen, aber keine Gefahr, „bricht die Build“ oder sonst einen Narren machen. Sie können absolut alles in, überprüfen, sobald Sie es getan haben, nicht bis in die nette kleine Pakete zu Batch-Arbeit zu versuchen. Also nicht nur die beiden großen Code ändern Sie vier Stunden heute verbrachten, sondern auch, dass Build-Update, das Sie auf halbem Weg durch erinnerten, und die Rechtschreibfehler in der Dokumentation, die Sie während etwas an einen Kollegen zu erklären entdeckt, und so weiter. Und wenn die großen Veränderungen aufgegeben werden, weil das Projekt Richtung ändert, können Sie Kirsche die Build-Fix auswählen und die Rechtschreibfehler aus Ihrer Branche und so alle ohne Ärger.

Der Befehl, der mich auf git verkauft persönlich war bisect . Ich glaube nicht, dass diese Funktion in einem anderen Versionskontrollsystem ab sofort zur Verfügung steht.

Dass gesagt wird, wenn die Menschen zu einem GUI-Client verwendet werden, für die Quellcodeverwaltung sie sein wird beeindruckt nicht mit git. Im Augenblick ist die einzige voll funktionsfähige Client-Befehlszeile.

Was Perforce-Funktionen sind die Menschen?

Mehrere Workspaces auf einer einzigen Maschine
Nummerierte Änderungslisten
Entwicklerzweige
Integration mit IDE (Visual Studio, Eclipse, SlickEdit, ...)
Viele Build-Varianten
Composite-Workspaces
einige Korrekturen Integration, andere aber nicht
etc

ich frage, weil, wenn alle Leute ist, tun und von der Kommandozeile gestellt bekommen, git, dass zurückgelegt hat, und so tun, alle anderen RTS.

Offenbar GitHub jetzt bieten git-Schulungen für Unternehmen.Sprach Ihre blog-post über Sie:

I ' ve been down, um die Google-campus eine Anzahl von Zeiten in den letzten paar Wochen, helfen zu Zug die Androiden gibt es in Git.Ich wurde gebeten, die von Shawn Pearce (Sie kennen ihn aus seiner Git und EGit/JGit Ehre – er ist der held, übernimmt die Pflege, wenn Junio ist aus der Stadt) zu kommen, um ihm zu helfen Zug die Google-Ingenieure arbeiten auf Andriod-in übergang von Perforce auf Git, also Android könnten geteilt werden mit die Massen.Ich kann Ihnen sagen, ich war mehr als glücklich, es zu tun.

[…]

Logische Genial ist jetzt offiziell bietet diese Art von benutzerdefinierten training-service für alle Unternehmen, wo wir helfen können Sie Ihre Organisation mit Ausbildung und Planung, wenn Sie denken über den Wechsel zu Git als gut.

Hervorhebung von mir.

Ich habe für eine lange Zeit Perforce gewesen verwendet und seit kurzem auch ich begann GIT zu verwenden. Hier ist meine „objektive“ Meinung:

Perforce Merkmale:

GUI-Tools scheinen mehr funktionsreiche (z Zeitraffer Ansicht, Revision Graph)
Geschwindigkeit, wenn an Kopf Revision Synchronisierung (kein Overhead der ganzen Geschichte zu übertragen)
Eclipse / Visual Studio Integration ist wirklich schön
Sie können pro Changelist mehr Funktionen in einem Zweig entwickeln (Ich bin immer noch nicht zu 100% sicher, ob dies ein Vorteil gegenüber GIT ist)
Sie können „Spion“, was andere Entwickler tun - welche Art von Dateien, die sie haben ausgecheckt

GIT Funktionen:

habe ich Eindrücke, die GIT Kommandozeile viel einfacher als Perforce ist (init / Klon, hinzufügen, begehen. Keine Konfiguration komplexer Workspaces)
Geschwindigkeit, wenn Projekthistorie nach einer Kasse Zugriff (kommt zu einem Preis von Kopieren ganze Geschichte bei der Synchronisierung)
Offline-Modus (Entwickler nicht darüber beschweren, dass nicht erreichbar P4 Server sie von Codierung verbieten wird)
einen neuen Zweig zu schaffen, ist viel schneller
Der „main“ GIT-Server muss nicht viel TByte Speicherplatz, da jeder Entwickler kann seine eigene lokale Sandbox
GIT ist Open Source - keine Lizenzgebühren
Wenn Sie Ihr Unternehmen wird auch auf Open Source-Projekte beitragen dann Patches Sharing ist viel viel einfacher, mit GIT

Insgesamt für Open Source / Verteilen Projekte würde ich immer GIT empfehlen, weil es mehr wie eine P2P-Anwendung und jeder ist in der Entwicklung teilnehmen. Zum Beispiel, ich erinnere mich, dass, wenn ich die Remote-Entwicklung mit Perforce tat ich der Synchronisierung 4GB Projekte über 1 Mbps Link einmal in der Woche. Alot der Zeit wurde einfach dadurch verschwendet. Auch mussten wir VPN einrichten, das zu tun.

Wenn Sie ein kleines Unternehmen und P4 Server werden immer sein, dann würde ich sagen, dass Perforce ist auch eine sehr gute Option.

Wir haben irgendwann für Git benutzen, die vor kurzem unseres Git Servers Festplatte abgestürzt und wir konnten nicht wieder auf den neuesten Stand zurück. Wir haben es geschafft wieder auf wenige Tage alten Zustand zu erhalten. Wann war der Server wieder nach oben. Jeder im Team gezogen / geschoben ihre Änderungen und voila, der Server zurück zu dem aktuellen Zustand.

Der ein wichtiger Unterschied zwischen Perforce und git (und die am häufigsten erwähnte) ist, die jeweilige Handhabung großer Binärdateien.

Wie zum Beispiel in diesem Blog eines Mitarbeiters bei einem Videospiel-Entwicklung Unternehmen: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

Allerdings ist das Wichtigste, dass die Drehzahldifferenz zwischen git und notgedrungen, wenn Sie eine riesige 6gb Repository haben, alles von der Dokumentation zu jedem binären je gebaut (und schließlich, oh ja! Die eigentliche Quelle der Geschichte), enthält in der Regel kommt von der Tatsache, dass große Unternehmen neigen dazu, Perforce zu laufen, und so es sie eingerichtet alle wesentlichen Vorgänge der großen Server Bank im Keller abzuladen.

Dieser wichtige Vorteil auf einen Teil von Perforce kommt nur von einem Faktor, der mit Perforce rein gar nichts zu tun hat, die Tatsache, dass das Unternehmen ausgeführt wird, kann es die Server-Bank leisten.

Und wie auch immer, am Ende, Perforce und git sind verschiedene Produkte. Git wurde entwickelt, nur ein VCS zu sein, und es tut dies viel besser als Perforce (in, dass es verfügt über mehr Features, die in der Regel einfacher zu bedienen ist, insbesondere in den Worten eines anderen, in Perforce Verzweigung wie die Durchführung am offenen Herzen Chirurgie, es sollte nur von Experten durchgeführt werden: P) ( http://stevehanov.ca/ Blog / index.php? id = 50 )

Jede andere Vorteile, die Unternehmen, die Perforce Gewinn verwenden nur gekommen, weil Perforce nicht nur ein VCS ist, es ist auch ein File-Server, sowie eine Vielzahl von anderen Funktionen, die die Leistung der Builds für die Prüfung, etc.

Endlich:. Git ist Open-Source und weitaus flexibler zu booten, wäre es nicht so schwer zu Patch git sein, um wichtige Operationen an einen zentralen Server Offload, Berge von teurer Hardware läuft

Ich denke, das einzige, was ich weiß, GIT gewinnt an ist seine Fähigkeit, auf alle Dateien „Zeilenenden zu bewahren“, während notgedrungen sie zu bestehen scheint auf die Übersetzung in entweder Unix, DOS / Windows-oder MacOS9-Format ( „\ n“ "\ r \ n" oder „\ r).

Dies ist ein echten Schmerzen, wenn Sie Unix-Skripte in einer Windows-Umgebung oder eine gemischte OS-Umgebung gerade schreiben. Es ist nicht einmal möglich, die Regel auf einer Pro-Datei-Erweiterung Basis einzustellen. Zum Beispiel wäre es .sh, .bash, .unix Dateien in Unix-Format und konvertiert .ccp, .bat oder .com-Dateien in DOS / Windows-Format konvertieren.

In GIT (Ich bin nicht sicher, ob das standardmäßig eine Option oder die einzige Option) Sie es einrichten können bis zu „Zeilenende bewahren“. Das bedeutet, können Sie manuell die Zeilenende einer Datei ändern, und dann wird GIT verlassen, dass Format, wie es ist. Dies scheint mir wie der ideale Weg, um Dinge zu tun, und ich verstehe nicht, warum dies keine Option mit Perforce ist.

Die einzige Möglichkeit, dieses Verhalten zu erreichen, ist es, die Dateien als binär zu markieren. Wie ich sehe, dass, wäre das ein gemeiner Hack eine fehlende Funktion zu umgehen. Abgesehen davon, dass langweilig zu haben, auf alle Skripte zu tun, etc, wäre es wahrscheinlich auch die meisten diffs brechen, etc.

Die „Lösung“, die wir für zur Zeit angesiedelt, ist ein sed Befehl auszuführen alle Zeilenumbrüche aus den Skripten zu entfernen, jedesmal wenn sie auf ihre Unix-Umgebung bereitgestellt sind. Dies ist auch nicht ideal, zumal einige von ihnen sind in WAR-Dateien bereitgestellt und die Sed Linie wieder zu laufen, wenn sie ausgepackt sind.

Das ist nur etwas, was ich denke, gibt GIT einen großen Vorteil, und das glaube ich nicht, wurde oben erwähnt.

EDIT: Nach Perforce für ein bisschen länger mit gewesen, ich möchte noch ein paar Kommentare hinzufügen:

A) Etwas, das ich wirklich in Perforce fehlt, ist eine klare und Instanz diff, einschließlich geändert, entfernt und Dateien hinzugefügt. Das in GIT mit dem git diff Befehl zur Verfügung steht, aber in Perforce, Dateien ausgecheckt werden, bevor ihre Änderungen aufgezeichnet werden, und während Sie Ihre Haupt-Editoren (wie Eclipse) gesetzt haben könnten bis zu überprüfen Dateien automatisch aus, wenn Sie sie bearbeiten, Sie könnten manchmal Dateien auf andere Weise bearbeiten (Notizblock, Unix-Befehle, etc.). Und neue Dateien scheinen nicht automatisch überhaupt aufgenommen werden, auch mit Eclipse und p4eclipse, was ziemlich lästig sein kann. So alle Änderungen zu finden, haben Sie einen „Diff gegen ...“ über den gesamten Arbeitsbereich laufen, die vor allem eine Weile dauert, zu laufen und schließen zweitens alle Arten von irrelevanten Dingen, wenn Sie sehr komplizierte Ausschlusslisten einrichten, das führt mich zum nächsten Punkt.

B) In GIT ich die .gitignore sehr einfach und leicht zu verwalten finden, lesen und verstehen. Allerdings ignoriert der Arbeitsbereich / Ausschlusslisten konfigurierbar in Perforce scheinen unhandlich und unnötig komplex. Ich habe nicht in der Lage gewesen, keine Ausschlüsse zu bekommen mit Wildcards arbeiten. Ich möchte wie etwas tun

-//Server/mainline/.../target/...   //Svend_Hansen_Server/.../target/...

Um alle Zielordner in allen Projekten innerhalb Server / Fern auszuschließen. Allerdings scheint dies nicht zu arbeiten, wie ich es erwartet hätte, und ich habe eine Zeile hinzufügen für jedes Projekt endete wie:

-//Server/mainline/projectA/target/...  //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/...  //Svend_Hansen_Server/projectB/target/...
...

Und ähnliche Zeilen für Bin-Ordner, .classpath und .projet Dateien und vieles mehr.

C) In Perforce gibt es die eher nützlich Änderungslisten. Allerdings gehe ich davon aus, eine Gruppe von Änderungen vornehmen, überprüfen Sie sie alle und sie in einer Änderungsliste setzen, um dann auf etwas anderes zu arbeiten, bevor diese Änderungsliste einreichen. Wenn ich später eine Änderung an einen der in der ersten Änderungsliste enthaltenen Dateien machen, wird die Datei in dieser Änderungsliste immer noch, und ich kann nicht nur später legt die Änderungs davon aus, dass es nur die Änderungen enthält, die ich ursprünglich hinzugefügt (obwohl es die gleichen Dateien sein). In GIT, wenn Sie eine Datei hinzufügen und weitere Änderungen vornehmen, werden diese Änderungen hinzugefügt wurden nicht (und würden zeigen, immer noch in einem git diff und Sie würden die Datei zu begehen, ohne zuerst das Hinzufügen der nicht in der Lage sein,sowie neue Änderungen. Natürlich ist dies nicht auf die gleiche Weise usefull die Änderungsliste nur, wie Sie einen Satz von Dateien hinzugefügt haben sein kann, aber in GIT können Sie nur die Änderungen zu übernehmen, wie das eigentlich nicht, sie schiebt. Man könnte sie auf andere Veränderungen arbeiten, bevor sie drängen, aber Sie würden nicht in der Lage sein, etwas anderes zu schieben, die Sie später hinzufügen, ohne auch die früheren Veränderungen zu drängen.

Ich habe keine Erfahrung mit Git, aber ich habe mit Mercurial, die VCS auch ein verteiltes ist. Es hängt von dem Projekt wirklich, aber in unserem Fall ein verteiltes VCS das Projekt geeignet, da im Grunde häufig gebrochene baut eliminiert.

ich denke, es auf dem Projekt hängt wirklich, wie einige besser auf einem Client-Server VCS geeignet sind, und andere Voreilung eine verteilte ein.

Hier ist, was ich nicht über git mögen:

Zunächst einmal denke ich, dass die verteilte Idee angesichts der Realität fliegt. Jeder, git tatsächlich verwenden ist tut dies in einer zentralisierten Weise, auch Linus Torvalds. Wenn der Kernel in einer verteilten Art und Weise verwaltet wurde, würde bedeuten, dass ich konnte nicht wirklich die „offiziellen“ Kernel-Quellen herunterladen - es nicht sein würde - ich hätte entscheiden, ob ich Linus' Version mag, oder Joe-Version, oder Bills Version. Das wäre natürlich lächerlich, und deshalb gibt es eine offizielle Definition, die Linus steuert einen zentralen Workflow.

Wenn Sie annehmen, dass Sie eine zentrale Definition Ihrer Sachen wollen, dann wird deutlich, dass die Server- und Client-Rollen völlig unterschiedlich sind, so das Dogma, dass die Client- und Server-Software das gleiche sein sollte wird rein zu begrenzen. Das Dogma, dass die Client- und Server- Daten sollten gleich sein wird einfach lächerlich, vor allem in einer Code-Basis, die 15 Jahre der Geschichte bekommt ist, dass niemand kümmert sich um, aber jeder würde klonen müssen.

Was wir wollen eigentlich mit all den alten Sachen zu tun ist, Spund es in einem Schrank und vergisst, dass es da ist, genau wie jeder normaler VCS tut. Die Tatsache, dass git schleppt sie alle hin und her über das Netzwerk jeden Tag ist sehr gefährlich, weil es Ihnen nörgelt es zu beschneiden. Das Beschneiden erfordert eine Menge langweiliger Entscheidungen und es kann schief gehen. So halten die Menschen wahrscheinlich eine ganze Reihe von Snapshot-repos von verschiedenen Punkten in der Geschichte, aber es war nicht das, was die Quellcodeverwaltung war in erster Linie? Dieses Problem gab es nicht, bis jemand das verteilte Modell erfunden.

Git fördert aktiv die Menschen Geschichte neu zu schreiben, und der oben ist wahrscheinlich ein Grund dafür. Jeder normale VCS macht aber die Admins Geschichte unmöglich für alle Umschreiben, und stellt sicher, dass die Admins haben keinen Grund, es zu betrachten. Korrigieren Sie mich, wenn ich falsch liege, aber soweit ich weiß, git bietet keine Möglichkeit, normale Benutzer Schreibzugriff zu gewähren, sondern sie aus Umschreiben der Geschichte zu verbieten. Das bedeutet, dass jeder Entwickler mit einem Groll (oder wer war noch mit der Lernkurve zu kämpfen) könnte die gesamte Code-Basis Müll. Wie ziehen wir, dass man? Nun, entweder Sie machen regelmäßige Sicherungen der gesamten Geschichte, das heißt Sie halten Geschichte quadriert, oder Sie verbieten Schreibzugriff auf alle außer einem armen sod, der alle diffs per E-Mail erhalten würde und kombiniere sie mit der Hand.

Nehmen wir ein Beispiel für ein gut finanziertes, großes Projekt und sehen, wie git ist für sie arbeiten: Android. Ich beschloss, einmal selbst ein Spiel mit dem Android-System zu haben. Ich fand heraus, dass ich angeblich Repo an ihren git zu erhalten genannt eine Reihe von Skripten zu verwenden. Einige von Repo läuft auf dem Client und einige auf dem Server, aber beide durch ihre Existenz, werden veranschaulicht die Tatsache, dass git in jeder Kapazität unvollständig ist. Was passiert ist, dass ich nicht in der Lage war, die Quellen für etwa eine Woche zu ziehen und gab dann ganz auf. Ich würde eine wirklich große Menge an Daten aus mehreren verschiedenen Repositories ziehen musste, aber der Server wurde vollständig mit Leuten wie ich überlastet. Repo war Timing und kam nicht wieder aufnehmen, wo sie abgelaufen war. Wenn git so verteilbar ist, würden Sie gedacht haben, dass sie eine Art von Peer-to-Peer-Sache getan haben würde, die Last auf, dass ein Server zu entlasten. Git ist verteilbar, aber es ist kein Server. Git + Repo ist ein Server, aber Repo ist nicht verteilbar cos es ist nur eine Ad-hoc-Sammlung von Hacks.

Eine ähnliche Darstellung von git der Unzulänglichkeit ist gitolite (und seine Vorfahren, die offenbar nicht so gut funktioniert.) Gitolite beschreibt seine Arbeit als die Bereitstellung eines git-Server zu erleichtern. Auch hier erweist sich die Existenz dieser Sache, dass git kein Server ist, sowenig es ein Client ist. Was mehr ist, wird es nie sein, denn wenn es in wächst entweder es wäre es Grundprinzipien werden verraten.

Auch wenn Sie in der verteilten Sache glaubten, git wäre immer noch ein Chaos sein. Was für instance, ist ein Zweig? Sie sagen, dass Sie implizit ein Zweig machen jedes Mal, wenn ein Repository zu klonen, aber das kann nicht das gleiche wie ein Zweig in einem einzigen Repository sein. So ist, dass mindestens zwei verschiedene Dinge als Zweig bezeichnet werden. Aber dann können Sie auch in einem Repo zurückspulen und nur die Bearbeitung beginnen. Ist das wie die zweite Art von Zweig, oder etwas anderes wieder? Vielleicht hängt es, welche Art von Repo was du hast - oh ja - offenbar das Repo entweder kein klares Konzept ist. Es gibt normale Einsen und kahlen. Sie können nicht auf einen normalen schieben, weil der blanken Teil nicht synchron mit dem Quellbaum bekommen könnte. Aber man kann nicht auf eine bloße cos cvsimport sie nicht gedacht haben. Also muss man auf einen normale cvsimport, Klon, dass auf einen bloßen die Entwickler treffen, und cvsexport, dass zu einer cvs Arbeitskopie, die noch in cvs überprüft werden muss. Wer kann gestört werden? Wo haben all diese Komplikationen kommen? Von der verteilten Idee selbst. Ich ditched gitolite am Ende, weil es noch mehr dieser Beschränkungen für mich aufzuzwingen.

Git sagt, dass Verzweigung sollte leicht sein, aber viele Unternehmen haben bereits ein ernsthaftes Schelm Zweig Problem so würde ich, dass Verzweigung gedacht haben sollte eine folgenschwere Entscheidung mit strengen Polizei sein. Dies ist, wo notgedrungen wirklich glänzt ...

In notgedrungen müssen Sie selten Zweige, weil Sie Changesets in einem sehr agilen Art und Weise jonglieren kann. Zum Beispiel ist die übliche Workflow, dass Sie an die letzte bekannte gute Version auf Fern synchronisieren, dann Funktion schreiben. Jedes Mal, wenn Sie versuchen, eine Datei zu ändern, wird der Unterschied dieser Datei auf Ihrem „default changeset“ hinzugefügt. Wenn Sie in der changeset zu überprüfen versuchen, es versucht automatisch, die Nachricht von den wichtigen in Ihr changeset zu fusionieren (Rebasing es effektiv) und begeht dann. Dieser Workflow wird erzwungen, ohne dass Sie es verstehen zu müssen. Magistrale sammelt so eine Geschichte von Veränderungen, die Sie ganz einfach Kirsche Ihren Weg durch später holen. Zum Beispiel: Angenommen, Sie ein altes zurückkehren wollen, sagen wir, die man vor dem vorletzten. Sie synchronisieren zu dem Moment vor der säumigen Änderung, die betroffenen Dateien als Teil des changeset markieren, bis zu dem Moment synchronisieren nach und verschmelzen mit „immer mine“. (Es war etwas sehr interessant dort. Syncing bedeutet nicht das Gleiche mit - wenn eine Datei bearbeitet werden kann (dh in einem aktiven changeset) wird es nicht durch die Sync-verprügelt werden, sondern markiert als Grund für die Auflösung) Jetzt haben Sie eine Änderungsliste, die die säumige einem rückgängig macht. Merge in der nachfolgenden Nachrichten und Sie haben eine Änderungsliste, die Sie auf der Hauptstrecke plop kann die gewünschte Wirkung zu haben. Zu keinem Zeitpunkt haben schreiben wir jede Geschichte.

Nun, auf halbem Weg durch diesen Prozess der Annahme, jemand läuft bis zu Ihnen und sagt Ihnen, alles fallen zu lassen und einige Fehler zu beheben. Sie geben nur Ihre Standard-Änderungsliste einen Namen (eine Zahl tatsächlich), dann „aussetzen“ es, regeln den Bug in die noch leere Standardänderungsliste, begehen sie, und die genannte Änderungsliste fortzusetzen. Es ist typisch mehrere Änderungslisten zu einer Zeit ausgesetzt haben, wo man verschiedene Dinge ausprobieren. Es ist einfach und privat. Sie bekommen, was Sie wirklich von einem Zweig Regime wollen, ohne die Versuchung zu Standard verschleppen oder kneifen die Verschmelzung.

Ich nehme an, es wäre theoretisch möglich sein, etwas Ähnliches in git zu tun, aber git macht praktisch alles möglich, anstatt zu behaupten ein Workflow wir genehmigen. Das zentralisierte Modell ist ein Bündel von gültigen Vereinfachungen in Bezug auf die verteilten Modell, das eine ungültige Verallgemeinerung ist. Es ist so overgeneralised, dass es im Grunde erwartet Sie Source-Control auf es zu implementieren, wie Repo tut.

Die andere Sache ist die Replikation. In git ist alles möglich, so dass Sie es heraus für sich selbst zu werden. In notgedrungen Sie einen effektiv staatenlos Cache erhalten. Die einzige Konfiguration muss es wissen, ist, wo der Meister ist, und die Kunden können entweder an den Master oder den Cache an ihrer Scheibe Punktretion. Das ist fünf Minuten zu Job und es kann nicht schief gehen.

Sie haben auch Trigger und anpassbare Formulare für Code-Reviews zu behaupten, Bugzilla Referenzen usw., und natürlich haben Sie Zweige für, wenn Sie tatsächlich benötigen. Es ist nicht Clearcase, aber es ist in der Nähe, und es ist tot einfach einzurichten und zu pflegen.

Alles in allem denke ich, dass, wenn Sie wissen, dass Sie in einem zentralen Weg zur Arbeit gehen, was jeder tut, dann kann man auch ein Tool, das mit dem im Verstand entworfen. Git ist überbewertet, weil Linus' gefürchteten Witz zusammen mit den Völkern Tendenz einander herum wie Schafe zu folgen, aber seine Haupt raison d'etre eigentlich nicht dem gesunden Menschenverstand stehen, und es folgt, git bindet seine eigenen Hände mit die beiden großen Dogmen, dass (a) die Software und (b) die Daten die gleichen sowohl auf Client und Server sein müssen, und das wird es immer an der zentralen Aufgabe kompliziert und lahm machen.

Mit GIT als Ersatz für schlechtes Code Linienmanagement ist weit verbreitet. Viele der Nachteile von Perforce sind eine Folge der schlechten Verzweigungsstrategien. Das gleiche gilt für jedes anderes zentrales Werkzeug. Wenn Sie eine Tonne Zweige erstellen müssen Sie etwas falsch machen. Warum brauchen Entwickler so viele Zweige erstellen?

Auch, warum arbeitet so wichtig ohnehin getrennt? Nur so kann jemand in einem Zug arbeiten? Das ist so ziemlich der einzige Ort in diesen Tagen kann man nicht über eine drahtlose Verbindung bekommen. Und auch die meisten Züge haben anständige WiFi.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow