Wiki

Desktop-Client

Der uVersion Desktop-Client für Windows, macOS und Linux: Installation, Workspace, Tabs, Einstellungen.

Installation

Der Desktop-Client ist eine native Anwendung, verfügbar für Windows, macOS (Apple Silicon) und Linux. Die Installationsprogramme für Windows, macOS und Linux enthalten außerdem die uversion-CLI und machen sie verfügbar. Laden Sie ihn unter /downloads herunter.

Windows

Laden Sie uVersion_x.y.z_x64-setup.exe herunter (signiertes NSIS-Installationsprogramm, ~25 MB). Beim Ausführen führt das Installationsprogramm Folgendes aus:

Installiert den Client nach %LOCALAPPDATA%\uVersion (pro Benutzer, keine Administratorrechte erforderlich)
Fügt den Installationsordner dem Benutzer-PATH hinzu (die uversion.exe-CLI ist dort enthalten)
Erstellt eine Verknüpfung im Startmenü
Aktiviert die automatische Aktualisierung über den Tauri-Updater

macOS (Apple Silicon)

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

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

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

Linux

Zwei Formate für x86_64:

AppImage (uVersion_x.y.z_amd64.AppImage, ~76 MB): portabel, enthält alle Abhängigkeiten (libwebkit2gtk, libgtk, libsoup usw.). Läuft auf jeder Linux-Distribution ohne Systeminstallation:
```
chmod +x uVersion_x.y.z_amd64.AppImage
./uVersion_x.y.z_amd64.AppImage
```
.deb-Paket (uVersion_x.y.z_amd64.deb, ~5 MB): für Ubuntu / Debian / Derivate. apt löst die Systemabhängigkeiten auf:
```
sudo apt install ./uVersion_x.y.z_amd64.deb
```
Die App wird nach /usr/bin/uVersion installiert.

Hinweis: Die uversion-CLI ist in den Linux-Paketen enthalten. 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 erforderlich).

Erster Start

Beim ersten Start zeigt der Client die Login-Seite an. Geben Sie ein:

Serveradresse: die Adresse Ihres Studios (z. B. https://uversion.mygamestudio.com)
Benutzername und Passwort

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

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 Stammverzeichnis des lokalen Ordners:

.uversion/config.toml: owner, repo_id, server URL, workspace UUID
.uversion/checkouts_<workspace_id>.json: Locks, die SIE in diesem Workspace halten
.uversion/changelists_<workspace_id>.json: lokale Changelists
.uversion/.last_sync: zuletzt synchronisierte Revision (für inkrementelle Syncs)

Files-Tab

Der Dateibaum mit den Statusfiltern (Synced, Modified, Local only, Locked…) und der Suchleiste.

Baumansicht der Workspace-Dateien mit ihrem Status. Verfügbare Filter:

Search: Suche per Teilzeichenfolge im Path (ohne Berücksichtigung der Groß-/Kleinschreibung)
Status filters: Synced, Modified, Local only, Server only, Locked, Deleted

Die Ansicht bleibt selbst bei Projekten mit mehreren Zehntausend Dateien flüssig.

Mehrfachauswahl + Aktionen

Wählen Sie mehrere Dateien aus (Klick + Umschalt oder Kontrollkästchen aktivieren) und dann:

Checkout: erwirbt die Locks (idempotent; das erneute Checkout einer bereits gelockten Datei ist ein No-op)
Sync: lädt die ausgewählten Dateien erneut herunter (nützlich, wenn eine Datei lokal beschädigt ist)
Revert: gibt den Lock frei, stellt die Serverversion wieder her

Pending-Tab

Dateien, die derzeit ausgecheckt und von Ihnen ODER von einem anderen Benutzer gelockt sind. Zwei Abschnitte:

Your locks: Sie können sie einzeln einchecken (checkin), zurücksetzen (revert) oder freigeben (release)
Other users' locks: Sie sehen, wer den Lock hält, plus eine Schaltfläche Request release, die eine Request-Karte im Production-Board erstellt (ein request-Badge)

Admins sehen außerdem eine Schaltfläche Force unlock bei fremden Locks, die den Lock ohne Zustimmung des Inhabers freigibt. Jedes Force Unlock wird protokolliert.

History-Tab

Ein aufgeklappter Commit mit seiner Dateiliste und der Schaltfläche Get all des Commits.

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 an jedem Commit lädt eine lokale Kopie aller Dateien in dieser Revision herunter (nützlich, um einen stabilen Zustand wiederherzustellen).

Production

Der Bereich Production (ein eigener Eintrag in der Seitenleiste) bündelt die Projektverfolgung, pro Repository. Er ersetzte die alten Tabs Activity und Requests des Workspace: Der Workspace konzentriert sich nun auf Dateien (Files, Pending, History).

My tasks

Die Ihnen zugewiesenen Aufgaben, über alle Projekte hinweg.

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

Board

Das Kanban: Spalten To Do / In Progress / Review / Done, Karten mit Priorität, Labels, Zugewiesenen, Covern.

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 Cover-Bild.

Requests sind Board-Karten Die alten Modification Requests (zum Beispiel 'Request release' auf einem Lock, das jemand anderes hält, im Pending-Tab) sind jetzt Board-Karten mit einem request-Badge. Es gibt keinen separaten Requests-Tab mehr.

Eine geöffnete Karte: Beschreibung, Zugewiesene, Fälligkeitsdatum, Kommentare, Asset-/Commit-Links, Cover.

📷 Screenshot · production-request-cards

Karten vom Typ Request (Badge) in der Spalte Review.

Activity

Einheitliches Dashboard:

24-h-KPIs: Commits, aktive Einreicher, aktive Locks
Aktivitätskalender: Commits pro Tag über mehrere Monate (Heatmap)
Recent Checkins und Most Modified Directories
Commit History: paginierte Commits mit Filtern nach Benutzer und nach Pfad

Watchlist

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

Games

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

Das ist der Zugangspunkt für Playtester: Ein Konto mit der Rolle playtester sieht nur diese Seite (weder Workspace noch Production) und greift nur auf die Builds der ihm geöffneten Projekte zu.

Lokale Changelists

📷 Screenshot · client-changelists

Ausgecheckte Dateien, aufgeteilt auf zwei lokale Changelists (zum Beispiel 'default' und 'review').

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

einen kritischen Fix von laufender Arbeit zu trennen
mehrere Einreichungen parallel vorzubereiten, ohne alles zu vermischen
eine "default"-Changelist für WIP und eine "review"-Changelist für das zu behalten, was in einen Checkin geht

Settings

Globale Client-Einstellungen (gespeichert in %APPDATA%/uversion/uVersion/config/config.toml):

Option	Beschreibung
Default server URL	Auf der Login-Seite vorausgefüllt
Username	Auf der Login-Seite vorausgefüllt
Theme	System / Light / Dark
Show hidden files	Dateien anzeigen, die mit `.` beginnen, im Files-Tab
Auto-sync interval	Deaktiviert / 5 Min. / 15 Min. / 30 Min.: löst einen automatischen inkrementellen Sync aus
Parallel uploads	Obergrenze für die Concurrency (1-32, Standard 16)
Default repos path	Beim Klonen standardmäßig vorgeschlagener Ordner

Unreal-Panel

📷 Screenshot · client-unreal-panel

Das Unreal-Panel mit seinen Aktionsschaltflächen: Open Editor, Compile, Package Game und dessen Konfigurationsauswahl, Publish Build, Stop.

Wenn der Client ein Unreal-Projekt im Workspace erkennt (Vorhandensein einer .uproject-Datei), erscheint ein spezielles Panel. Es steuert die Engine direkt vom Client aus: den Editor öffnen, kompilieren, paketieren, ohne den Umweg über eine IDE. Die meisten Aktionen betreffen nur C++-Projekte (ein reines Blueprint-Projekt muss nicht kompiliert werden).

Engine path

Die Unreal-Version wird automatisch aus dem EngineAssociation der .uproject erkannt (Windows-Registry, LauncherInstalled.dat oder Source-Build). Sie können sie manuell überschreiben, falls die Erkennung fehlschlägt. Dieser Pfad ist für alle folgenden Aktionen erforderlich.

Open Editor

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

Compile

📷 Screenshot · client-compile-console

Die eingebettete Konsole, die die Kompilierungsausgabe des Unreal Build Tool in Echtzeit anzeigt.

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

Generate Project Files

Erzeugt die IDE-Projektdateien neu (Visual Studio, Rider). Nützlich nach dem Hinzufügen oder Entfernen von Quelldateien oder nach einem Clone. Zu finden im Menü „…“ (weitere Aktionen) des Panels.

Package Game

Paketiert das Spiel über RunUAT BuildCookRun und archiviert das Ergebnis in Packages/{config}/ im Workspace-Stammverzeichnis. Drei Konfigurationen stehen zur Auswahl:

Config	Verwendung
`DebugGame`	Debug-Build (vollständige Symbole, nicht optimiert).
`Development`	Development-Build (Standard): optimiert, aber mit den Dev-Tools.
`Shipping`	Distributions-Build: optimiert, ohne die Dev-Tools.

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 für Ihr 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 Dateimanager des Systems (Windows-Explorer, Finder oder xdg-open unter Linux).

Stop

Bricht alle laufenden Builds sauber ab: Kompilierung und Paketierung. Die Schaltfläche zeigt an, wie viele Builds gestoppt wurden (eine im Hintergrund gestartete automatische 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 Codedateien geändert haben, wird das Projekt zuerst kompiliert. Schlägt die Kompilierung fehl, wird der Check-in blockiert (man reicht keinen Code ein, der nicht kompiliert).
Nach einem Sync: Wenn der Sync Code heruntergeladen hat, erzeugt der Client die Projektdateien neu und kompiliert erneut.
Beim ersten Start nach einem Clone (C++-Projekt): Generierung der Projektdateien und anschließende Kompilierung, bevor der Editor geöffnet werden kann.

Diese automatischen Builds werden über den Engine-Lock (Unreal Build Tool -WaitMutex) serialisiert: Sie weisen sich nicht gegenseitig ab, sondern reihen sich aneinander. Die Schaltfläche Stop unterbricht sie ebenfalls.