Tag Archives for SVN

git: svn:externals-Äquivalent

Vorab: Ich bin git-Anfänger.

Wenn man nach einem git-Äquivalent zu svn:externals sucht, liest man von zwei Optionen:

  • Subtree merges: “very easy on other users, because it is automatically included when the repository is checked out or cloned”
  • Submodules: “all users have to manage the submodules, which are not automatically included in checkouts”

Die Zitate sind aus dem verlinkten Beitrag, aber die Tendenz “Submodules will man nicht” liest man auch an anderer Stelle [1, 2]. Meiner Meinung nach ist es genau andersrum:

Bei Subtree merges werden die externen Sourcen in das aktuelle Projekt gelegt – und nicht nur verlinkt! Das heißt, man pusht die (vermeintlich) externen Sourcen in das aktuelle Projekt. Ja, dadurch klont sie ab dem Moment auch jeder automatisch (vgl. Zitat oben), trotzdem entspricht das nicht dem Sinn und Zweck.

Darüber hinaus hatte ich zeitweise das Problem, dass Dateien aus dem externen Projekt gleich benamte lokale Dateien überschreiben wollten (bei README.md, composer.json, .gitignore, make, … durchaus ein Problem!). Das mag aber ein Anwenderfehler gewesen sein; nachdem mir Problem #1 klar wurde, habe ich Subtree merges nicht weiter verfolgt.

Submodules erfordern zwei zusätzliche Schritte beim Klonen (git submodule init, git submodule update), sowie einen beim Update, wenn sich das Submodule ebenfalls geändert hat (git submodule update). Dafür sind die externen Sourcen nun “nur” verlinkt, also wie bei SVN Externals. Dumm: Wenn sich das externe Projekt ändert, muss man den “Link” auf den entsprechenden neuen Hash zeigen lassen, und das auch commiten. Passt jemand nicht auf und commitet nun wieder den alten Link, revertet er dadurch die Änderung.

Das spricht aber nicht gegen Submodules als Externals-Ersatz – es spricht höchstens gegen git, wo alles “ein wenig” komplizierter ist, als es sein sollte :-/ PS dazu: Ich habe mein Glück die meiste Zeit auf der Kommandozeile versucht, erst später zeigte Tobi mir Sourcetree. Damit sollte das leichter sein.

Composer: Erste Learnings

Ich versuche gerade, ein Composer-Package zu definieren und aus dem SVN zu installieren, bekomme aber immer die Meldung

Your requirements could not be resolved to an installable set of packages

Es wird nicht ganz klar, ob das an der packages.json im SVN liegt, an der lokalen composer.json, oder irgendwo dazwischen (zB an der Verbindung zum SVN). Leider liefert composer install auch im verbose Modus keine hilfreiche Informationen, aber

hilft. Es zeigt Informationen (zB die description) aus der packages.json (also scheint die Verbindung zum SVN zu klappen), als Version aber nur “dev-trunk”. Offenbar zählt die in der externen composer.json angegebene Version nicht, sondern allein die Tatsache, dass das Package im trunk liegt. Folgendes funktioniert schließlich:

externe composer.json:

lokale composer.json:

Wichtig dabei: “url” enthält nicht “trunk”, und alles hinter “trunk” wandert aus der URL nach “package-path”. So kann man mehrere Packages in einem SVN-Projekt ablegen.

Update “Versionierung”

Eine packages.json wird im externen Package ebensowenig benötigt, wie eine Versionsnummer in der externen composer.json! Die Versionsinformationen ergeben sich implizit aus Tag-/Branchnamen (oder halt “dev-trunk”), was ja auch Sinn macht, denn natürlich enthält das Repository alle Versionen.

Eine ganz bestimmte Revision kann man wohl mit

angeben (Quelle)

Update “SVN”

Mit dem oben beschriebenen Vorgehen muss man für jedes “require” Package ein eigenes Repository definieren. Das ist übrigens unabhängig davon, ob alle Packages in einem SVN-Projekt liegen, oder jedes Package sein eigenes Projekt hat – so lange man nicht jedem Package sein eigenes SVN-Repository geben möchte, kommt man da nicht drumrum. IMHO eine Designschwäche; Composer ist halt sehr auf git fixiert.

Anyway: Eine Möglichkeit, die “repositories” in der lokalen composer.json zu begrenzen, wäre der Einsatz von Satis:

[Satis] can be used to host the metadata of your company’s private packages, or your own.
[…]
You don’t need to copy all your repositories in every project anymore. Only that one unique repository that will update itself.

*Notwendig* ist das nicht, aber es macht die Sache übersichtlicher.

Update “SVN”/2.

Ohne Satis sind “verschachtelte” Abhängigkeiten nicht möglich (siehe), die unschöne “Lösung”: Alle Abhängigkeiten im Root-Projekt definieren (Quelle) 🙁

PS: Composer – und folglich auch Satis – laufen auf uberspace 🙂

Git als offline-Verlängerung von SVN

Ja, dafür ist git nicht gedacht, und ja, git ist viel besser als SVN.

Aber.

Angenommen, man hat ein Projekt im SVN. Und muss nun zum Kunden, bei dem kein Zugriff auf dieses SVN möglich ist. Dann wäre es doch potentiell elegant, das Projekt als git-Projekt auf einen USB-Stick auszuchecken, und gegen dieses portable Repository zu arbeiten. Gesagt, getan:

Dann, beim Kunden, checkt man vom USB-Stick aus:

bzw. arbeitet man dort wie (von git) gewohnt. Später synchronisiert man Stick und lokalen SVN-Checkout, und diesen spielt man zurück in’s SVN.

Danke an Arndt! Quellen: [1], [2], [3], git-svn

Eclipse: Ignore whitespace in file compare

Mitarbeiter des Monats: Frederik. Weil: Vergleicht man zwei Dateien in Eclipse (also etwa eine Revision im SVN mit der lokalen Kopie), stolpert man früher oder später über das Ärgernis unterschiedlicher Line-Breaks / Tabs, … White Spaces halt. Schlimmstenfalls wird jede einzelne Zeile als geändert markiert.

Das kann man aber unterdrücken: Rechtsklick -> “Ignore White Space”, oder unter Einstellungen -> General -> Compare/Patch.

Und gefunden hat das eben Frederik.