Wiki

Verteilung

Dateien (Plugins, geteilte Inhalte) anhand von Pfadmustern aus einem Quell-Repository in ein Ziel-Repository kopieren. Veröffentlichung, Remapping, übersprungene Sperren.

Einführung

Die Verteilung kopiert Dateien (ein Plugin, ein Paket geteilter Inhalte) aus einem Quell-Repository in ein Ziel-Repository, beschränkt auf Pfadmuster. Sie erzeugt neue Revisionen im Ziel, sodass die übliche inkrementelle Synchronisierung den Inhalt an die Clients verteilt. So lässt sich dasselbe Plugin ohne manuelles Kopieren und Einfügen über mehrere Projekte hinweg teilen.

Zugriff und Rollen

Ein anderes Zugriffsmodell als bei den übrigen Tabs Die Verteilung ist nicht wie die anderen Tabs abgesichert. Sie erfordert die Fähigkeit manage_rules, die admin und lead serverweit besitzen. Ein project_admin, der keine Fähigkeit besitzt, hat keinen Zugriff. Ein lead hingegen kann jedes Repository mit jedem anderen verknüpfen.

Eine Verknüpfung erstellen

1. Den Tab Distribution öffnen

Der Tab Distribution befindet sich in der Zeile SERVER: eine Verknüpfung verbindet zwei Repositories, sie hängt also nicht von dem in der Zeile PROJECT gewählten Repository ab. Klicken Sie oben rechts auf + New Link: das Fenster New Distribution Link öffnet sich.

2. Quelle, Ziel und Pfade wählen

Source Repository ist das Repository, aus dem die Dateien stammen, Target Repository das Ziel-Repository: die gewählte Quelle verschwindet aus der Zielliste, eine Verknüpfung kann nicht auf sich selbst zurückführen. Path Patterns nimmt ein Muster pro Zeile (zum Beispiel Plugins/MyPlugin/, Content/SharedAssets/), und mindestens eines ist erforderlich: ohne Muster würde nichts kopiert.

Das Fenster New Distribution Link: die Menüs Source Repository und Target Repository, der Bereich Path Patterns (one per line) mit zwei Mustern gefüllt, und die Schaltflächen Cancel und Create Link.

3. Mit Create Link bestätigen

Die Verknüpfung erscheint sofort in der Liste. Eine bereits zwischen denselben beiden Repositories bestehende Verknüpfung wird abgelehnt (Konflikt): bearbeiten Sie die vorhandene, statt eine zweite zu erstellen.

Pfadmuster

Ein Muster passt zu einem Pfad, wenn es irgendwo darin auftaucht (Suche vom Typ „enthält“). Ein Muster Plugins/uVersion passt also zu DefaultProject/Plugins/uVersion/Source/Foo.cpp, unabhängig vom Projektpräfix. Der abschließende Schrägstrich ändert nichts.

Veröffentlichen

1. Die Verknüpfung und ihre Aktionen finden

Jede Verknüpfung belegt eine Zeile der Liste: source → cible, ihre Muster als Chips, wer sie erstellt hat und das Datum der letzten Veröffentlichung. Die Aktionen sind rechts in der Zeile gruppiert: Show pending files (Datei-Symbol), Publish history (Uhr), Publish, der Schalter, der die Verknüpfung aktiviert oder deaktiviert, und das Löschen.

Der Tab Distribution mit dem Titel Content Distribution und einer Verknüpfung in der Liste: der Name des Quell-Repositorys, der Pfeil, der Name des Ziel-Repositorys, darunter die Muster als Chips, die Zeile Created by und Last published, und rechts die Datei- und Uhr-Symbole, die Schaltfläche Publish, der Schalter und der Papierkorb.

2. Prüfen, was übertragen wird

Show pending files klappt unter der Zeile die Liste der Dateien auf, die sich unterscheiden, mit ihrer Quellrevision und einer Gesamtzahl im Titel (Pending Files (N)). Jede trägt ihren Status: new, modified oder locked. Ist alles auf dem neuesten Stand, sagt das Panel es.

Das unter einer Verknüpfungszeile aufgeklappte Panel Pending Files: die Pfade, markiert als new, modified oder locked, mit ihrer Quellrevision, und über der Liste das grüne Banner der letzten Veröffentlichung.

3. Veröffentlichen

Die Schaltfläche Publish führt das Kopieren aus. Ein grünes Banner fasst zusammen: „Published: X source files found, Y updated, Z skipped (locked), W unchanged“. Die Schaltfläche ist deaktiviert, solange die Verknüpfung inaktiv ist, und das Veröffentlichen einer inaktiven Verknüpfung gibt einen ausdrücklichen Fehler zurück.

Eine im Ziel gesperrte Datei wird übersprungen, nicht überschrieben. Eine Datei mit identischem Inhalt (gleicher Hash) wird als unverändert gezählt und übersprungen. Die Veröffentlichung ist atomar (eine einzige Transaktion).

Publish history (Uhr) liefert anschließend die letzten 50 Veröffentlichungen: wie viele Dateien aktualisiert und übersprungen wurden, von wem und wann.

Remapping und Revisionen

Der Pfad wird für das Ziel umgeschrieben: uVersion entfernt alles, was vor dem passenden Muster steht, und fügt dann das im Ziel erkannte Präfix hinzu. Beispiel: Quelle DefaultProject/Plugins/uVersion/foo.cpp, Muster Plugins/uVersion, Zielpräfix CineDroneStudio/ → CineDroneStudio/Plugins/uVersion/foo.cpp. Das Zielpräfix wird aus einer vorhandenen Datei im Ziel abgeleitet (Behandlung von Repositories mit oder ohne Projektunterordner).

Revisionsnummerierung Verteilte Revisionen verwenden einen globalen Zähler oberhalb der aktuellen Revision des Ziels, damit die inkrementelle Synchronisierung sie erfasst. Der Verlauf einer Datei kann daher „springen“ (z. B. rev 1, dann rev 200): das ist rein kosmetisch. Chunks werden geteilt (keine Datenverdopplung, nur ein Referenzinkrement).

Häufige Stolperfallen

„Publish“ ist ausgegraut

Die Verknüpfung ist inaktiv. Aktivieren Sie sie zuerst. Das Veröffentlichen einer inaktiven Verknüpfung gibt einen ausdrücklichen Fehler zurück.

Eine Datei wird im Ziel nicht aktualisiert

Entweder ist sie auf der Zielseite gesperrt (dann wird sie übersprungen und als „locked“ gezählt), oder ihr Inhalt ist bereits identisch (als „unchanged“ gezählt). Sehen Sie sich die Veröffentlichungszusammenfassung und die Liste der pending files an.

Ein project_admin sieht den Tab nicht

Das ist beabsichtigt: die Verteilung erfordert manage_rules (admin oder lead). Ein project_admin hat keinen Zugriff, auch nicht auf seine eigenen Repositories.