Client desktop

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

Windows en parc : le MSI

Pour déployer sur de nombreux postes avec un outil de gestion de parc (Intune, SCCM, stratégie de groupe...), utilisez le MSI plutôt que l'installeur NSIS : uVersion_latest_x64_en-US.msi (URL stable, toujours la dernière version, ~10 Mo). Installation silencieuse, par machine :

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

• Installe dans C:\Program Files\uVersion (droits administrateur requis). Le CLI uversion.exe est inclus, mais le dossier n'est pas ajouté au PATH : si vos utilisateurs en ont besoin en terminal, faites-le ajouter par l'outil de déploiement.
• Pas d'auto-update sur une installation MSI : le client reste à la version déployée et les mises à jour du parc se font en redéployant le MSI suivant. C'est voulu : la mise à jour intégrée installerait une seconde copie, par utilisateur, à côté de celle du parc.
• Désinstallation silencieuse : msiexec /x uVersion_latest_x64_en-US.msi /qn

À la première ouverture, chaque utilisateur saisit l'adresse du serveur et valide l'empreinte du certificat, une fois par utilisateur et par poste (voir Empreinte TLS).

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

Un seul format pour x86_64 : l'AppImage (uVersion_x.y.z_amd64.AppImage, ~85 Mo). Portable, elle embarque ses dépendances (libwebkit2gtk, libgtk, libsoup, etc.) et fonctionne sur toute distribution récente sans installation système. Prérequis : Ubuntu 24.04 ou supérieur, Debian 13 ou supérieur, ou une distribution d'une génération équivalente. Le binaire réclame une bibliothèque C système récente, et l'AppImage n'abaisse pas ce plancher : elle embarque l'environnement graphique, pas la bibliothèque C.

La voie recommandée est le script d'installation. Sans sudo :

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

Il ne fait rien de magique, et surtout rien qui demande des droits :

• il refuse de tourner en root, sur une architecture qui n'est pas x86_64, ou sur un système trop ancien pour exécuter le binaire, en disant lequel des trois pose problème ;
• il télécharge l'AppImage dans ~/Applications/uVersion.AppImage, vérifie que ce qui est arrivé est bien un exécutable Linux (un portail captif ou une page d'erreur seraient sinon enregistrés puis rendus exécutables, pour échouer plus tard de façon incompréhensible), puis la met en place d'un seul geste, ce qui reste sûr même si une copie tourne déjà ;
• il lance l'application. C'est ce démarrage qui crée l'entrée dans le menu des applications, donc mieux vaut le laisser faire. En session distante sans interface graphique, il affiche à la place la commande exacte à taper depuis votre bureau.

Vous pouvez aussi télécharger l'AppImage à la main depuis la page de téléchargement, la rendre exécutable et la lancer :

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

Il n'y a pas de paquet .deb pour le client, et il n'y en aura pas : un paquet installé par dpkg ne peut se mettre à jour qu'en repassant par dpkg, donc par une élévation de privilèges à chaque version, ce qui est impossible pour un poste sans droits administrateur. L'AppImage se remplace elle-même, sans mot de passe. Le serveur, lui, garde bien son paquet .deb.

Note : le CLI uversion est embarqué dans l'AppImage. Au premier lancement, le client copie le binaire dans ~/.local/bin/uversion et ajoute ~/.local/bin à votre PATH via ~/.profile (aucune action manuelle requise). L'entrée dans le menu des applications est créée au premier lancement, pour la même raison : une AppImage est un fichier, pas une installation.

Premier lancement

1. Renseigner l'adresse du serveur et vos identifiants

Au premier lancement, le client affiche la page de login, intitulée Welcome to uVersion. Le champ Server address n'attend pas une URL complète : il est découpé en trois blocs, un préfixe https:// non modifiable, la machine, et le port (8443 par défaut). Le schéma est imposé, le client ne peut pas produire de http://. Coller une adresse complète ou un machine:port dans la case machine la répartit automatiquement entre les deux champs. Renseignez ensuite Username et Password, puis Sign in.

2. Vérifier l'empreinte du serveur, une seule fois

Un serveur uVersion étant auto-signé par défaut, la toute première connexion à une machine donnée affiche Verify server identity : comparez l'empreinte SHA-256 avec celle que votre administrateur vous a donnée, puis cliquez sur Trust this server. La question n'est posée qu'une fois par serveur, et si elle revient sous le titre rouge Server identity changed, l'empreinte a changé : n'acceptez pas sans vérifier. Voir Empreinte TLS.

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.

Ouvrir ou cloner un dépôt

Se connecter n'ouvre aucun projet : la liste des dépôts se demande explicitement. C'est la même fenêtre qui sert à cloner un projet pour la première fois et à rouvrir un workspace déjà présent sur le disque.

1. Ouvrir la fenêtre Open Repository

Tant qu'aucun onglet n'est ouvert, le Workspace affiche No repository selected et un bouton Open Repository. Une fois que vous avez au moins un onglet, le même écran s'obtient par le + de la barre d'onglets. La fenêtre liste, une carte par projet, les dépôts auxquels vous avez accès, avec un bouton Refresh pour redemander la liste au serveur.

2. Cloner, ou rouvrir un workspace existant

Chaque carte propose l'action qui correspond à son état :

• Clone : crée un workspace neuf. Le champ Workspace name de la carte nomme le dossier créé, et reprend le nom du projet s'il est laissé vide. Le sélecteur de dossier qui suit demande le dossier parent : uVersion crée le sous-dossier lui-même.
• Clone New : le même bouton, renommé quand un workspace existe déjà pour ce projet. Cloner une deuxième fois est légitime, par exemple pour tenir deux états du projet côte à côte.
• Open : rouvre un workspace déjà cloné sur cette machine, dont le chemin est rappelé sous la carte. Switch to Open Tab apparaît à la place quand l'onglet est déjà ouvert.
• Open Local Repository..., en bas de la fenêtre : pointe un dossier contenant déjà un .uversion/, par exemple après avoir déplacé un workspace.

La case Download files after clone, en bas, est cochée par défaut et lance le téléchargement dans la foulée du clone. Décochez-la pour créer le workspace maintenant et rapatrier les fichiers plus tard.

3. Suivre le téléchargement

La fenêtre se ferme dès que le clone démarre, et c'est voulu : le transfert peut durer des heures et ne doit pas vous bloquer. La progression continue dans l'en-tête du client, l'onglet du workspace s'ouvre tout seul à la fin, et une coupure réseau ne perd rien puisque le transfert reprend de lui-même.

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 : le seul fichier vraiment important. Sa section [workspace] porte le propriétaire du workspace (owner), son identifiant, son nom, et last_synced_revision, la révision à laquelle vous êtes synchronisé (il n'y a pas de fichier .last_sync). C'est aussi là qu'est mémorisé le chemin du moteur Unreal.
• .uversion/checkouts_<workspace_id>.json : les verrous que VOUS détenez dans ce workspace
• .uversion/changelists_<workspace_id>.json : vos changelists, c'est-à-dire des paquets de fichiers réservés que vous regroupez pour les envoyer séparément. Purement local, jamais transmis au serveur.
• .uversion/pending_deletes_<workspace_id>.json : les suppressions en attente d'envoi
• .uversion/snapshots.json : l'état connu des fichiers, qui sert à repérer ce que vous avez modifié localement

Tab Files

Vue arborescente des fichiers du workspace avec leur état. Deux moyens de réduire la liste :

• Le champ de recherche, intitulé Search files... : filtre sur une portion du chemin, sans tenir compte de la casse.
• Les puces de statut, juste en dessous. Ce sont des compteurs cliquables, et une puce n'apparaît que si son compteur dépasse zéro : sur un workspace fraîchement synchronisé, vous ne verrez donc que {n} synced, et l'absence des autres est normale. Les six puces possibles sont {n} synced, {n} modified, {n} local only, {n} server only, {n} locked et {n} deleted.

Recherche et puces se combinent : la recherche restreint d'abord, les puces filtrent ensuite. La vue reste fluide même sur des projets de plusieurs dizaines de milliers de fichiers.

Sélection multiple + actions

La barre d'actions n'existe que si quelque chose est sélectionné. Tant que la sélection est vide, il n'y a aucun bouton : c'est normal, ce n'est pas un chargement en cours. Sélectionnez des fichiers (clic + shift, ou les cases à cocher) et la barre apparaît, préfixée du nombre retenu ({n} file(s) selected). Les boutons s'affichent selon ce que la sélection permet :

Tab Pending

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

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. Le Workspace, lui, se concentre sur les fichiers (Files, Pending, History).

My tasks

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

Board

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.

Dashboard

Le cockpit du producer : un bandeau de santé du projet (bloquants ouverts, rapports de playtest en attente), les zones qui concentrent les soucis, les commits de la semaine, le poids du projet et la dernière build publiée, chaque bloc renvoyant vers le board ou vers Games.

En dessous, la timeline calendrier : jalons, playtests (ponctuels ou récurrents), releases et échéances de cartes. Un playtest récurrent génère automatiquement sa carte de board à chaque occurrence.

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

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) :

Panneau Unreal

Quand le client détecte un projet Unreal dans le workspace, une barre d'actions dédiée apparaît en haut à droite du Workspace. Elle 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).

La pastille d'état du plugin

Tout à gauche de la barre, une pastille indique où en est le plugin Unreal pour ce projet. Elle est cliquable :

Chemin du moteur

Le chemin d'installation d'Unreal est résolu automatiquement à partir de l'EngineAssociation du .uproject (registre Windows, LauncherInstalled.dat, ou build source). Ce chemin est requis pour toutes les actions ci-dessous, et la résolution automatique échoue notamment sur un moteur compilé depuis les sources. Voici où le régler à la main.

1. Ouvrir le menu des actions secondaires

Il n'y a ni champ de saisie, ni bouton Browse, ni bouton Auto-detect visible dans la barre. Le seul point d'entrée est le bouton en forme d'engrenage, tout à droite de la barre Unreal, accompagné d'un petit chevron et dont l'infobulle dit More actions. Rien dans son apparence ne parle du moteur, et c'est pour ça qu'on ne le trouve pas.

2. Choisir Set Engine Path...

L'entrée Set Engine Path... est la dernière du menu. Son sous-titre affiche le chemin courant, ou Not configured s'il n'y en a pas : c'est le moyen le plus rapide de savoir si le problème vient de là. Un sélecteur de dossier s'ouvre, et le chemin retenu est enregistré dans le .uversion/config.toml du workspace.

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

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.

Sync et Status

Ces deux boutons vivent dans la même barre, et non dans l'onglet Files :

• Sync : met à jour tout le workspace depuis le serveur. Son infobulle indique le nombre de fichiers en attente quand il y en a. C'est le vrai « sync » du client, à ne pas confondre avec le bouton Download de l'onglet Files, qui ne ramène que la sélection.
• Status : rafraîchit l'état côté serveur, verrous des autres utilisateurs compris, et remet à jour le compteur du bouton Sync.

Le menu More actions

Les actions plus rares sont regroupées derrière le bouton en forme d'engrenage, à droite de la barre (capture ci-dessus) :

• 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.
• Publish Editor Binaries : compile, puis publie les binaires d'éditeur correspondant au dernier commit de code. Vos coéquipiers les récupèrent au sync au lieu de recompiler chacun de leur côté. Absent sous Linux.
• Force Sync : re-télécharge en écrasant vos fichiers locaux. Signalé en rouge dans le menu, avec la mention overwrites local, et précédé d'une confirmation. À réserver aux workspaces qu'on accepte de perdre.
• Set Engine Path... : le réglage du chemin du moteur, décrit plus haut.

Package

Le bouton s'appelle Package ; « Package Game » n'est que son infobulle, remplacée par Set Engine Path first quand le chemin du moteur manque, le bouton étant alors désactivé. Il empaquette le jeu via RunUAT BuildCookRun et archive le résultat dans Packages/{config}/ à la racine du workspace. Trois configurations au choix :

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.