Desktop-Client

Installation

Der Desktop-Client ist eine native Anwendung für Windows, macOS (Apple Silicon) und Linux. Die Installer für Windows, macOS und Linux bündeln außerdem die uversion-CLI und machen sie verfügbar. Herunterladen unter /downloads.

Windows

Laden Sie uVersion_x.y.z_x64-setup.exe herunter (signierter NSIS-Installer, ~25 MB). Beim Start führt der Installer Folgendes aus:

• Installiert den Client nach %LOCALAPPDATA%\uVersion (pro Benutzer, keine Adminrechte nötig)
• Fügt den Installationsordner dem Benutzer-PATH hinzu (die uversion.exe-CLI ist dort gebündelt)
• Erstellt eine Verknüpfung im Startmenü
• Aktiviert das Auto-Update über den Tauri-Updater

Windows im großen Stil: das MSI

Um auf vielen Rechnern mit einem Verwaltungswerkzeug (Intune, SCCM, Gruppenrichtlinie...) auszurollen, verwenden Sie das MSI statt des NSIS-Installers: uVersion_latest_x64_en-US.msi (stabile URL, immer die neueste Version, ~10 MB). Stille Installation, pro Rechner:

msiexec /i uVersion_latest_x64_en-US.msi /qn /norestart

• Installiert nach C:\Program Files\uVersion (Adminrechte erforderlich). Die uversion.exe-CLI ist enthalten, aber der Ordner wird nicht zum PATH hinzugefügt: Wenn Ihre Benutzer sie im Terminal brauchen, lassen Sie sie über das Bereitstellungswerkzeug hinzufügen.
• Kein Auto-Update bei einer MSI-Installation: Der Client bleibt auf der ausgerollten Version, und Flotten-Updates erfolgen durch erneutes Ausrollen des nächsten MSI. Das ist Absicht: Der integrierte Updater würde eine zweite, benutzerbezogene Kopie neben der verwalteten installieren.
• Stille Deinstallation: msiexec /x uVersion_latest_x64_en-US.msi /qn

Beim ersten Öffnen gibt jeder Benutzer die Serveradresse ein und bestätigt den Zertifikats-Fingerabdruck, einmal pro Benutzer und pro Rechner (siehe TLS-Fingerabdruck).

macOS (Apple Silicon)

Laden Sie uVersion_x.y.z_macos-arm64.app.zip herunter (~32 MB, mit Developer ID signiert und von Apple notariell beglaubigt). Doppelklicken zum Entpacken, dann uVersion.app nach /Applications ziehen. Beim ersten Start prüft Gatekeeper die Beglaubigung automatisch, ohne Warnung.

Die uversion-CLI ist in der App gebündelt. Beim ersten Start legt der Client automatisch einen symbolischen Link nach ~/.local/bin/uversion an und fügt ~/.local/bin über ~/.zprofile Ihrem PATH hinzu: keine manuelle Aktion nötig. Öffnen Sie ein neues Terminal, und uversion ist verfügbar.

Hinweis: Nur Apple Silicon (M1/M2/M3/M4) wird unterstützt. Kein Intel-Binary.

Linux

Ein einziges Format für x86_64: das AppImage (uVersion_x.y.z_amd64.AppImage, ~85 MB). Portabel, es bündelt seine Abhängigkeiten (libwebkit2gtk, libgtk, libsoup usw.) und läuft ohne Systeminstallation auf jeder aktuellen Distribution. Voraussetzung: Ubuntu 24.04 oder höher, Debian 13 oder höher, oder eine Distribution einer gleichwertigen Generation. Das Binary verlangt eine aktuelle System-C-Bibliothek, und das AppImage senkt diese Untergrenze nicht: Es bündelt die grafische Umgebung, nicht die C-Bibliothek.

Der empfohlene Weg ist das Installationsskript. Ohne sudo:

curl -fSL https://uversion.io/downloads/client/install.sh | sh

Es tut nichts Magisches, und vor allem nichts, was Rechte verlangt:

• Es weigert sich, als root, auf einer Architektur außer x86_64 oder auf einem für das Binary zu alten System zu laufen, und sagt dabei, welches der drei das Problem ist;
• Es lädt das AppImage nach ~/Applications/uVersion.AppImage herunter, prüft, dass das Angekommene wirklich ein Linux-Executable ist (sonst würden ein Captive-Portal oder eine Fehlerseite gespeichert und ausführbar gemacht, um später auf unverständliche Weise zu scheitern), und setzt es dann in einem einzigen Schritt an seinen Platz, was sicher bleibt, selbst wenn bereits eine Kopie läuft;
• Es startet die Anwendung. Genau dieser Start erzeugt den Eintrag im Anwendungsmenü, also lässt man ihn besser geschehen. In einer Remote-Sitzung ohne grafische Oberfläche zeigt es stattdessen den genauen Befehl an, den Sie von Ihrem eigenen Desktop aus eingeben sollen.

Sie können das AppImage auch von Hand über die Download-Seite herunterladen, es ausführbar machen und starten:

chmod +x uVersion_x.y.z_amd64.AppImage
./uVersion_x.y.z_amd64.AppImage

Es gibt kein .deb-Paket für den Client, und es wird keins geben: Ein per dpkg installiertes Paket kann sich nur aktualisieren, indem es erneut über dpkg geht, also über eine Rechteerhöhung bei jeder Version, was für einen Rechner ohne Adminrechte unmöglich ist. Das AppImage ersetzt sich selbst, ohne Passwort. Der Server hingegen behält sein .deb-Paket.

Hinweis: Die uversion-CLI ist im AppImage gebündelt. Beim ersten Start kopiert der Client das Binary nach ~/.local/bin/uversion und fügt ~/.local/bin über ~/.profile Ihrem PATH hinzu (keine manuelle Aktion nötig). Der Eintrag im Anwendungsmenü wird beim ersten Start aus demselben Grund erstellt: Ein AppImage ist eine Datei, keine Installation.

Erster Start

1. Serveradresse und Ihre Anmeldedaten eingeben

Beim ersten Start zeigt der Client die Login-Seite mit dem Titel Welcome to uVersion. Das Feld Server address erwartet keine vollständige URL: Es ist in drei Blöcke geteilt, ein nicht änderbares https://-Präfix, den Host und den Port (standardmäßig 8443). Das Schema ist vorgegeben, der Client kann kein http:// erzeugen. Fügt man eine vollständige Adresse oder ein host:port in das Host-Feld ein, verteilt es sich automatisch auf die beiden Felder. Geben Sie dann Username und Password ein und klicken Sie auf Sign in.

2. Den Server-Fingerabdruck einmalig prüfen

Da ein uVersion-Server standardmäßig selbstsigniert ist, zeigt die allererste Verbindung zu einem bestimmten Rechner Verify server identity: Vergleichen Sie den SHA-256-Fingerabdruck mit dem, den Ihr Administrator Ihnen gegeben hat, und klicken Sie dann auf Trust this server. Die Frage wird nur einmal pro Server gestellt, und wenn sie unter dem roten Titel Server identity changed wiederkommt, hat sich der Fingerabdruck geändert: Akzeptieren Sie nicht ohne zu prüfen. Siehe TLS-Fingerabdruck.

Nach der Verbindung merkt sich der Client Ihre Sitzung auf sichere Weise. Die uversion-CLI und die Editor-Plugins (Unreal, Rider) verwenden automatisch dieselben Anmeldedaten: Sie geben Ihr Passwort nirgendwo sonst erneut ein.

Repository öffnen oder klonen

Das Anmelden öffnet kein Projekt: Die Repository-Liste wird ausdrücklich angefordert. Dasselbe Fenster dient dazu, ein Projekt zum ersten Mal zu klonen und einen bereits auf der Platte vorhandenen Workspace wieder zu öffnen.

1. Das Fenster Open Repository öffnen

Solange kein Tab geöffnet ist, zeigt der Workspace No repository selected und eine Schaltfläche Open Repository. Sobald Sie mindestens einen Tab haben, erreichen Sie dasselbe Fenster über das + der Tab-Leiste. Das Fenster listet, eine Karte pro Projekt, die Repositories auf, auf die Sie Zugriff haben, mit einer Schaltfläche Refresh, um die Liste erneut beim Server anzufordern.

2. Klonen oder einen vorhandenen Workspace wieder öffnen

Jede Karte bietet die Aktion, die zu ihrem Zustand passt:

• Clone: erstellt einen neuen Workspace. Das Feld Workspace name der Karte benennt den erstellten Ordner und übernimmt den Projektnamen, wenn es leer bleibt. Der folgende Ordner-Dialog fragt nach dem übergeordneten Ordner: Den Unterordner legt uVersion selbst an.
• Clone New: dieselbe Schaltfläche, umbenannt, wenn für dieses Projekt bereits ein Workspace existiert. Ein zweites Klonen ist legitim, etwa um zwei Zustände des Projekts nebeneinander zu halten.
• Open: öffnet einen auf diesem Rechner bereits geklonten Workspace wieder, dessen Pfad unter der Karte angezeigt wird. Switch to Open Tab erscheint stattdessen, wenn der Tab bereits offen ist.
• Open Local Repository..., unten im Fenster: verweist auf einen Ordner, der bereits ein .uversion/ enthält, zum Beispiel nachdem ein Workspace verschoben wurde.

Das Kontrollkästchen Download files after clone unten ist standardmäßig aktiviert und startet den Download direkt nach dem Klonen. Deaktivieren Sie es, um den Workspace jetzt zu erstellen und die Dateien später zu holen.

3. Dem Download folgen

Das Fenster schließt sich, sobald der Klon startet, und das ist Absicht: Die Übertragung kann Stunden dauern und darf Sie nicht blockieren. Der Fortschritt läuft in der Kopfzeile des Clients weiter, der Workspace-Tab öffnet sich am Ende von selbst, und ein Netzausfall verliert nichts, da die Übertragung von selbst weiterläuft.

Workspace

Ein Workspace ist ein lokaler Ordner, der mit einem Server-Repository verknüpft ist. Der Client kann mehrere Workspaces gleichzeitig verwalten, angezeigt in der Tab-Leiste oben. Jeder Workspace speichert seine Metadaten in .uversion/ im Wurzelverzeichnis des lokalen Ordners:

• .uversion/config.toml: die einzige wirklich wichtige Datei. Ihr Abschnitt [workspace] trägt den Eigentümer des Workspace (owner), seine Kennung, seinen Namen und last_synced_revision, die Revision, auf die Sie synchronisiert sind (es gibt keine .last_sync-Datei). Hier wird auch der Pfad zur Unreal-Engine gemerkt.
• .uversion/checkouts_<workspace_id>.json: die Sperren, die SIE in diesem Workspace halten
• .uversion/changelists_<workspace_id>.json: Ihre Changelists, also Bündel ausgecheckter Dateien, die Sie gruppieren, um sie getrennt zu übermitteln. Rein lokal, nie an den Server übertragen.
• .uversion/pending_deletes_<workspace_id>.json: die zur Übermittlung anstehenden Löschungen
• .uversion/snapshots.json: der bekannte Zustand der Dateien, der dazu dient, zu erkennen, was Sie lokal geändert haben

Files-Tab

Baumansicht der Workspace-Dateien mit ihrem Zustand. Zwei Wege, die Liste einzugrenzen:

• Das Suchfeld, betitelt Search files...: filtert nach einem Teil des Pfads, ohne auf Groß-/Kleinschreibung zu achten.
• Die Status-Chips, direkt darunter. Es sind anklickbare Zähler, und ein Chip erscheint nur, wenn sein Zähler über null liegt: Auf einem frisch synchronisierten Workspace sehen Sie daher nur {n} synced, und das Fehlen der anderen ist normal. Die sechs möglichen Chips sind {n} synced, {n} modified, {n} local only, {n} server only, {n} locked und {n} deleted.

Suche und Chips kombinieren sich: Die Suche schränkt zuerst ein, die Chips filtern danach. Die Ansicht bleibt selbst bei Projekten mit mehreren zehntausend Dateien flüssig.

Mehrfachauswahl + Aktionen

Die Aktionsleiste existiert nur, wenn etwas ausgewählt ist. Solange die Auswahl leer ist, gibt es keine Schaltfläche: Das ist normal, es ist kein laufender Ladevorgang. Wählen Sie Dateien aus (Klick + Shift, oder die Kontrollkästchen), und die Leiste erscheint, vorangestellt die Anzahl der gewählten ({n} file(s) selected). Die Schaltflächen erscheinen je nachdem, was die Auswahl zulässt:

Pending-Tab

Derzeit ausgecheckte, von Ihnen ODER von einem anderen Benutzer gesperrte Dateien. Zwei Abschnitte:

• Your locks: Sie können einzeln checkin, revert oder release durchführen
• Other users' locks: Sie sehen, wer die Sperre hält, plus eine Schaltfläche Request release, die eine Anfragekarte im Production-Board erstellt (ein request-Badge)

Admins sehen auf fremden Sperren zusätzlich eine Schaltfläche Force unlock, die die Sperre ohne Zustimmung des Halters release. Jedes Force unlock wird auditiert.

History-Tab

Paginierte Liste der Commits des Repositorys, mit Autor, Datum, Nachricht und geänderten Dateien. Ein Klick auf einen Commit öffnet die Detailansicht: die vollständige Liste der Dateien des Commits mit ihren Revisionen.

Eine Schaltfläche Get all auf jedem Commit lädt eine lokale Kopie aller Dateien in dieser Revision herunter (nützlich, um einen stabilen Zustand wiederzubekommen).

Production

Der Bereich Production (ein eigener Eintrag in der Seitenleiste) bündelt die Projektverfolgung, pro Repository. Der Workspace konzentriert sich seinerseits auf die Dateien (Files, Pending, History).

My tasks

Die Liste der Ihnen zugewiesenen Karten, aggregiert über alle Repositories, auf die Sie Zugriff haben.

Board

Kanban-Board pro Repository, mit konfigurierbaren Spalten (standardmäßig To Do, In Progress, Review, Done). Jede Karte trägt eine Priorität (low / normal / high / urgent), Labels, Zugewiesene, ein Fälligkeitsdatum, Kommentare, Links zu Assets oder Commits und ein Titelbild.

Dashboard

Das Cockpit des Producers: ein Banner zur Projektgesundheit (offene Blocker, ausstehende Playtest-Berichte), die Zonen, in denen sich die Probleme konzentrieren, die Commits der Woche, das Projektgewicht und der zuletzt veröffentlichte Build, wobei jeder Block auf das Board oder auf Games verweist.

Darunter die Kalender-Timeline: Meilensteine, Playtests (einmalig oder wiederkehrend), Releases und Fälligkeitsdaten von Karten. Ein wiederkehrender Playtest erzeugt bei jedem Auftreten automatisch seine Board-Karte.

Watchlist

Überwachen Sie Pfade (Glob-Muster), um über die Check-ins benachrichtigt zu werden, die sie berühren. Jeder Eintrag gibt den überwachten Pfad und die verfolgten Ereignisse an.

Games

Der Bereich Games listet die für das Projekt veröffentlichten internen Playtest-Builds auf. Jeder Build gibt seine Version, seine Konfiguration (DebugGame / Development / Shipping), seine Plattform (Win64 / Mac / Linux), seine Größe und seine Release Notes an, mit einer zur Plattform passenden Download-Schaltfläche.

Es ist der Zugangspunkt der Playtester: Ein Konto mit der Rolle playtester sieht nur diese Seite (weder Workspace noch Production) und erreicht nur die Builds der ihm geöffneten Projekte.

Lokale Changelists

Gruppieren Sie Ihre ausgecheckten Dateien in mehrere unabhängige Commits. Changelists sind lokal zu Ihrem Workspace (nie an den Server gesendet). Nützlich, um:

• einen kritischen Fix von laufender Arbeit zu trennen
• mehrere Übermittlungen parallel vorzubereiten, ohne alles zu vermischen
• ein „default“-Changelist für WIP und ein „review“ für das, was zum Checkin geht, zu halten

Settings

Globale Einstellungen des Clients (gespeichert in %APPDATA%/uversion/uVersion/config/config.toml):

Unreal-Panel

Wenn der Client ein Unreal-Projekt im Workspace erkennt, erscheint oben rechts im Workspace eine eigene Aktionsleiste. Sie steuert die Engine direkt aus dem Client: den Editor öffnen, kompilieren, paketieren, ohne über eine IDE zu gehen. Die meisten Aktionen betreffen nur C++-Projekte (ein reines Blueprint-Projekt muss nicht kompilieren).

Das Plugin-Status-Pill

Ganz links in der Leiste zeigt ein Pill an, wo das Unreal-Plugin für dieses Projekt steht. Es ist anklickbar:

Engine-Pfad

Der Installationspfad von Unreal wird automatisch aus der EngineAssociation der .uproject aufgelöst (Windows-Registry, LauncherInstalled.dat oder Source-Build). Dieser Pfad ist für alle Aktionen unten erforderlich, und die automatische Auflösung scheitert insbesondere bei einer aus dem Quellcode kompilierten Engine. Hier stellen Sie ihn von Hand ein.

1. Das Menü der sekundären Aktionen öffnen

Es gibt weder ein Eingabefeld noch eine Browse-Schaltfläche noch eine Auto-detect-Schaltfläche, die in der Leiste sichtbar wäre. Der einzige Einstieg ist die zahnradförmige Schaltfläche, ganz rechts in der Unreal-Leiste, begleitet von einem kleinen Chevron, deren Tooltip More actions sagt. Nichts an ihrem Aussehen spricht von der Engine, und genau deshalb findet man sie nicht.

2. Set Engine Path... wählen

Der Eintrag Set Engine Path... ist der letzte des Menüs. Sein Untertitel zeigt den aktuellen Pfad an, oder Not configured, wenn keiner vorhanden ist: Es ist der schnellste Weg zu wissen, ob das Problem von dort kommt. Ein Ordner-Dialog öffnet sich, und der gewählte Pfad wird in der .uversion/config.toml des Workspace gespeichert.

Open Editor

Startet den Unreal-Editor (UnrealEditor) auf dem Projekt des Workspace. Die Schaltfläche ist idempotent: Der Editor kann mehrere Dutzend Sekunden brauchen, um sein Fenster anzuzeigen (besonders auf macOS / Linux), sodass ein zweiter Klick in dieser Zeit keine zweite Instanz öffnet. Die Schaltfläche zeigt „Opening…“, solange der Editor startet. Bei einem C++-Projekt, das lokal nie kompiliert wurde, löst das Öffnen des Editors zuerst eine Generierung der Projektdateien und dann eine Kompilierung aus (siehe Automatische Aktionen).

Compile

Kompiliert das Projekt (Unreal Build Tool). Die Ausgabe erscheint in Echtzeit in einer integrierten Konsole. Ein C++-Projekt muss kompiliert werden, damit der Editor es öffnen kann und um Codeänderungen widerzuspiegeln.

Sync und Status

Diese beiden Schaltflächen leben in derselben Leiste, nicht im Files-Tab:

• Sync: aktualisiert den gesamten Workspace vom Server. Sein Tooltip nennt die Anzahl der ausstehenden Dateien, wenn es welche gibt. Es ist das echte „Sync“ des Clients, nicht zu verwechseln mit der Schaltfläche Download des Files-Tabs, die nur die Auswahl holt.
• Status: aktualisiert den serverseitigen Zustand, einschließlich der Sperren anderer Benutzer, und stellt den Zähler der Schaltfläche Sync neu ein.

Das More-actions-Menü

Die selteneren Aktionen sind hinter der zahnradförmigen Schaltfläche rechts in der Leiste zusammengefasst (Screenshot oben):

• Generate Project Files: regeneriert die Projektdateien der IDE (Visual Studio, Rider). Nützlich, nachdem Quelldateien hinzugefügt oder entfernt wurden, oder nach einem Klon.
• Publish Editor Binaries: kompiliert und veröffentlicht dann die Editor-Binaries, die dem letzten Code-Commit entsprechen. Ihre Teamkollegen holen sie beim Sync, statt jeder für sich neu zu kompilieren. Unter Linux nicht vorhanden.
• Force Sync: lädt erneut herunter und überschreibt Ihre lokalen Dateien. Im Menü rot gekennzeichnet, mit dem Hinweis overwrites local, und von einer Bestätigung vorangestellt. Nur für Workspaces, deren Verlust man in Kauf nimmt.
• Set Engine Path...: die oben beschriebene Einstellung des Engine-Pfads.

Package

Die Schaltfläche heißt Package; „Package Game“ ist nur ihr Tooltip, ersetzt durch Set Engine Path first, wenn der Engine-Pfad fehlt, wobei die Schaltfläche dann deaktiviert ist. Sie paketiert das Spiel über RunUAT BuildCookRun und archiviert das Ergebnis in Packages/{config}/ im Wurzelverzeichnis des Workspace. Drei Konfigurationen zur Auswahl:

Der Ordner Packages/ wird standardmäßig ignoriert (.uversionignore): Die paketierten Builds werden nicht versioniert, sie werden über Publish Build verteilt.

Publish Build

Veröffentlicht einen paketierten Build als interne Playtest-Version. Er wird von Ihrem Team über die Games-Seite des Clients herunterladbar (Rolle playtester oder gewährter Build-Zugriff). Der Client scannt Packages/{config}/, lädt die Dateien hoch (serverseitig dedupliziert) und registriert dann das Manifest.

Open project folder

Öffnet den Workspace-Ordner im Datei-Explorer des Systems (Windows Explorer, Finder oder xdg-open unter Linux).

Stop

Unterbricht sauber alle laufenden Builds: Kompilierung und Paketierung. Die Schaltfläche nennt, wie viele Builds gestoppt wurden (eine im Hintergrund gestartete Auto-Kompilierung kann mitgezählt werden).

Automatische Aktionen

Zusätzlich zu den Schaltflächen löst der Client bestimmte Unreal-Aktionen von selbst aus, damit ein C++-Projekt stets aktuell und kompilierbar bleibt:

• Vor einem Check-in: Wenn sich Code-Dateien geändert haben, wird das Projekt zuerst kompiliert. Wenn die Kompilierung scheitert, wird der Check-in blockiert (man übermittelt keinen Code, der nicht kompiliert).
• Nach einem Sync: Wenn der Sync Code heruntergeladen hat, regeneriert der Client die Projektdateien und kompiliert dann neu.
• Beim ersten Start nach einem Klon (C++-Projekt): Generierung der Projektdateien und dann Kompilierung, bevor man den Editor öffnen kann.

Diese automatischen Builds serialisieren sich über die Engine-Sperre (Unreal Build Tool -WaitMutex): Sie weisen sich nicht gegenseitig ab, sie reihen sich aneinander. Die Schaltfläche Stop unterbricht auch sie.