Wiki

Distribution

Copier des fichiers (plugins, contenu partagé) d'un dépôt source vers un dépôt cible par patterns de chemin. Publication, remapping, verrous ignorés.

Introduction

La distribution copie des fichiers (un plugin, un pack de contenu partagé) d'un dépôt source vers un dépôt cible, en se limitant à des patterns de chemin. Elle crée de nouvelles révisions dans la cible, si bien que la synchronisation incrémentale habituelle propage le contenu aux clients. C'est le moyen de partager un même plugin entre plusieurs projets sans copier-coller manuel.

Accès et rôles

Modèle d'accès différent des autres onglets La distribution n'est pas gardée comme les autres onglets. Elle exige la capacité manage_rules, qui est détenue par admin et lead, à l'échelle du serveur entier. Un project_admin, qui ne détient aucune capacité, n'y a pas accès. Un lead, lui, peut relier n'importe quel dépôt à n'importe quel autre.

Créer un lien

Le formulaire New Link : Source Repository, Target Repository, et la zone Path Patterns.

Onglet Distribution → New Link.
Source Repository : le dépôt d'où viennent les fichiers.
Target Repository : le dépôt de destination (la source choisie est retirée de la liste ; source et cible ne peuvent pas être identiques).
Path Patterns : un pattern par ligne (ex. Plugins/MyPlugin/, Content/SharedAssets/). Au moins un est requis.
Validez avec Create Link.

Un lien déjà existant entre les deux mêmes dépôts est refusé (conflit). Chaque ligne affiche source → cible, ses patterns, qui l'a créé et la date de dernière publication.

Patterns de chemin

Un pattern matche un chemin s'il apparaît quelque part dedans (recherche de type « contient »). Un pattern Plugins/uVersion matche donc DefaultProject/Plugins/uVersion/Source/Foo.cpp quel que soit le préfixe de projet. Le slash final ne change rien.

Publier

La liste des fichiers en attente (new/modified/locked) et le bandeau de résumé de publication.

Trois actions sur chaque lien :

Show pending files (icône fichier) : liste les fichiers qui diffèrent, marqués new, modified ou locked, avec leur révision.
Publish history (horloge) : les 50 dernières publications (combien mis à jour / ignorés, qui, quand).
Publish (envoi) : exécute la copie. Un bandeau récapitule « X fichiers source trouvés, Y mis à jour, Z ignorés (verrouillés), W inchangés ». Désactivé si le lien est inactif.

Un fichier verrouillé dans la cible est ignoré, pas écrasé. Un fichier au contenu identique (même hash) est compté comme inchangé et ignoré. La publication est atomique (une seule transaction).

Vous pouvez aussi activer / désactiver ou supprimer un lien.

Remapping et révisions

Le chemin est réécrit pour la cible : uVersion retire ce qui précède le pattern qui a matché, puis ajoute le préfixe détecté sur la cible. Exemple : source DefaultProject/Plugins/uVersion/foo.cpp, pattern Plugins/uVersion, préfixe cible CineDroneStudio/ → CineDroneStudio/Plugins/uVersion/foo.cpp. Le préfixe cible est déduit d'un fichier existant de la cible (gestion des dépôts avec ou sans sous-dossier de projet).

Numérotation de révision Les révisions distribuées utilisent un compteur global au-dessus de la révision courante de la cible, pour que la sync incrémentale les récupère. L'historique par fichier peut donc « sauter » (ex. rev 1 puis rev 200) : c'est cosmétique. Les chunks sont partagés (pas de duplication de données, simple incrément de référence).

Pièges courants

« Publish » est grisé

Le lien est inactif. Activez-le d'abord. Publier un lien inactif renvoie une erreur explicite.

Un fichier n'est pas mis à jour dans la cible

Soit il est verrouillé côté cible (il est alors ignoré et compté comme « locked »), soit son contenu est déjà identique (compté comme « unchanged »). Regardez le récapitulatif de publication et la liste des pending files.

Un project_admin ne voit pas l'onglet

C'est voulu : la distribution exige manage_rules (admin ou lead). Un project_admin n'y a pas accès, même sur ses propres dépôts.