Sind Subversion-Externals ein Antipattern?

Mit Subversion können Sie Arbeitskopien anderer Repositorys mithilfe von externen Dateien einbetten und so die Versionskontrolle der Bibliothekssoftware von Drittanbietern in Ihrem Projekt vereinfachen.

Diese scheinen zwar ideal für die Wiederverwendung von Bibliotheken und die Versionskontrolle von Software von Anbietern zu sein , sind jedoch nicht ohne Kritiker :

Bitte verwenden Sie keine Subversion-Externals (oder ähnliches in anderen Tools), sie sind ein Anti-Pattern und daher nicht erforderlich

Gibt es versteckte Risiken bei der Verwendung von externen Geräten? Bitte erklären Sie, warum sie als Antimuster gelten würden.

Ich bin der Autor des Zitats in der Frage, das aus einer früheren Antwort stammt .

Jason ist zu Recht misstrauisch gegenüber kurzen Aussagen wie meinen und bittet um eine Erklärung. Wenn ich alles in dieser Antwort vollständig erklärt hätte, hätte ich natürlich ein Buch geschrieben.

Mike weist auch zu Recht darauf hin, dass eines der Probleme mit einer svn:externalähnlichen Funktion darin besteht, dass Änderungen an der Zielquelle Ihre eigene Quelle beschädigen können, insbesondere wenn sich diese Zielquelle in einem Repository befindet, das Sie nicht besitzen.

Lassen Sie mich zur weiteren Erläuterung meines Kommentars zunächst sagen, dass es "sichere" Möglichkeiten gibt, die svn:externalähnliche Funktion zu verwenden, genau wie bei jedem anderen Tool oder Feature. Ich bezeichne es jedoch als Antimuster, da die Funktion weitaus häufiger missbraucht wird. Nach meiner Erfahrung wurde es immer missbraucht, und es ist sehr unwahrscheinlich, dass ich es jemals auf diese sichere Weise verwenden oder jemals empfehlen werde. Bitte beachten Sie weiter, dass ich KEINE Herabsetzung des Subversion-Teams meine - ich liebe Subversion, obwohl ich vorhabe, zum Basar zu wechseln.

Das Hauptproblem bei dieser Funktion besteht darin, dass sie ermutigt und normalerweise verwendet wird, um die Quelle eines Builds ("Projekt") direkt mit der Quelle eines anderen zu verknüpfen oder das Projekt mit einer Binärdatei (DLL, JAR usw.) zu verknüpfen. von denen es abhängt. Keine dieser Verwendungen ist weise und sie bilden ein Antimuster.

Wie ich in meiner anderen Antwort sagte, glaube ich, dass ein wesentliches Prinzip für Software-Builds darin besteht, dass jedes Projekt genau EIN binäres oder primäres Ergebnis erstellt. Dies kann als Anwendung des Prinzips der Trennung von Bedenken auf den Erstellungsprozess angesehen werden. Dies gilt insbesondere für ein Projekt, das direkt auf die Quelle eines anderen verweist, was ebenfalls einen Verstoß gegen das Kapselungsprinzip darstellt . Eine andere Form dieser Art von Verletzung ist der Versuch, eine Build-Hierarchie zu erstellen, um ein gesamtes System oder Subsystem durch rekursives Aufrufen von Sub-Builds zu erstellen. Maven ermutigt / erzwingt dieses Verhalten nachdrücklich, was einer der vielen Gründe ist, warum ich es nicht empfehle.

Schließlich finde ich, dass es verschiedene praktische Aspekte gibt, die diese Funktion unerwünscht machen. Zum einen svn:externalhat einige interessante Verhaltensmerkmale (aber die Details entgehen mir im Moment). Zum anderen stelle ich immer fest, dass solche Abhängigkeiten für mein Projekt explizit sichtbar sein müssen (Erstellungsprozess) und nicht als Metadaten der Quellcodeverwaltung vergraben sind.

Was ist also eine "sichere" Art, diese Funktion zu verwenden? Ich würde dies als eine Zeit betrachten, in der es nur von einer Person verwendet wird, beispielsweise um eine Arbeitsumgebung zu "konfigurieren". Ich konnte sehen, wo ein Programmierer möglicherweise einen eigenen Ordner im Repository erstellt (oder einen für jeden Programmierer), in dem er svn:externalLinks zu den verschiedenen anderen Teilen des Repositorys konfiguriert, an denen er gerade arbeitet. Durch Auschecken dieses einen Ordners wird dann eine Arbeitskopie aller aktuellen Projekte erstellt. Wenn ein Projekt hinzugefügt oder beendet wird, können die svn:externalDefinitionen angepasst und die Arbeitskopie entsprechend aktualisiert werden. Ich bevorzuge jedoch einen Ansatz, der nicht an ein bestimmtes Versionsverwaltungssystem gebunden ist, z. B. mit einem Skript, das die Checkouts aufruft.

Mein letztes Engagement für dieses Problem trat im Sommer 2008 bei einem Beratungskunden svn:externalauf, der in großem Umfang tätig war. ALLES wurde vernetzt, um eine einzige Master-Arbeitskopie zu erstellen. Ihre Ant & Jython-basierten (für WebLogic) Build-Skripte wurden auf dieser Master-Arbeitskopie erstellt. Das Nettoergebnis: NICHTS konnte eigenständig gebaut werden, es gab buchstäblich Dutzende von Teilprojekten, aber keines war sicher, selbst auszuchecken / daran zu arbeiten. Daher erforderte jede Arbeit an diesem System zuerst das Auschecken / Aktualisieren von mehr als 2 GB Dateien (sie legten auch Binärdateien in das Repository). Etwas zu erledigen war eine Übung der Sinnlosigkeit, und ich ging, nachdem ich es drei Monate lang versucht hatte (es waren auch viele andere Antimuster vorhanden).

BEARBEITEN: Erläutern Sie rekursive Builds -

Im Laufe der Jahre (insbesondere des letzten Jahrzehnts) habe ich massive Systeme für Fortune 500-Unternehmen und große Regierungsbehörden aufgebaut, die viele Dutzend Teilprojekte umfassen, die in Verzeichnishierarchien angeordnet sind, die viele Ebenen tief sind. Ich habe Microsoft Visual Studio-Projekte / -Lösungen verwendet, um .NET-basierte Systeme, Ant oder Maven 2 für Java-basierte Systeme zu organisieren, und ich habe begonnen, Distutils und Setuptools (easyinstall) für Python-basierte Systeme zu verwenden. Diese Systeme enthalten auch große Datenbanken, die normalerweise in Oracle oder Microsoft SQL Server enthalten sind.

Ich hatte großen Erfolg beim Entwerfen dieser massiven Builds für Benutzerfreundlichkeit und Wiederholbarkeit. Mein Designstandard ist, dass ein neuer Entwickler am ersten Tag auftauchen, eine neue Workstation (möglicherweise direkt von Dell mit nur einer typischen Betriebssysteminstallation) und ein einfaches Einrichtungsdokument (normalerweise nur eine Seite mit Installationsanweisungen) erhalten kann. und in der Lage sein, die Workstation vollständig einzurichten und das gesamte System aus dem Quellcode zu erstellen, unbeaufsichtigt, ohne Unterstützung und in einem halben Tag oder weniger. Das Aufrufen des Builds selbst umfasst das Öffnen einer Befehlsshell, das Wechseln in das Stammverzeichnis des Quellbaums und das Ausgeben eines einzeiligen Befehls zum Erstellen von ALLES.

Trotz dieses Erfolgs erfordert der Aufbau eines solch massiven Build-Systems große Sorgfalt und die strikte Einhaltung solider Designprinzipien, genau wie beim Aufbau einer massiven geschäftskritischen Anwendung / eines massiven Systems. Ich habe festgestellt, dass ein entscheidender Teil darin besteht, dass jedes Projekt (das ein einzelnes Artefakt / Ergebnis liefert) ein einzelnes Build-Skript haben muss, das eine genau definierte Schnittstelle (Befehle zum Aufrufen von Teilen des Build-Prozesses) haben muss und stehen muss allein aus allen anderen (Teil-) Projekten. Historisch gesehen ist es einfach, das gesamte System zu bauen, aber es ist schwierig / unmöglich, nur ein Stück zu bauen. Erst kürzlich habe ich gelernt, sorgfältig sicherzustellen, dass jedes Projekt wirklich für sich steht.

In der Praxis bedeutet dies, dass mindestens zwei Ebenen von Build-Skripten vorhanden sein müssen. Die unterste Ebene sind die Projekterstellungsskripte, die jedes Ergebnis / Artefakt erzeugen. Jedes dieser Skripte befindet sich im Stammverzeichnis seines Projektquellbaums (tatsächlich definiert dieses Skript seinen Projektquellbaum). Diese Skripte wissen nichts über die Quellcodeverwaltung. Sie erwarten, dass sie über die Befehlszeile ausgeführt werden. Sie verweisen auf alles im Projekt relativ Sie verweisen auf das Build-Skript und verweisen auf ihre externen Abhängigkeiten (Tools oder binäre Artefakte, keine anderen Quellprojekte), basierend auf einigen konfigurierbaren Einstellungen (Umgebungsvariablen, Konfigurationsdateien usw.).

Die zweite Ebene von Build-Skripten soll ebenfalls über die Befehlszeile aufgerufen werden, diese kennen sich jedoch mit der Quellcodeverwaltung aus. In der Tat handelt es sich bei dieser zweiten Ebene häufig um ein einzelnes Skript, das mit einem Projektnamen und einer Version aufgerufen wird. Anschließend wird die Quelle für das benannte Projekt in einem neuen temporären Verzeichnis (möglicherweise in der Befehlszeile angegeben) ausgecheckt und das Erstellungsskript aufgerufen.

Möglicherweise müssen mehr Variationen vorgenommen werden, um Continuous Integration Server, mehrere Plattformen und verschiedene Release-Szenarien zu berücksichtigen.

Manchmal ist eine dritte Schicht von Skripten erforderlich, die die zweite Schicht von Skripten (die die erste Schicht aufruft) aufruft, um bestimmte Teilmengen der gesamten Projektmenge zu erstellen. Beispielsweise kann jeder Entwickler ein eigenes Skript haben, das die Projekte erstellt, an denen er heute arbeitet. Möglicherweise gibt es ein Skript, mit dem Sie alles erstellen können, um die Masterdokumentation zu generieren oder Metriken zu berechnen.

Unabhängig davon habe ich festgestellt, dass der Versuch, das System als eine Hierarchie von Projekten zu behandeln, kontraproduktiv ist. Es bindet die Projekte so miteinander, dass sie nicht frei oder an beliebigen Orten (temporäres Verzeichnis auf dem Continuous Integration Server) oder in beliebiger Reihenfolge (vorausgesetzt, die Abhängigkeiten sind erfüllt) erstellt werden können. Der Versuch, eine Hierarchie zu erzwingen, unterbricht häufig jede mögliche IDE-Integration.

Schließlich kann der Aufbau einer massiven Hierarchie von Projekten einfach zu leistungsintensiv sein. Im Frühjahr 2007 habe ich beispielsweise versucht, eine bescheidene Quellhierarchie (Java plus Oracle) zu erstellen, die ich mit Ant erstellt habe. Dies ist schließlich fehlgeschlagen, da der Build immer mit einer Java OutOfMemoryException abgebrochen wurde. Dies war auf einer 2 GB RAM-Workstation mit 3,5 GB Swap-Speicher, für die ich die JVM so eingestellt hatte, dass sie den gesamten verfügbaren Speicher nutzen konnte. Die Anwendung / das System war in Bezug auf die Codemenge relativ trivial, aber die rekursiven Build-Aufrufe erschöpften schließlich den Speicher, egal wie viel Speicher ich ihm gab. Natürlich dauerte die Ausführung auch ewig (30-60 Minuten waren üblich, bevor sie abgebrochen wurden). Ich weiß, wie man SEHR gut abstimmt, aber letztendlich habe ich einfach die Grenzen der Tools überschritten (in diesem Fall Java / Ant).

Tun Sie sich selbst einen Gefallen, konstruieren Sie Ihren Build als eigenständige Projekte und komponieren Sie sie dann zu einem vollständigen System. Halten Sie es leicht und flexibel. Genießen.

EDIT: Mehr zu Antimustern

Genau genommen ist ein Antimuster eine gängige Lösung, die das Problem zu lösen scheint, dies aber nicht tut, entweder weil es wichtige Lücken hinterlässt oder weil es zusätzliche Probleme mit sich bringt (oft schlimmer als das ursprüngliche Problem). Eine Lösung umfasst notwendigerweise ein oder mehrere Werkzeuge sowie die Technik, um sie auf das jeweilige Problem anzuwenden. Daher ist es eine Strecke, ein Werkzeug oder ein bestimmtes Merkmal eines Werkzeugs als Antimuster zu bezeichnen, und es scheint, dass Menschen diese Strecke erkennen und darauf reagieren - fair genug.

Auf der anderen Seite, da es in unserer Branche üblich zu sein scheint, sich eher auf Werkzeuge als auf Technik zu konzentrieren, ist es das Werkzeug / Merkmal, das die Aufmerksamkeit auf sich zieht (eine gelegentliche Übersicht der Fragen hier auf StackOverflow scheint leicht zu veranschaulichen). Meine Kommentare und diese Frage selbst spiegeln diese Praxis wider.

Manchmal erscheint es jedoch besonders gerechtfertigt, diese Dehnung vorzunehmen, wie in diesem Fall. Einige Werkzeuge scheinen den Benutzer zu bestimmten Techniken zu führen, um sie anzuwenden, bis zu dem Punkt, an dem einige argumentieren, dass Werkzeuge das Denken formen (leicht umformuliert). svn:externalVor allem in diesem Sinne schlage ich vor, dass es sich um ein Antimuster handelt.

Um das Problem genauer zu formulieren, besteht das Antimuster darin, eine Build-Lösung zu entwerfen, die das Zusammenbinden von Projekten auf Quellenebene umfasst, oder die Abhängigkeiten zwischen Projekten implizit zu versionieren oder zuzulassen, dass sich solche Abhängigkeiten implizit ändern, da jede dieser Abhängigkeiten sehr negativ ist Folgen. Die Art des svn:externalähnlichen Merkmals macht es sehr schwierig, diese negativen Konsequenzen zu vermeiden.

Um die Abhängigkeiten zwischen Projekten richtig zu behandeln, müssen diese Dynamiken zusammen mit dem Basisproblem berücksichtigt werden, und die Tools und Techniken gehen einen anderen Weg. Ein Beispiel, das in Betracht gezogen werden sollte, ist Ivy , das auf ähnliche Weise wie Maven hilft, jedoch ohne die vielen Nachteile. Ich untersuche Ivy in Verbindung mit Ant als meine kurzfristige Lösung für das Java-Build-Problem. Langfristig möchte ich die Kernkonzepte und -funktionen in ein Open-Source-Tool integrieren, das eine plattformübergreifende Lösung ermöglicht.

Ich denke nicht, dass dies überhaupt ein Anti-Muster ist. Ich habe ein paar schnelle Suchanfragen bei Google durchgeführt und im Grunde nichts gefunden ... niemand beschwert sich darüber, dass die Verwendung von svn: externals schlecht oder schädlich ist. Natürlich gibt es einige Vorbehalte, die Sie beachten müssen ... und es ist nicht etwas, das Sie nur stark in alle Ihre Repositories streuen sollten ... aber was das ursprüngliche Zitat betrifft, ist dies nur seine persönliche (und subjektive) Meinung . Er hat nie wirklich über svn: externals gesprochen, außer um sie als Anti-Muster zu verurteilen. Solche umfassenden Aussagen ohne jegliche Unterstützung oder zumindest Begründung, wie die Person dazu gekommen ist, die Aussage zu machen, sind immer verdächtig.

Es gibt jedoch einige Probleme bei der Verwendung von externen Geräten. Wie Mike antwortete, können sie sehr hilfreich sein, um auf stabile Zweige freigegebener Software zu verweisen ... insbesondere auf Software, die Sie bereits steuern. Wir verwenden sie intern in einer Reihe von Projekten für Utility-Bibliotheken und dergleichen. Wir haben eine kleine Gruppe, die die Basis der Dienstprogrammbibliothek erweitert und bearbeitet, aber dieser Basiscode wird von einer Reihe von Projekten gemeinsam genutzt. Wir wollen nicht, dass verschiedene Teams nur den Code des Hilfsprojekts einchecken, und wir wollen uns nicht mit einer Million Filialen befassen. Deshalb funktioniert svn: externals für uns sehr gut. Für manche Menschen sind sie möglicherweise nicht die Antwort. Ich würde jedoch der Aussage "Bitte nicht verwenden ..." stark widersprechen und dass diese Tools ein Anti-Pattern darstellen.

Das Hauptrisiko bei der Verwendung von svn: externals besteht darin, dass das referenzierte Repository so geändert wird, dass Ihr Code beschädigt wird oder eine Sicherheitslücke entsteht. Wenn das externe Repository ebenfalls unter Ihrer Kontrolle steht, ist dies möglicherweise akzeptabel.

Persönlich verwende ich nur svn: externals, um auf "stabile" Zweige eines Repositorys zu verweisen, das ich besitze.

Ein alter Thread, aber ich möchte auf die Sorge eingehen, dass ein sich ändernder externer Thread Ihren Code beschädigen könnte. Wie bereits erwähnt, ist dies meist auf eine falsche Verwendung der externen Eigenschaft zurückzuführen. Externe Verweise sollten in fast allen Fällen auf eine bestimmte Revisionsnummer im externen Repository-URI verweisen. Dadurch wird sichergestellt, dass sich das externe System niemals ändert, es sei denn, Sie ändern es so, dass es auf eine andere Versionsnummer verweist.

Für einige unserer internen Bibliotheken, die wir in unseren Endbenutzerprojekten als externe Bibliotheken verwenden, hat es sich als nützlich erwiesen, ein Tag der Bibliothek in der Major.Minor-Version zu erstellen, in dem keine wesentlichen Änderungen erzwungen werden. Mit einem Vier-Punkte-Versionsschema (Major.Minor.BugFix.Build) ermöglichen wir, dass das Tag mit BugFix.Build-Änderungen auf dem neuesten Stand gehalten wird (auch hier werden keine wesentlichen Änderungen erzwungen). Dies ermöglicht es uns, einen externen Verweis auf das Tag ohne Versionsnummer zu verwenden. Bei größeren oder anderen Änderungen wird ein neues Tag erstellt.

Externe selbst sind nicht schlecht, aber das hindert die Leute nicht daran, schlechte Implementierungen von ihnen zu erstellen. Es erfordert nicht viel Recherche, nur ein wenig Lesen einiger Dokumentationen, um zu lernen, wie man sie sicher und effektiv einsetzt.

Wenn Plain External ein Anti-Pattern ist, weil es Ihr Repository beschädigen kann, sollte eines mit expliziter Revision dies nicht tun.

Auszug aus dem SVN-Buch :

Eine externe Definition ist eine Zuordnung eines lokalen Verzeichnisses zur URL ** - und möglicherweise einer bestimmten Revision - ** einer versionierten Ressource.

Ich denke, es hängt alles von Ihrem Verwendungszweck ab. Es ist kein Anti-Pattern für sich.

Es gibt bestimmte Fehler bei Subversion-Externals, aber wir scheinen sie ziemlich erfolgreich zu verwenden, um Bibliotheken (sowohl unsere eigenen als auch die des Anbieters) einzubeziehen, von denen das aktuelle Projekt abhängt. Ich sehe sie also nicht als "Anti-Muster". Die wichtigen Verwendungspunkte für mich sind:

• Sie verweisen auf eine bestimmte Revision oder ein bestimmtes Tag (niemals den Kopf) des anderen Projekts.
• Sie werden weit entfernt von ihrem eigenen Quellcode usw. in das aktuelle Projekt eingefügt (z. B. in einem Unterverzeichnis namens "Support-Dateien").
• Sie beziehen sich nur auf die "Schnittstellendateien" anderer Projekte (z. B. Ordner einschließen) und Binärbibliotheken (dh wir erhalten nicht die vollständige Quelle des anderen Projekts).

Auch ich würde mich für größere Risiken dieser Vereinbarung und bessere Ansätze interessieren.

Zu sagen, dass a b ist, macht a a b nicht, es sei denn, Sie sagen warum dies so ist.

Der Hauptfehler, den ich bei externen Referenzen in Subversion sehe, ist, dass Sie nicht garantiert sind, dass das Repository vorhanden ist, wenn Sie Ihre Arbeitskopie aktualisieren.

Externe Subversion-Referenzen können verwendet und missbraucht werden, und das Feature selbst ist nichts anderes als genau das, ein Feature . Es kann nicht gesagt werden, dass es sich um ein Muster oder ein Antimuster handelt .

Ich habe die Antwort der Person gelesen, die Sie zitieren, und ich muss sagen, dass ich nicht einverstanden bin. Wenn für Ihr Projekt die Dateiversion XYZ aus einem Repository erforderlich ist, kann Ihnen eine externe Subversionsreferenz dies leicht geben.

Ja, Sie können es falsch verwenden, indem Sie nicht genau angeben, welche Version dieser Referenz Sie benötigen. Wird dir das Probleme bereiten? Wahrscheinlich!

Ist es ein Antimuster? Es hängt davon ab. Wenn Sie dem Link des Autors des von Ihnen zitierten Textes folgen, d. H. hier dann nein. Das etwas verwendet werden kann, um eine schlechte Lösung bereitzustellen, macht die gesamte Methode nicht zu einem Antimuster . Wenn das die Regel wäre, würde ich sagen, dass Programmiersprachen im Großen und Ganzen Antimuster sind, weil man in jeder Programmiersprache schlechte Lösungen finden kann .