Comprendre un Gestionnaire de Sources :

Pour partager du code source, sauvegarder et garantir la traçabilité des corrections opérées par de nombreux Contributeur(s) SPIP, un peu d’organisation s’impose pour un contrôle de versions et le suivi des modifications...

Le vocabulaire utilisé (souvent exclusivement en anglais, car outil de professionnels) peut heurter le sens commun, car il prend souvent son sens du point de vue du serveur, alors que le contributeur-lecteur des sources se positionne sur un client : voir Comment fonctionne un Site Internet.
En général, et en particulier pour SPIP, la lecture est librement autorisée ; par contre il vous sera le plus souvent demandé une authentification pour commiter, c’est-à-dire écrire des modifications sur le serveur.

Mais les notions principales que nous allons revoir restent les memes pour tous ces outils, et vous pourrez ensuite vous reporter aux articles détaillés ci-après.

Article publié le 9 mars, et actualisé en mars 2020

Attention, cette page est encore en      

 L’inscription pour authentification

Un simple mail suffit pour valider une inscription qui se traduit par un mot de passe ((par diffusion automatique ou par choix utilisateur) ; en général vous pourrez récupérer un mot de passe oublié par mail (comme avec SPIP), voire le modifier...
Ce code utilisateur reçoit alors des droits d’usage, en lecture (souvent anonyme) ou en écriture sur tout ou partie(s) des dépots concernés, pour avoir accès aux fichers.

La démarche consiste pour l’utilisateur à importerextraire une version de fichiers sur un dossier en local, puis à renvoyer (commiter) une version modifiée au serveur pour fusion, avec commentaires explicatifs : mais vu du serveur, les sens des mots s’inversent...
En plus le système de gestion doit traiter les conflits de révisions concourantes -souvent sous forme d’un arbre historisant chacune des révisions- enregistrant les modifications concomitantes de plusieurs utilisateurs sur les mêmes fichiers en quasi-simultanné.

 La notion de dépot-repository

Pour partager des fichiers source (c’est-à-dire d’abord récupérer une version des fichiers sur un poste de travail local), un peu de collaboratif est nécessaire, géré informatiquement autour d’une base centrale en charge du contrôle-suvi des versions.
Chaque dossier-projet en développement est en général structuré autour d’un tronc commun de développement actif, avec des branches autonomes pour certaines orientations de développement ; enfin la notion de tag permet d’étiqueter un état des divers sources du projet, pour garder cette situation rapidement accessible parmi l’arbre des révisions successifs.
Les derniers systèmes privilégient désormais un mode de contrôle décentralisé, donnant plus d’autonomie à chaque dépôt-utilisateur (à se créer en local) en cas de panne ou d’indisponibilité du serveur d’origine distant : c’est une raison du passage du serveur SVN au serveur Git...
Au cours du workflow de révision des fichiers sources selon les interventions des ’commiters’ on passe par quatre étapes :
- checkout : récupération/clonage d’un depot source à l’état actualisé des dernières révisions,
- modification(s) individuelle(s) autonome en local
- stabilisation du source par le modifieur en état stage
- commit de synchronisation de la version individuelle en stage,
avant validation synchronisée en global entre les dépots utilisateurs

 Une organisation des dossiers

Les sources sont gérés sur le serveur comme sur votre disque dur, donc par dossiers de répertoires et arborescence de sous-répertoires : la première étape est de prendre connaissance de celle-ci, pour savoir chercher et/ou déposer du code.

Une fois trouvé le dossier de base contenant le projet qui vous intéresse, reste à gérer le partage des sources, et des commits de révisions successives.

 Le fonctionnement en branches d’un sous-projet

Lors de la vie d’un projet, les developpements ne sont pas toujours linéaires, soient par divergence ou fork du projet initial, et plus souvent par avancement à des niveaux différents de plusieurs branches du projet, pour des raisons de différentiation technique (compatibilité avec une ancinenne release) et/ou fonctionnelle, par exemple pour étudier la faisabilité de plusieurs solutions nouvelles.
Il peut s’avérer nécessaire de fusionner (merge) les développements portés sur deux branches, et dans certains cas de gérer les conflits dus à des commits indépendants portant sur des memes lignes des fichiers concernés...

 D’autres services rendus

Le gestionnaire de sources permet de suivre, et donc de retracer la succession des versions des sources par consultation de l’historique, et -les révisions étant normalement toujours accompagnées d’un message de commit- d’identifier leurs motivations.
En particulier, des commandes facilitent la mise en évidence des différences entre versions.
Enfin, le gestionnaire permet la délivrance facile d’archive compacte des sources à un état final ou étiqueté à un stade précis.


Merci de nous signaler les coquilles, imprécisions ou erreurs qui figureraient dans cette page.


Liens A2A visibles seulement pour les inscrits.
Liens visibles seulement pour les inscrits.

Article publié le 9 mars, et actualisé en mars 2020 Provisoire (à compléter...) .

Répondre à cet article