====== Versioning ======
===== Définition =====
''Sources : [[http://www.openclassroom.com|Site du zéro]] et manuel utilisateur de TortoiseSvn chez [[http://www.tortoisesvn.net|TortoiseSVN]]'' \\ \\
Le contrôle des versions d’un logiciel répond à deux problématiques :
* D’abord, le développement d’une application informatique implique la création et la modification de nombreux fichiers. Au fil du temps, ces fichiers sont modifiés (enrichis, supprimés, ...). Or, il arrive souvent que l’on veuille revenir à l’état précédent d’un fichier, afin par exemple de voir quelle modification a entraîné l’apparition d’un bug, ou de remettre en service du code que l’on avait supprimé. Un système de gestion de versions garde l’intégralité des états successifs de chaque fichier, permettant à tout instant de revenir en arrière. En bonne pratique, tout changement d'état est accompagné d'un commentaire.
* Ensuite, le développement d’une application informatique implique généralement plusieurs personnes simultanément. Dès lors que ces personnes sont amenées à intervenir sur les mêmes parties du projet, il convient de gérer correctement les modifications concurrentes des fichiers. Un système de gestion de versions joue ce rôle de médiation.
===== Répartition des rôles entre client et serveur =====
Le principe est le suivant :
* Le serveur conserve en mémoire toutes les versions de tous les fichiers, ainsi que les changements de l'arborescence des répertoires, comme l'ajout, la suppression et le réarrangement des fichiers et des dossiers. La zone où sont archivées, sur le serveur, les modifications successives s’appellent le référentiel (repository, en anglais) ou dépôt. Il n'est pas possible de travailler directement sur les fichiers du dépôt. C'est la raison pour laquelle il faut obligatoirement un client dans le système.
* Le client, lui, va télécharger du serveur les fichiers à jour afin de pouvoir travailler dessus localement. Une fois qu'il aura fini d'apporter ses modifications, il va télé-verser la nouvelle version des fichiers sur le dépôt de sorte qu’ils puissent être, à leur tour, modifiés par d’autres intervenants.
{{ bloc2:prog:gen:versioning1.png?800 |Diagramme de séquence}}
===== Les révisions =====
Dans une copie locale de travail, il est possible de changer le contenu des fichiers existants, ou encore créer, supprimer, renommer, copier des fichiers et des répertoires et ensuite livrer le jeu complet de changements comme une unité. Sur le serveur, chaque livraison est traitée comme une transaction atomique : tous les changements de la livraison ont lieu, ou aucun n'a lieu.
L'acceptation d'une livraison par le référentiel crée un nouvel état de l'arborescence du système de fichiers, appelé une révision. À chaque révision est assigné un numéro (soit un numéro d'ordre, soit une signature sous la forme d'un hash).
{{ bloc2:prog:gen:versioning2.png?300 | Révisions}}
===== Brancher / Étiqueter =====
{{ bloc2:prog:gen:versioning3.png?300 |Brancher et étiqueter}}
La capacité d'isoler des changements sur une ligne de développement particulière est une des fonctionnalités des systèmes de contrôle de versions. Cette ligne de développement particulière est connue sous le nom de branche (branch).
Les branches sont souvent utilisées pour expérimenter de nouvelles fonctionnalités sans déranger la ligne de développement principale. Dès que la nouvelle fonctionnalité est suffisamment stable, alors la branche de développement peut être fusionnée avec la branche principale (le tronc ou master). \\
Une autre fonctionnalité des systèmes de contrôle de versions est la capacité de marquer des révisions particulières, par exemple une version à déployer (livrables). Il est alors possible de recréer à tout moment cette version d'application sans effort. Ce processus est connu comme l'étiquetage (tag). Cette fonctionnalité est largement utilisée afin de marquer à intervalles plus ou moins réguliers des versions d’une application dans la ligne de développement.