Pour partager les modifications de code et de graphismes, nous utilisons un système de gestion des dépôts.

Les données du serveur de jeu Ryzom Core sont hébergées sur Bitbucket (mercurial) mais nous avons mis en place notre propre serveur Gitlab pour la gestion des données de Khaganat.

Elles sont régulièrement mises à jour par les participants au projet. C'est à partir de là que l'on peut récupérer tous les fichiers nécessaires à l'installation d'un serveur, à la création d'un jeu ou au déploiement d'un client. Pour l'heure, il n'existe pas de dépôt de tous les binaires que l'on peut compiler à partir de ces sources.

Nous allons donc voir dans un premier temps comment récupérer les fichiers, les synchroniser, voire proposer des modifications.

Avant de voir comment réaliser les différentes opérations, il semble important de préciser quelques notions de vocabulaire. Les termes anglais ont été conservés car il est très fréquent que cela soient ceux que vous rencontrerez sur XMPP ou dans des tutoriels.

L'endroit où les fichiers sont conservés sur Internet (la zone de Bitbucket qui accueille les fichiers Ryzom Core par exemple) s'appelle un repository (dépôt en français). En créant un compte sur Bitbucket (ou Github, ou Gitlab), vous allez créer votre propre repository, qui contiendra votre version des données, celle avec laquelle vous allez synchroniser votre répertoire local (sur votre ordinateur).

Le dépôt contient en outre un historique des modifications faites (dans le répertoire .hg pour mercurial, .git pour git). On présente chaque nouveau dépôt comme un fork (ang. bifurcation) de son dépôt initial, car il peut donner lieu à un projet distinct, selon les choix d'échange et de synchronisation qu'il choisit.

La première chose à faire pour travailler avec un repository de référence est de récupérer les données par un clone (ang. clone ) dans son propre repository. Si on l'a déjà fait voilà un moment et que l'on n'est pas certain d'avoir les dernières versions, il faut alors le vérifier et, le cas échéant, les récupérer, ce qui modifiera les données dans notre propre dépôt, on appelle cette opération un pull (ang. tirer). Une fois cela fait, on peut synchroniser les données que l'on a en local avec son dépôt : un update (ang. mise à jour).

Si des fichiers ont été modifiés des deux côtés, le système refusera de faire cela et proposera plutôt un Merge (ang. fusion, “comparer”). A priori cela se fera également automatiquement, tant que ce sont des lignes différentes qui auront été modifiées au sein d'un même fichier. Dans le cas contraire, il vous sera proposé manuellement de faire un choix ou de choisir comment synthétiser les deux modifications en une.

Lorsque l'on a réalisé un certain nombre de modifications sur ses fichiers locaux, il faut les enregistrer sur son repository. Pour cela, on fait un commit (ang. envoi, livraison), qui va copier en vérifiant si un merge ne serait pas préférable, s'il constate que des changements ont été fait également dans le repository (par le biais d'un pull récent par exemple). On indique généralement à cette occasion quels fichiers et lignes ont été modifiés, ou de très synthétiques commentaires.

Une fois ses données dans son repository, on peut faire un push (ang. pousser, “demande d'ajout”) pour que ses modifications soient acceptées par le repository du projet initial. Dans la cas probable où des fichiers y auront été modifiés depuis votre dernier pull, il faudra sûrement faire un pull/merge pour que cela soit possible (et donc un update de vos fichiers locaux également).

Lorsqu'on réalise un travail particulier demandant plusieurs commits, pour ajouter une feature par exemple, on travaille sur une branche, parallèlement à la branche principale appelée master. Cette branche est ensuite fusionné sur master.

Lorsque vous clonez un dépôt, vous ne voyez que ce qui est sur la branche que vous suivez (par défaut, master). Il faut passer une commande pour aller d'une branche à l'autre et voir les modifications.