GIT vs. Perforce - Zwei VCS werden eintreten ... einer wird verlassen [geschlossen]

Ich bin gerade dabei, GIT bei der Arbeit zu verkaufen. Als erstes muss ich alle davon überzeugen, dass GIT besser darin ist, was sie bereits gewohnt sind. Wir verwenden derzeit Perforce. Hat noch jemand einen ähnlichen Verkauf? Irgendwelche guten Links / Ratschläge?

Einer der großen Vorteile ist, dass wir damit unabhängig vom Netzwerk arbeiten können. Ein weiterer Gewinn IMO ist die Art und Weise, wie Adds / Checkout behandelt werden. Weitere Punkte sind willkommen! Außerdem haben wir insgesamt etwa 10-20 Entwickler.

Der Perl 5-Interpreter-Quellcode durchläuft derzeit die Konvertierung von Perforce nach Git. Vielleicht ist Sam Vilains git-p4rawImporteur von Interesse.

In jedem Fall ist einer der Hauptgewinne, den Sie bei jedem zentralisierten und am meisten verteilten VCS erzielen werden, auch die rohe, rasante Geschwindigkeit . Sie können sich nicht vorstellen, wie befreiend es ist, die gesamte Projektgeschichte zur Hand zu haben, nur Bruchteile von Sekundenbruchteilen, bis Sie sie erlebt haben. Selbst das Generieren eines Festschreibungsprotokolls der gesamten Projekthistorie, das für jedes Festschreiben einen vollständigen Unterschied enthält, kann in Sekundenbruchteilen gemessen werden. Git ist so schnell, dass dein Hut abfliegt. VCSs, die über das Netzwerk runden müssen, haben einfach keine Chance zu konkurrieren, auch nicht über eine Gigabit-Ethernet-Verbindung.

Mit git ist es außerdem sehr einfach, beim Festschreiben sorgfältig auszuwählen, sodass Änderungen in Ihrer Arbeitskopie (oder sogar in einer einzelnen Datei) auf mehrere Festschreibungen verteilt werden können - und bei Bedarf auf verschiedene Zweige. Auf diese Weise können Sie während der Arbeit weniger mentale Notizen machen. Sie müssen Ihre Arbeit nicht so sorgfältig planen, im Voraus entscheiden, welche Änderungen Sie vornehmen möchten, und sicherstellen, dass Sie alles andere verschieben. Sie können einfach alle gewünschten Änderungen vornehmen, sobald sie Ihnen einfallen, und sie dennoch - fast immer ganz einfach - entwirren, wenn es Zeit ist, sich zu verpflichten. Das Versteck kann hier eine sehr große Hilfe sein.

Ich habe festgestellt, dass diese Tatsachen zusammen dazu führen, dass ich natürlich viel mehr und viel fokussiertere Commits mache als zuvor, als ich Git verwendet habe. Dies wiederum macht Ihre Historie nicht nur allgemein nützlicher, sondern ist auch besonders vorteilhaft für Mehrwert-Tools wie z git bisect.

Ich bin mir sicher, dass es noch mehr Dinge gibt, an die ich momentan nicht denken kann. Ein Problem mit dem Vorschlag, Ihr Team auf Git zu verkaufen, besteht darin, dass viele Vorteile miteinander zusammenhängen und sich gegenseitig ausspielen, wie ich oben angedeutet habe, so dass es schwierig ist, einfach eine Liste der Funktionen und Vorteile von Git zu betrachten und daraus zu schließen werden Ihren Workflow ändern, und welche Änderungen werden bonafide Verbesserungen sein. Sie müssen dies berücksichtigen und ausdrücklich darauf hinweisen.

Ich benutze Perforce bei der Arbeit. Ich benutze Git auch, weil ich immer noch eine Form der Versionskontrolle haben möchte, wenn ich an Code arbeite und keine Verbindung zum Server herstellen kann. Nein, Offline-Arbeit in Einklang zu bringen ist einfach nicht dasselbe. Hier habe ich festgestellt, dass Git ein großer Vorteil ist:

1. Verzweigungsgeschwindigkeit - Git dauert höchstens einige Sekunden.
2. Konflikte - Die automatische Lösung von P4Merge hat einmal die Arbeit einer Woche zerstört. Seitdem würde ich beim Zusammenführen lieber von Hand auflösen. Wenn Git mich zu einem Konflikt auffordert, handelt es sich tatsächlich um einen Konflikt. In der restlichen Zeit löst git die Dinge korrekt auf und ich spare jede Menge Zeit.
3. Zusammenführen verfolgen - Wenn Sie einen Zweig haben, der kontinuierlich Zusammenführungen von zwei anderen Zweigen empfängt, wissen Sie, was für Kopfschmerzen dies zwangsläufig sein kann. Mit git werden die Kopfschmerzen minimiert, da das Ergebnis einer Zusammenführung von git tatsächlich ein neues Commit ist, das weiß, wer seine Vorfahren sind.
4. Berechtigungen - Ich habe den Überblick darüber verloren, wie oft ich versucht habe, an einer Datei zu arbeiten, konnte dies jedoch nicht, da sie nicht in Perforce ausgecheckt wurde. Wenn Sie offline mit XCode (oder einem Editor ohne solides Perforce SCM-Plugin) gearbeitet haben, wissen Sie, wie irritierend dies sein kann. Darüber muss ich mir bei Git keine Sorgen machen. Ich nehme meine Änderungen vor. Git hält mich nicht auf und verfolgt sie im Hintergrund.
5. Den Hauptbaum aufgeräumt halten - Mit git kann ich meine Commits sortieren und den Code aufräumen, damit der Verlauf schön und aufgeräumt aussieht. Nichts davon "diese Datei einchecken, weil sie Teil des vorherigen Eincheckvorgangs sein sollte". Ich quetsche solche Commits, weil sie niemandem helfen.
6. Stashing - Ihr Perforce-Server muss Version 2010.1 oder höher sein, um den Befehl p4 Shelve verwenden zu können.
7. Patches erstellen - Einfach in Git zu machen. Ich weiß nicht, ob dies in Perforce ohne Verwendung der Befehlszeile möglich ist.
8. Mailing-Patches von der GUI - auch hier gewinnt git.
9. Speicherplatz - Mit Perforce ist jeder Zweig eine Kopie. Das heißt, wenn Ihr Quellbaum riesig ist, wird Ihr Speicherplatz schnell aufgebraucht. Dies zählt nicht einmal den zusätzlichen Platz, sobald Sie mit dem Bau beginnen. Warum überhaupt eine Verbindung zwischen Zweigen und Speicherplatz? Mit git können Sie 100 Zweige haben und es existiert immer nur ein Zweig. Wenn Sie speziell an zwei Versionen gleichzeitig arbeiten möchten, können Sie klonen, Ihre Arbeit erledigen und dann einen Klon entfernen, wenn Sie möchten, ohne etwas zu verlieren.
10. Wenn Sie mit XCode4 arbeiten, wurde die Perforce-Unterstützung eingestellt und die Git-Unterstützung ist jetzt integriert. Wenn Sie wie ich plattformübergreifend arbeiten, ist dies sehr wichtig. Mit Visual Studio können Sie Git-Erweiterungen verwenden. Mit Perforce ist es auf beiden Betriebssystemen gleich gut. Nun, vielleicht ein bisschen mehr auf dem Mac mit XCode4 in der Szene.
11. Finden des fehlerhaften Eincheckens (oder der Regeln zur Halbierung von Git) - Haben Sie jemals versucht, eine binäre Suche mit Perforce durchzuführen, um herauszufinden, wo ein Fehler aufgetreten ist? Ein ziemlicher Ärger, ja? Noch problematischer, wenn es Integrationen aus anderen Branchen in der Mitte gegeben hat. Warum? Weil es für solche Aufgaben keine Automatisierung gibt. Sie müssen Ihr eigenes Tool schreiben, um notgedrungen zu sprechen, und normalerweise haben Sie keine Zeit dafür. Mit git geben Sie ihm die Startpunkte (den "guten" Punkt und den "schlechten" Punkt) und es automatisiert die Suche nach Ihnen. Noch besser, wenn Sie ein Skript haben, das den Erstellungs- und Testprozess automatisieren kann, können Sie git mit dem Skript verbinden und der gesamte Prozess des Findens des Eincheckens wird automatisiert. So sollte es sein.
12. Verfolgen von Änderungen zwischen Refaktoren - Versuchen Sie, BigClass in SmallClass1 und SmallClass2 aufzuteilen. Für Perforce existiert BigClass nun nicht mehr und zwei neue Klassen (SmallClass1 und SmallClass2 sind dem Quellbaum beigetreten). Für Perforce besteht keine Beziehung zwischen BigClass und SmallClass1 und SmallClass2. Git hingegen ist klug genug zu wissen, dass x% von BigClass jetzt in SmallClass1 und y% von BigClass in SmallClass2 enthalten sind und dass BigClass nicht mehr existiert. Aus der Sicht von jemandem, der Änderungen in mehreren Zweigen überprüft, sagen Sie mir nun, welchen Ansatz Sie nützlicher finden würden - Git oder Perforce. Persönlich bevorzuge ich den Ansatz von Git, weil er die tatsächliche Änderung des Codes genauer widerspiegelt. Git ist dazu in der Lage, da es den Inhalt der Datei und nicht die Datei selbst verfolgt.
13. Zentral oder dezentral: Git ist ein DVCS System, während Perforce zentralisiert ist. Ein zentrales VCS kann später nicht dezentralisiert werden, aber ein DVCS (insbesondere Git) kann zentralisiert werden. Es gibt mehrere Produkte, die git eine sehr fein abgestimmte Zugriffskontrolle hinzufügen, wenn dies für das Unternehmen erforderlich ist. Persönlich würde ich mich für ein System entscheiden, das mir langfristig mehr Flexibilität bietet.
14. Verzweigungszuordnungen: Wenn Sie direkt in Perforce verzweigen möchten, müssen Sie eine Verzweigungszuordnung erstellen. Es gibt Gründe dafür, aber sie hängen davon ab, wie Perforce einen Zweig konzipiert. Als Entwickler oder Team bedeutet dies einfach einen weiteren Schritt im Arbeitsablauf, den ich überhaupt nicht für effizient halte.
15. Arbeitsteilung zwischen Teams: Mit Perforce können Sie eine Einreichung nicht aufteilen. Team A arbeitet an Feature A. Team B arbeitet an Feature B. Team C arbeitet an Fehlerkorrekturen. Jetzt müssen die Teams A und B eine Reihe von Fehlern beheben, um ihre Funktionen zu implementieren. Das einzige ist, dass sie bei der Festlegung ihrer Änderungen nicht so diszipliniert waren (wahrscheinlich, weil sie sich auf eine Frist beeilen), und daher sind ihre "Bugfixes" Teile größerer Einreichungen, die auch neue Inhalte zur Versionskontrolle enthalten Branchen sind betroffen. Team C macht jetzt jedoch eine Punktveröffentlichung und möchte die Fehlerbehebungen von den anderen Teams erhalten. Wenn sie Git verwenden, kann Team C die relevanten Änderungen der anderen Teams auswählen, sie aufteilen und nur das übernehmen, was sie benötigen, ohne sich Gedanken über die Einführung teilweise implementierter Funktionen machen zu müssen. Mit Perforce
16. Ändern der Plattform - Wenn Sie aus irgendeinem Grund in Zukunft entscheiden, die Plattform Ihrer Wahl mit Perforce zu ändern, sind Sie Perforce.com und der Verfügbarkeit der Tools für die Plattform Ihrer Wahl ausgeliefert.
17. Wechsel zur zukünftigen erstaunlichen Quellcodeverwaltungs-Engine X - Wenn Sie sich entscheiden, Ihre Verwendung für die Quellcodeverwaltung zu ändern, wird das Extrahieren Ihres Quellcodeverwaltungsverlaufs aus Perforce und das Verschieben auf das neue System X ein Albtraum, da es sich um Closed Source und das Beste handelt Sie können nur raten - nur die Migration von Google für Perforce zu Git, um ein Gefühl dafür zu bekommen, wovon ich spreche. Zumindest mit Git, seiner Open Source-Version, entfällt so viel Rätselraten.

Nun, das sind meine 2 Cent. Zur Verteidigung von Perforce muss ich die Regeln für den Kundensupport und das Tool für die Zeitrafferansicht angeben. Ich weiß nicht, wie ich mit git eine Zeitrafferansicht bekommen soll. Aber für die Bequemlichkeit und Zeitersparnis würde ich jeden Tag mit git gehen.

Es würde mich sehr überzeugen, von notgedrungen zu wechseln. In den beiden Firmen, die ich verwendet habe, war es mehr als ausreichend. Dies waren beide Unternehmen mit unterschiedlichen Büros, aber die Büros waren mit einer ausreichenden Infrastruktur ausgestattet, sodass die disjunkten / getrennten Funktionen nicht erforderlich waren.

Wie viele Entwickler sprechen Sie über eine Umstellung?

Die eigentliche Frage ist: Was ist mit Perforce, das nicht den Anforderungen Ihres Unternehmens entspricht, die Git bieten kann? Und ähnlich, welche Schwächen hat Git im Vergleich zu Perforce? Wenn Sie das nicht selbst beantworten können, hilft es nicht, hier zu fragen. Sie müssen einen Business Case für Ihr Unternehmen finden. (z. B. Möglicherweise mit niedrigeren Gesamtbetriebskosten (einschließlich Produktivitätsverlust für die Zwischenlernphase, höheren Verwaltungskosten (zumindest anfänglich) usw.)

Ich denke, Sie stehen vor einem schwierigen Verkauf - Perforce ist ein ziemlich guter Versuch, ihn zu ersetzen. Es ist ein Kinderspiel, wenn Sie versuchen, pvcs oder ssafe zu booten.

Ich denke, um die Leute während / nach der Umstellung glücklich zu machen, ist eines der Dinge, die man früh vermitteln sollte, wie privat eine lokale Niederlassung in Git sein kann und wie viel Freiheit sie haben, Fehler zu machen. Lassen Sie sie alle ein paar private Zweige aus dem aktuellen Code klonen und experimentieren. Benennen Sie einige Dateien um, checken Sie Inhalte ein, führen Sie Elemente aus einem anderen Zweig zusammen, spulen Sie den Verlauf zurück, setzen Sie eine Reihe von Änderungen auf eine andere und so weiter. Zeigen Sie, dass selbst die schlimmsten Unfälle vor Ort keine Konsequenzen für ihre Kollegen haben. Was Sie wollen, ist eine Situation, in der sich Entwickler sicher fühlen, damit sie schneller lernen können (da Git eine steile Lernkurve hat, die wichtig ist) und schließlich, damit sie als Entwickler effektiver sind.

Wenn Sie versuchen, ein zentrales Tool zu erlernen, werden Sie offensichtlich besorgt sein, einen Fehler zu machen, der anderen Benutzern des Repositorys Probleme bereitet. Die Angst vor Verlegenheit allein reicht aus, um die Menschen vom Experimentieren abzuhalten. Selbst ein spezielles "Training" -Repository hilft nicht weiter, da Entwickler unweigerlich auf eine Situation im Produktionssystem stoßen, die sie während des Trainings nie gesehen haben, und sich daher wieder Sorgen machen.

Aber die verteilte Natur von Git beseitigt dies. Sie können jedes Experiment in einer lokalen Niederlassung ausprobieren. Wenn es schrecklich schief geht, werfen Sie die Niederlassung einfach weg und niemand muss es wissen. Da Sie einen lokalen Zweig von allem erstellen können, können Sie ein Problem, das Sie sehen, mit dem realen Live-Repository replizieren, haben jedoch keine Gefahr, den Build zu "brechen" oder sich auf andere Weise zum Narren zu machen. Sie können absolut alles einchecken, sobald Sie es getan haben, ohne zu versuchen, Stapelarbeiten in ordentliche kleine Pakete zu zerlegen. Also nicht nur die zwei wichtigen Codeänderungen, an denen Sie heute vier Stunden gearbeitet haben, sondern auch die Build-Korrektur, an die Sie sich auf halbem Weg erinnert haben, und der Rechtschreibfehler in der Dokumentation, die Sie entdeckt haben, als Sie einem Kollegen etwas erklärt haben, und so weiter. Und wenn die wichtigsten Änderungen aufgegeben werden, weil das Projekt die Richtung ändert,

Der Befehl, der mich persönlich auf git verkaufte, war halbiert . Ich glaube nicht, dass diese Funktion derzeit in einem anderen Versionskontrollsystem verfügbar ist.

Davon abgesehen werden Benutzer, die an einen GUI-Client zur Quellcodeverwaltung gewöhnt sind, nicht von Git beeindruckt sein. Derzeit ist der einzige Client mit vollem Funktionsumfang die Befehlszeile.

Welche Perforce-Funktionen verwenden Benutzer?

• Mehrere Arbeitsbereiche auf einem Computer
• Nummerierte Änderungslisten
• Entwicklerzweige
• Integration mit IDE (Visual Studio, Eclipse, SlickEdit, ...)
• Viele Build-Varianten
• Zusammengesetzte Arbeitsbereiche
• Einige Korrekturen integrieren, andere jedoch nicht
• etc

Ich frage, denn wenn alle Leute nur von der Kommandozeile holen und setzen, hat git das abgedeckt, und alle anderen RTS auch.

Anscheinend bietet GitHub jetzt Git-Schulungen für Unternehmen an . Quoth ihren Blog-Beitrag darüber :

Ich war in den letzten Wochen einige Male auf dem Google-Campus, um die Androiden dort in Git zu trainieren. Shawn Pearce (Sie kennen ihn vielleicht von seinem Git- und EGit / JGit-Ruhm - er ist der Held, der die Wartung übernimmt, wenn Junio ​​nicht in der Stadt ist) wurde gebeten, ihn bei der Schulung der Google-Ingenieure zu unterstützen, die an Andriod für den Übergang arbeiten von Perforce bis Git , damit Android mit den Massen geteilt werden kann. Ich kann Ihnen sagen, dass ich mehr als glücklich war, es zu tun.

[…]

Logical Awesome bietet diese Art von benutzerdefiniertem Schulungsservice nun offiziell allen Unternehmen an. Wir können Ihrem Unternehmen bei der Schulung und Planung helfen, wenn Sie auch über einen Wechsel zu Git nachdenken.

Hervorhebung von mir.

Ich benutze Perforce schon lange und seit kurzem auch GIT. Hier ist meine "objektive" Meinung:

Perforce-Funktionen:

1. GUI-Tools scheinen umfangreicher zu sein (z. B. Zeitrafferansicht, Revisionsdiagramm).
2. Geschwindigkeit bei der Synchronisierung mit der Kopfrevision (kein Aufwand für die Übertragung des gesamten Verlaufs)
3. Die Integration von Eclipse / Visual Studio ist wirklich nett
4. Sie können pro Changelist mehrere Funktionen in einem Zweig entwickeln (ich bin mir immer noch nicht 100% sicher, ob dies ein Vorteil gegenüber GIT ist).
5. Sie können "ausspionieren", was andere Entwickler tun - welche Art von Dateien sie ausgecheckt haben.

GIT-Funktionen:

1. Ich habe den Eindruck, dass die GIT-Befehlszeile viel einfacher als Perforce ist (init / clone, add, commit. Keine Konfiguration komplexer Arbeitsbereiche).
2. Geschwindigkeit beim Zugriff auf den Projektverlauf nach dem Auschecken (kostet das Kopieren des gesamten Verlaufs bei der Synchronisierung)
3. Offline-Modus (Entwickler werden sich nicht darüber beschweren, dass ein nicht erreichbarer P4-Server das Codieren verhindert)
4. Das Erstellen neuer Zweige geht viel schneller
5. Der "Haupt" -GIT-Server benötigt nicht genügend TByte Speicher, da jeder Entwickler seine eigene lokale Sandbox haben kann
6. GIT ist OpenSource - keine Lizenzgebühren
7. Wenn Ihr Unternehmen auch zu OpenSource-Projekten beiträgt, ist das Teilen von Patches mit GIT viel einfacher

Insgesamt würde ich für OpenSource / Distributed-Projekte immer GIT empfehlen, da es eher einer P2P-Anwendung ähnelt und jeder an der Entwicklung teilnehmen kann. Ich erinnere mich zum Beispiel, dass ich bei der Remote-Entwicklung mit Perforce einmal pro Woche 4-GB-Projekte über eine 1-Mbit / s-Verbindung synchronisiert habe. Dadurch wurde einfach viel Zeit verschwendet. Dazu mussten wir auch VPN einrichten.

Wenn Sie eine kleine Firma haben und der P4-Server immer in Betrieb ist, würde ich sagen, dass Perforce auch eine sehr gute Option ist.

Wir verwenden Git seit einiger Zeit. Vor kurzem ist die Festplatte unseres Git-Servers abgestürzt und wir konnten nicht zum neuesten Status zurückkehren. Wir haben es geschafft, in den ein paar Tage alten Zustand zurückzukehren. Als der Server gesichert wurde. Jeder im Team hat seine Änderungen gezogen / gepusht und voila, der Server ist wieder im aktuellen Zustand.

Der einzige wichtige Unterschied zwischen Perforce und git (und dem am häufigsten erwähnten) ist der jeweilige Umgang mit riesigen Binärdateien.

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

Wichtig ist jedoch, dass der Geschwindigkeitsunterschied zwischen git und perforce, wenn Sie ein riesiges 6-GB-Repository haben, das alles von der Dokumentation bis zu jeder jemals erstellten Binärdatei enthält (und schließlich, oh ja! Der tatsächliche Quellverlauf), normalerweise von der stammt Tatsache, dass große Unternehmen dazu neigen, Perforce zu betreiben, und sie haben es so eingerichtet, dass alle wichtigen Vorgänge auf die riesige Serverbank im Keller verlagert werden.

Dieser wichtige Vorteil von Perforce beruht nur auf einem Faktor, der überhaupt nichts mit Perforce zu tun hat, nämlich der Tatsache, dass sich das Unternehmen, das es betreibt, diese Serverbank leisten kann.

Und letztendlich sind Perforce und Git unterschiedliche Produkte. Git wurde ausschließlich als VCS entwickelt und ist weitaus besser als Perforce (da es über mehr Funktionen verfügt, die im Allgemeinen einfacher zu verwenden sind, insbesondere in den Worten eines anderen, ist das Verzweigen in Perforce wie das Ausführen von Open Heart Operation sollte nur von Experten durchgeführt werden: P) ( http://stevehanov.ca/blog/index.php?id=50 )

Alle anderen Vorteile, die Unternehmen, die Perforce nutzen, nutzen, sind lediglich darauf zurückzuführen, dass Perforce nicht nur ein VCS, sondern auch ein Dateiserver ist und über eine Vielzahl weiterer Funktionen zum Testen der Leistung von Builds usw. verfügt.

Schließlich: Da Git Open Source ist und viel flexibler zu booten ist, wäre es nicht so schwer, Git zu patchen, um wichtige Vorgänge auf einen zentralen Server zu verlagern, auf dem eine Menge teurer Hardware ausgeführt wird.

Ich denke, das einzige, von dem ich weiß, dass GIT gewinnt, ist die Fähigkeit, "Zeilenenden" für alle Dateien beizubehalten, während perforce darauf zu bestehen scheint, sie entweder in das Unix-, Dos / Windows- oder MacOS9-Format ("\ n", "\" zu übersetzen r \ n "oder" \ r).

Dies ist ein echtes Problem, wenn Sie Unix-Skripte in einer Windows-Umgebung oder einer gemischten Betriebssystemumgebung schreiben. Es ist nicht einmal möglich, die Regel pro Dateierweiterung festzulegen. Beispielsweise würden .sh-, .bash-, .unix-Dateien in das Unix-Format konvertiert und .ccp-, .bat- oder .com-Dateien in das Dos / Windows-Format konvertiert.

In GIT (ich bin nicht sicher, ob dies die Standardeinstellung, eine Option oder die einzige Option ist) können Sie es so einstellen, dass "Zeilenenden beibehalten werden". Das heißt, Sie können die Zeilenenden einer Datei manuell ändern, und dann lässt GIT dieses Format unverändert. Dies scheint mir der ideale Weg zu sein, um Dinge zu tun, und ich verstehe nicht, warum dies bei Perforce keine Option ist.

Die einzige Möglichkeit, dieses Verhalten zu erreichen, besteht darin, die Dateien als binär zu markieren. Wie ich das sehe, wäre das ein böser Hack, um eine fehlende Funktion zu umgehen. Abgesehen davon, dass es mühsam ist, alle Skripte usw. zu bearbeiten, würde es wahrscheinlich auch die meisten Unterschiede usw. aufheben.

Die "Lösung", mit der wir uns im Moment zufrieden gegeben haben, besteht darin, einen sed-Befehl auszuführen, um alle Wagenrückläufe bei jeder Bereitstellung in ihrer Unix-Umgebung aus den Skripten zu entfernen. Dies ist auch nicht ideal, zumal einige von ihnen in WAR-Dateien bereitgestellt werden und die sed-Zeile beim Entpacken erneut ausgeführt werden muss.

Dies ist nur etwas, von dem ich denke, dass es GIT einen großen Vorteil verschafft, und von dem ich glaube, dass es oben nicht erwähnt wurde.

BEARBEITEN: Nachdem ich Perforce länger verwendet habe, möchte ich noch ein paar Kommentare hinzufügen:

A) Was ich in Perforce wirklich vermisse, ist ein klarer und instanzieller Unterschied, einschließlich geänderter, entfernter und hinzugefügter Dateien. Dies ist in GIT mit dem git diffBefehl verfügbar. In Perforce müssen Dateien jedoch ausgecheckt werden, bevor ihre Änderungen aufgezeichnet werden. Möglicherweise sind Ihre Haupteditoren (wie Eclipse) so eingerichtet, dass Dateien beim Bearbeiten automatisch ausgecheckt werden Manchmal können Dateien auf andere Weise bearbeitet werden (Editor, Unix-Befehle usw.). Und neue Dateien scheinen überhaupt nicht automatisch hinzugefügt zu werden, selbst wenn Eclipse und p4eclipse verwendet werden, was ziemlich ärgerlich sein kann. Um alle Änderungen zu finden, müssen Sie im gesamten Arbeitsbereich einen "Diff gegen ..." ausführen, der erstens eine Weile dauert und zweitens alle möglichen irrelevanten Dinge enthält, es sei denn, Sie richten sehr komplizierte Ausschlusslisten ein. was mich zum nächsten Punkt führt.

B) In GIT finde ich den .gitignore sehr einfach und leicht zu verwalten, zu lesen und zu verstehen. Die in Perforce konfigurierbaren Listen zum Ignorieren / Ausschließen des Arbeitsbereichs scheinen jedoch unhandlich und unnötig komplex zu sein. Ich konnte keine Ausschlüsse mit funktionierenden Platzhaltern erzielen. Ich würde gerne so etwas machen

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

So schließen Sie alle Zielordner in allen Projekten innerhalb von Server / Mainline aus Dies scheint jedoch nicht so zu funktionieren, wie ich es erwartet hätte, und ich habe am Ende für jedes Projekt eine Zeile hinzugefügt 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 mehr.

C) In Perforce gibt es die ziemlich nützlichen Änderungslisten. Angenommen, ich nehme eine Gruppe von Änderungen vor, überprüfe sie alle und füge sie in eine Änderungsliste ein, um dann an etwas anderem zu arbeiten, bevor ich diese Änderungsliste abschicke. Wenn ich später eine Änderung an einer der in der ersten Änderungsliste enthaltenen Dateien vornehme, befindet sich diese Datei weiterhin in dieser Änderungsliste, und ich kann die Änderungsliste nicht einfach später einreichen, vorausgesetzt, sie enthält nur die Änderungen, die ich ursprünglich hinzugefügt habe (obwohl dies der Fall ist) werden die gleichen Dateien sein). Wenn Sie in GIT eine Datei hinzufügen und weitere Änderungen daran vornehmen, wurden diese Änderungen nicht hinzugefügt (und werden weiterhin in a angezeigtgit diffund Sie könnten die Datei nicht festschreiben, ohne vorher auch die neuen Änderungen hinzuzufügen. Dies ist natürlich nicht so nützlich wie die Änderungsliste, da Sie nur einen Satz hinzugefügter Dateien haben, aber in GIT können Sie die Änderungen einfach festschreiben, da dies sie nicht wirklich pusht. Sie könnten sie an anderen Änderungen bearbeiten, bevor Sie sie verschieben, aber Sie könnten nichts anderes verschieben, das Sie später hinzufügen, ohne auch die vorherigen Änderungen zu übernehmen.

Ich habe keine Erfahrung mit Git, aber ich habe mit Mercurial, das auch ein verteiltes VCS ist. Es hängt wirklich vom Projekt ab, aber in unserem Fall war ein verteiltes VCS für das Projekt geeignet, da es häufig fehlerhafte Builds eliminierte.

Ich denke, es hängt wirklich vom Projekt ab, da einige besser für ein Client-Server-VCS geeignet sind und andere für ein verteiltes.

Folgendes mag ich an git nicht:

Zunächst denke ich, dass die verteilte Idee der Realität widerspricht. Jeder, der tatsächlich Git benutzt, tut dies zentral, sogar Linus Torvalds. Wenn der Kernel auf verteilte Weise verwaltet würde, würde dies bedeuten, dass ich die "offiziellen" Kernelquellen nicht herunterladen könnte - es würde keine geben - ich müsste mich entscheiden, ob ich Linus 'Version oder Joes Version möchte. oder Bills Version. Das wäre natürlich lächerlich, und deshalb gibt es eine offizielle Definition, die Linus mithilfe eines zentralisierten Workflows steuert.

Wenn Sie akzeptieren, dass Sie eine zentralisierte Definition Ihrer Inhalte wünschen, wird deutlich, dass die Server- und Client-Rollen völlig unterschiedlich sind, sodass das Dogma, dass Client- und Server-Software identisch sein sollten, rein einschränkend wird. Das Dogma , dass die Client- und Server - Daten sollten gleich sein wird einfach lächerlich, vor allem in einer Code - Basis , dass die 15 Jahre der Geschichte bekam , dass niemand kümmert sich um , aber jeder zu Klon haben würde.

Was wir eigentlich mit all dem alten Zeug machen wollen, ist es in einen Schrank zu stecken und zu vergessen, dass es da ist, genau wie jedes normale VCS. Die Tatsache, dass Git jeden Tag alles über das Netzwerk hin und her schleppt, ist sehr gefährlich, weil es Sie nervt, es zu beschneiden. Dieses Beschneiden ist mit vielen langwierigen Entscheidungen verbunden und kann schief gehen. Die Leute werden wahrscheinlich eine ganze Reihe von Schnappschuss-Repos von verschiedenen Punkten in der Geschichte behalten, aber war das nicht das, wofür die Quellcodeverwaltung gedacht war? Dieses Problem gab es erst, als jemand das verteilte Modell erfand.

Git ermutigt die Leute aktiv, die Geschichte neu zu schreiben, und das Obige ist wahrscheinlich ein Grund dafür. Jedes normale VCS macht das Umschreiben des Verlaufs für alle außer den Administratoren unmöglich und stellt sicher, dass die Administratoren keinen Grund haben, darüber nachzudenken. Korrigieren Sie mich, wenn ich falsch liege, aber soweit ich weiß, bietet git normalen Benutzern keine Möglichkeit, Schreibzugriff zu gewähren, sondern verbietet ihnen, den Verlauf neu zu schreiben. Das bedeutet, dass jeder Entwickler mit Groll (oder der immer noch mit der Lernkurve zu kämpfen hatte) die gesamte Codebasis in den Papierkorb werfen kann. Wie ziehen wir das fest? Nun, entweder erstellen Sie regelmäßig Backups des gesamten Verlaufs, dh Sie halten den Verlauf im Quadrat, oder Sie verbieten den Schreibzugriff auf alle außer einigen armen Leuten, die alle Unterschiede per E-Mail erhalten und von Hand zusammenführen würden.

Nehmen wir ein Beispiel für ein gut finanziertes, großes Projekt und sehen, wie Git für sie funktioniert: Android. Ich habe mich einmal entschlossen, mit dem Android-System selbst zu spielen. Ich fand heraus, dass ich eine Reihe von Skripten namens Repo verwenden sollte, um an ihren Git zu kommen. Einige Repos werden auf dem Client und einige auf dem Server ausgeführt, aber beide veranschaulichen aufgrund ihrer Existenz die Tatsache, dass Git in beiden Funktionen unvollständig ist. Was passierte ist, dass ich ungefähr eine Woche lang nicht in der Lage war, die Quellen zu ziehen und dann ganz aufgab. Ich hätte eine wirklich große Datenmenge aus verschiedenen Repositorys abrufen müssen, aber der Server war mit Leuten wie mir völlig überlastet. Repo hatte eine Zeitüberschreitung und konnte nicht dort weitermachen, wo die Zeitüberschreitung abgelaufen war. Wenn Git so verteilbar ist, hättest du gedacht, dass sie ' Ich habe eine Art Peer-to-Peer-Aktion durchgeführt, um die Belastung dieses einen Servers zu verringern. Git ist verteilbar, aber kein Server. Git + Repo ist ein Server, aber Repo ist nicht verteilbar, da es sich nur um eine Ad-hoc-Sammlung von Hacks handelt.

Ein ähnliches Beispiel für die Unzulänglichkeit von git ist gitolite (und sein Vorfahr, der anscheinend nicht so gut funktioniert hat). Gitolite beschreibt seine Aufgabe darin, die Bereitstellung eines git-Servers zu vereinfachen. Wiederum beweist die bloße Existenz dieser Sache, dass Git kein Server ist, genauso wenig wie es ein Client ist. Darüber hinaus wird es niemals so sein, denn wenn es zu einem der beiden werden würde, würde es seine Grundprinzipien verraten.

Selbst wenn Sie an das verteilte Ding glauben würden, wäre Git immer noch ein Chaos. Was ist zum Beispiel eine Niederlassung? Sie sagen, dass Sie implizit jedes Mal einen Zweig erstellen, wenn Sie ein Repository klonen, aber das kann nicht dasselbe sein wie ein Zweig in einem einzelnen Repository. Das sind also mindestens zwei verschiedene Dinge, die als Zweige bezeichnet werden. Sie können aber auch ein Repo zurückspulen und einfach mit der Bearbeitung beginnen. Ist das wie die zweite Art von Zweig oder wieder etwas anderes? Vielleicht hängt es davon ab, welche Art von Repo Sie haben - oh ja - anscheinend ist das Repo auch kein sehr klares Konzept. Es gibt normale und nackte. Sie können nicht zu einem normalen Teil wechseln, da der nackte Teil möglicherweise nicht mehr mit dem Quellbaum synchronisiert ist. Aber Sie können nicht zu einem Nackten importieren, weil sie nicht daran gedacht haben. Sie müssen also zu einem normalen cvsimportieren, Klonen Sie das auf eine nackte, die Entwickler getroffen haben, und cvsexportieren Sie das auf eine CVS-Arbeitskopie, die noch in cvs eingecheckt werden muss. Wer kann gestört werden? Woher kamen all diese Komplikationen? Aus der verteilten Idee selbst. Am Ende habe ich Gitolite fallen lassen, weil es mir noch mehr dieser Einschränkungen auferlegte.

Git sagt, dass die Verzweigung leicht sein sollte, aber viele Unternehmen haben bereits ein ernstes Problem mit betrügerischen Zweigen, so dass ich gedacht hätte, dass die Verzweigung eine wichtige Entscheidung mit strenger Überwachung sein sollte. Hier scheint Perforce wirklich ...

In der Not brauchen Sie selten Zweige, weil Sie Änderungssätze auf sehr agile Weise jonglieren können. Der übliche Workflow besteht beispielsweise darin, dass Sie mit der letzten bekannten guten Version auf der Hauptleitung synchronisieren und dann Ihre Funktion schreiben. Wenn Sie versuchen, eine Datei zu ändern, wird der Unterschied dieser Datei zu Ihrem "Standard-Änderungssatz" hinzugefügt. Wenn Sie versuchen, das Änderungsset einzuchecken, wird automatisch versucht, die Nachrichten von der Hauptzeile in Ihr Änderungsset einzufügen (effektiv neu zu gründen) und dann festgeschrieben. Dieser Workflow wird erzwungen, ohne dass Sie ihn verstehen müssen. Mainline sammelt so eine Änderungshistorie, durch die Sie sich später ganz einfach durcharbeiten können. Angenommen, Sie möchten eine alte zurücksetzen, z. B. die vor der vorletzten. Sie synchronisieren mit dem Moment vor der Änderung, markieren die betroffenen Dateien als Teil des Änderungssatzes. Synchronisiere mit dem Moment danach und verschmelze mit "immer meins". (Da war etwas sehr Interessantes: Synchronisieren bedeutet nicht, dasselbe zu haben - wenn eine Datei bearbeitet werden kann (dh in einem aktiven Änderungssatz), wird sie nicht von der Synchronisierung blockiert, sondern als zum Auflösen fällig markiert.) Jetzt haben Sie eine Änderungsliste, die die beleidigende rückgängig macht. Wenn Sie die nachfolgenden Nachrichten zusammenführen, haben Sie eine Änderungsliste, die Sie über die Hauptlinie legen können, um den gewünschten Effekt zu erzielen. Zu keinem Zeitpunkt haben wir eine Geschichte neu geschrieben. Wenn Sie die nachfolgenden Nachrichten zusammenführen, haben Sie eine Änderungsliste, die Sie über die Hauptlinie legen können, um den gewünschten Effekt zu erzielen. Zu keinem Zeitpunkt haben wir eine Geschichte neu geschrieben. Wenn Sie die nachfolgenden Nachrichten zusammenführen, haben Sie eine Änderungsliste, die Sie über die Hauptlinie legen können, um den gewünschten Effekt zu erzielen. Zu keinem Zeitpunkt haben wir eine Geschichte neu geschrieben.

Angenommen, in der Mitte dieses Prozesses läuft jemand auf Sie zu und fordert Sie auf, alles fallen zu lassen und einen Fehler zu beheben. Sie geben Ihrer Standard-Änderungsliste einfach einen Namen (tatsächlich eine Nummer), "setzen" sie dann aus, beheben den Fehler in der jetzt leeren Standard-Änderungsliste, schreiben sie fest und setzen die benannte Änderungsliste fort. Es ist typisch, dass mehrere Änderungslisten gleichzeitig angehalten werden, wenn Sie verschiedene Dinge ausprobieren. Es ist einfach und privat. Sie erhalten das, was Sie wirklich von einem Zweigregime wollen, ohne die Versuchung zu haben, die Verschmelzung mit der Hauptlinie hinauszuschieben oder zu verzögern.

Ich nehme an, es wäre theoretisch möglich, etwas Ähnliches in git zu tun, aber git macht praktisch alles möglich, anstatt einen Workflow zu behaupten, den wir gutheißen. Das zentralisierte Modell ist eine Reihe gültiger Vereinfachungen in Bezug auf das verteilte Modell, bei dem es sich um eine ungültige Verallgemeinerung handelt. Es ist so übergeneralisiert, dass es im Grunde erwartet, dass Sie die Quellcodeverwaltung darüber hinaus implementieren, wie es Repo tut.

Die andere Sache ist die Replikation. In git ist alles möglich, also musst du es selbst herausfinden. Zwangsläufig erhalten Sie einen effektiv zustandslosen Cache. Die einzige Konfiguration, die es wissen muss, ist, wo sich der Master befindet, und die Clients können nach eigenem Ermessen entweder auf den Master oder den Cache zeigen. Das ist ein fünfminütiger Job und es kann nichts schief gehen.

Sie haben auch Trigger und anpassbare Formulare, um Codeüberprüfungen, Bugzilla-Referenzen usw. zu bestätigen, und natürlich haben Sie Zweige, wenn Sie sie tatsächlich benötigen. Es ist kein klarer Fall, aber es ist nah und es ist kinderleicht einzurichten und zu warten.

Alles in allem denke ich, wenn Sie wissen, dass Sie zentral arbeiten werden, was jeder tut, können Sie auch ein Tool verwenden, das unter diesem Gesichtspunkt entwickelt wurde. Git wird überbewertet, weil Linus 'furchterregender Witz zusammen mit der Tendenz der Menschen, einander wie Schafe zu folgen, aber seine Hauptaufgabe dem gesunden Menschenverstand nicht wirklich standhält, und indem er ihm folgt, bindet Git seine eigenen Hände mit Die beiden großen Dogmen, dass (a) die Software und (b) die Daten sowohl auf dem Client als auch auf dem Server gleich sein müssen, machen das bei der zentralen Arbeit immer kompliziert und lahm.

Die Verwendung von GIT als Ersatz für eine schlechte Codezeilenverwaltung ist üblich. Viele der Nachteile von Perforce sind auf schlechte Verzweigungsstrategien zurückzuführen. Das gleiche gilt für jedes andere zentralisierte Tool. Wenn Sie eine Menge Zweige erstellen müssen, machen Sie etwas falsch. Warum müssen Entwickler so viele Zweige erstellen?

Warum ist es überhaupt so wichtig, nicht verbunden zu arbeiten? Nur damit jemand in einem Zug arbeiten kann? Dies ist heutzutage der einzige Ort, an dem Sie keine drahtlose Verbindung herstellen können. Und selbst die meisten Züge haben ordentliches WiFi.