Wiki

Client desktop

Le client desktop uVersion pour Windows, macOS et Linux : installation, workspace, tabs, settings.

Installation

Le client desktop est une application native disponible pour Windows, macOS (Apple Silicon) et Linux. Les installeurs Windows, macOS et Linux embarquent aussi le CLI uversion et le rendent accessible. Téléchargez sur /downloads.

Windows

Téléchargez uVersion_x.y.z_x64-setup.exe (installeur NSIS signé, ~25 Mo). Au lancement, l'installeur :

Installe le client dans %LOCALAPPDATA%\uVersion (per-user, pas besoin d'admin)
Ajoute le dossier d'install au PATH utilisateur (le CLI uversion.exe y est embarqué)
Crée un raccourci dans le menu démarrer
Active l'auto-update via Tauri updater

macOS (Apple Silicon)

Téléchargez uVersion_x.y.z_macos-arm64.app.zip (~32 Mo, signé Developer ID et notarisé Apple). Double-clic pour décompresser, puis glissez uVersion.app dans /Applications. Au premier lancement, Gatekeeper valide automatiquement la notarisation, aucun avertissement.

Le CLI uversion est embarqué dans l'app. Au premier lancement, le client crée automatiquement un lien symbolique vers ~/.local/bin/uversion et ajoute ~/.local/bin à votre PATH via ~/.zprofile : aucune action manuelle requise. Ouvrez un nouveau terminal et uversion est disponible.

Note : seul Apple Silicon (M1/M2/M3/M4) est supporté. Pas de binaire Intel.

Linux

Deux formats pour x86_64 :

AppImage (uVersion_x.y.z_amd64.AppImage, ~76 Mo) : portable, embarque toutes les dépendances (libwebkit2gtk, libgtk, libsoup, etc.). Marche sur toute distro Linux sans installation système :
```
chmod +x uVersion_x.y.z_amd64.AppImage
./uVersion_x.y.z_amd64.AppImage
```
Paquet .deb (uVersion_x.y.z_amd64.deb, ~5 Mo) : pour Ubuntu / Debian / dérivés. apt résout les dépendances système :
```
sudo apt install ./uVersion_x.y.z_amd64.deb
```
L'app s'installe dans /usr/bin/uVersion.

Note : le CLI uversion est embarqué dans les paquets Linux. Au premier lancement, le client copie le binaire dans ~/.local/bin/uversion et ajoute ~/.local/bin à votre PATH via ~/.profile (aucune action manuelle requise).

Premier lancement

Au premier lancement, le client affiche la page de login. Entrez :

Adresse du serveur : l'adresse de votre studio (ex : https://uversion.mygamestudio.com)
Nom d'utilisateur et mot de passe

Une fois connecté, le client mémorise votre session de manière sécurisée. Le CLI uversion et les plugins éditeur (Unreal, Rider) réutilisent automatiquement les mêmes identifiants : vous ne ressaisissez votre mot de passe nulle part ailleurs.

Workspace

Un workspace est un dossier local lié à un repository serveur. Le client peut gérer plusieurs workspaces simultanément, affichés dans la barre de tabs en haut. Chaque workspace stocke ses métadonnées dans .uversion/ à la racine du dossier local :

.uversion/config.toml : owner, repo_id, server URL, workspace UUID
.uversion/checkouts_<workspace_id>.json : locks que VOUS détenez dans ce workspace
.uversion/changelists_<workspace_id>.json : changelists locales
.uversion/.last_sync : dernière révision synced (pour les syncs incrémentaux)

Tab Files

Arbre des fichiers avec les filtres de statut (Synced, Modified, Local only, Locked…) et la barre de recherche.

Vue arborescente des fichiers du workspace avec leur status. Filtres disponibles :

Search : recherche par substring dans le path (insensible à la casse)
Status filters : Synced, Modified, Local only, Server only, Locked, Deleted

La vue reste fluide même sur des projets de plusieurs dizaines de milliers de fichiers.

Sélection multiple + actions

Sélectionnez plusieurs fichiers (clic + shift, ou cocher les checkboxes) puis :

Checkout : acquiert les locks (idempotent, re-checkout d'un fichier déjà locked est no-op)
Sync : re-télécharge les sélectionnés (utile si un fichier est corrompu localement)
Revert : release le lock, restore la version serveur

Tab Pending

Onglet Pending : sections « Vos locks » et « Locks des autres », avec les boutons Request release et Force unlock.

Fichiers actuellement checked-out, locked par vous OU par un autre user. Deux sections :

Your locks : vous pouvez checkin, revert, ou release individuellement
Other users' locks : vous voyez qui possède le lock + bouton Request release qui crée une carte de demande dans le board Production (badge request)

Les admins voient aussi un bouton Force unlock sur les locks tiers, qui release le lock sans consentement du holder. Toutes les force unlock sont auditées.

Tab History

Un commit déplié avec sa liste de fichiers et le bouton « Get all » du commit.

Liste paginée des commits du repository, avec auteur, date, message, et fichiers modifiés. Cliquer sur un commit ouvre le détail : liste complète des fichiers du commit avec leurs révisions.

Bouton Get all sur chaque commit pour télécharger une copie locale de tous les fichiers à cette révision (utile pour récupérer un état stable).

Production

La zone Production (entrée dédiée dans la barre latérale) regroupe le suivi de projet, par dépôt. Elle a remplacé les anciens onglets Activity et Requests du Workspace : le Workspace se concentre désormais sur les fichiers (Files, Pending, History).

My tasks

Les tâches qui vous sont assignées, tous projets confondus.

La liste des cartes qui vous sont assignées, agrégée sur tous les dépôts auxquels vous avez accès.

Board

Le kanban : colonnes To Do / In Progress / Review / Done, cartes avec priorité, labels, assignés, couvertures.

Tableau kanban par dépôt, colonnes configurables (par défaut To Do, In Progress, Review, Done). Chaque carte porte une priorité (low / normal / high / urgent), des labels, des assignés, une échéance, des commentaires, des liens vers des assets ou des commits, et une image de couverture.

Les demandes sont des cartes du board Les anciennes modification requests (par exemple « Request release » sur un lock détenu par quelqu'un d'autre, dans l'onglet Pending) sont désormais des cartes du board portant un badge request. Il n'y a plus d'onglet Requests séparé.

Une carte ouverte : description, assignés, échéance, commentaires, liens asset/commit, couverture.

📷 Screenshot · production-request-cards

Des cartes de type request (badge) dans la colonne Review.

Activity

Tableau de bord unifié :

KPIs 24h : commits, déposants actifs, locks actifs
Calendrier d'activité : commits par jour sur plusieurs mois (heatmap)
Recent Checkins et Most Modified Directories
Commit History : commits paginés avec filtres par utilisateur et par chemin

Watchlist

Surveillez des chemins (motifs glob) pour être notifié des check-ins qui les touchent. Chaque entrée précise le chemin surveillé et les événements suivis.

Games

La zone Games liste les builds de playtest internes publiés pour le projet. Chaque build indique sa version, sa configuration (DebugGame / Development / Shipping), sa plateforme (Win64 / Mac / Linux), sa taille et ses notes de version, avec un bouton de téléchargement adapté à la plateforme.

C'est le point d'accès des playtesters : un compte avec le rôle playtester ne voit que cette page (ni Workspace ni Production), et n'accède qu'aux builds des projets qui lui sont ouverts.

Changelists locales

📷 Screenshot · client-changelists

Des fichiers checked-out répartis dans deux changelists locales (par exemple « default » et « review »).

Groupez vos checked-out files en plusieurs commits indépendants. Les changelists sont locales à votre workspace (jamais envoyées au serveur). Utile pour :

Séparer un fix critique d'un travail en cours
Préparer plusieurs envois en parallèle sans tout mélanger
Tenir un "default" changelist pour les WIP et un "review" pour ce qui part en checkin

Settings

Préférences globales du client (sauvegardées dans %APPDATA%/uversion/uVersion/config/config.toml) :

Option	Description
Default server URL	Pré-rempli sur la page de login
Username	Pré-rempli sur la page de login
Theme	System / Light / Dark
Show hidden files	Afficher les fichiers commençant par `.` dans le tab Files
Auto-sync interval	Désactivé / 5 min / 15 min / 30 min : déclenche un sync incrémental automatique
Parallel uploads	Plafond de concurrency (1-32, défaut 16)
Default repos path	Dossier proposé par défaut lors d'un clone

Panneau Unreal

📷 Screenshot · client-unreal-panel

Le panneau Unreal avec ses boutons d'action : Open Editor, Compile, Package Game et son choix de config, Publish Build, Stop.

Quand le client détecte un projet Unreal dans le workspace (présence d'un fichier .uproject), un panneau dédié apparaît. Il pilote le moteur directement depuis le client : ouvrir l'éditeur, compiler, empaqueter, sans passer par un IDE. La plupart des actions ne concernent que les projets C++ (un projet Blueprint pur n'a pas besoin de compiler).

Engine path

La version d'Unreal est détectée automatiquement depuis le EngineAssociation du .uproject (registre Windows, LauncherInstalled.dat, ou build source). Vous pouvez la surcharger manuellement si la détection échoue. Ce chemin est requis pour toutes les actions ci-dessous.

Open Editor

Lance l'éditeur Unreal (UnrealEditor) sur le projet du workspace. Le bouton est idempotent : l'éditeur peut mettre plusieurs dizaines de secondes à afficher sa fenêtre (surtout sur macOS / Linux), donc un second clic pendant ce temps n'ouvre pas une deuxième instance. Le bouton affiche « Opening… » tant que l'éditeur se lance. Pour un projet C++ jamais compilé localement, ouvrir l'éditeur déclenche d'abord une génération des fichiers de projet puis une compilation (voir Actions automatiques).

Compile

📷 Screenshot · client-compile-console

La console intégrée affichant la sortie de compilation Unreal Build Tool en temps réel.

Compile le projet (Unreal Build Tool). La sortie s'affiche en temps réel dans une console intégrée. Un projet C++ doit être compilé pour que l'éditeur puisse l'ouvrir et pour refléter les changements de code.

Generate Project Files

Régénère les fichiers de projet de l'IDE (Visual Studio, Rider). Utile après avoir ajouté ou supprimé des fichiers source, ou après un clone. Se trouve dans le menu « … » (plus d'actions) du panneau.

Package Game

Empaquette le jeu via RunUAT BuildCookRun et archive le résultat dans Packages/{config}/ à la racine du workspace. Trois configurations au choix :

Config	Usage
`DebugGame`	Build de débogage (symboles complets, non optimisé).
`Development`	Build de développement (par défaut) : optimisé mais avec les outils de dev.
`Shipping`	Build de distribution : optimisé, sans les outils de dev.

Le dossier Packages/ est ignoré par défaut (.uversionignore) : les packagés ne sont pas versionnés, ils se distribuent via Publish Build.

Publish Build

Publie un build empaqueté comme version de playtest interne. Il devient téléchargeable par votre équipe depuis la page Games du client (rôle playtester ou accès au build accordé). Le client scanne Packages/{config}/, envoie les fichiers (dédupliqués côté serveur) puis enregistre le manifeste.

Open project folder

Ouvre le dossier du workspace dans l'explorateur de fichiers du système (Explorateur Windows, Finder, ou xdg-open sous Linux).

Stop

Interrompt proprement tous les builds en cours : compilation et packaging. Le bouton indique combien de builds ont été arrêtés (une compilation auto lancée en arrière-plan peut être comptée avec).

Actions automatiques

En plus des boutons, le client déclenche certaines actions Unreal tout seul, pour qu'un projet C++ reste toujours à jour et compilable :

Avant un check-in : si des fichiers de code ont changé, le projet est compilé d'abord. Si la compilation échoue, le check-in est bloqué (on ne soumet pas du code qui ne compile pas).
Après un sync : si le sync a téléchargé du code, le client régénère les fichiers de projet puis recompile.
Au premier lancement après un clone (projet C++) : génération des fichiers de projet puis compilation, avant de pouvoir ouvrir l'éditeur.

Ces builds automatiques se sérialisent sur le verrou du moteur (Unreal Build Tool -WaitMutex) : ils ne se refusent pas entre eux, ils s'enchaînent. Le bouton Stop les interrompt aussi.