Différences

Ci-dessous, les différences entre deux révisions de la page.

--- bloc2:prog:gen:versioning [2023/11/28 14:15] – ↷ Liens modifiés en raison d'un déplacement. admin
+++ bloc2:prog:gen:versioning [2024/11/05 14:48] (Version actuelle) – [Organisation] admin
@@ Ligne 13: / Ligne 13: @@
   * 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?400  |Diagramme de séquence}}
+{{  bloc2:prog:gen:versioning1.png?800  |Diagramme de séquence}}
 ===== Les révisions =====
 <WRAP group>
 <WRAP half column>
 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, plus grand d’une unité que le dernier numéro attribué à une livraison par le système. La révision initiale d'un référentiel est numérotée zéro et ne consiste en rien d'autre qu'un répertoire racine vide.
+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).
-Le référentiel peut être considéré comme une série d'arbres. À chaque numéro de révision est associé un arbre du système de fichiers.
 </WRAP>
@@ Ligne 34: / Ligne 33: @@
 <WRAP half column>
 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).
+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.
@@ Ligne 40: / Ligne 39: @@
 </WRAP>
-===== Organisation =====
-Sur un serveur SVN, le projet, les Branches et les Tags sont stockés dans des dossiers spécifiques nommés res-pectivement « trunk », « branches », et « tags ». Ce n’est qu’une convention de nommage que vous êtes libres de respecter ou d’adapter, mais les bonnes pratiques vous conduiront naturellement à adopter ce nommage.
-L’intérêt des étiquettes sous Subversion est d’utiliser des noms symboliques plutôt que des numéros de révi-sions pour se référer à un état précis, comme par exemple ’release-1.1’, plutôt que ’488’.
-Un nom symbolique permet de revenir facilement à une version identifiée.
-Pour créer un tag, il suffit de copier l'état actuel d'une version de développement dans un sous-répertoire du dépôt.
-Les règles suivantes sont communément admises :
-  * Liste à puceLes différents tags correspondent chacun à un sous-répertoire, lui-même contenu dans un sous-répertoire nommé tags du projet ;
-  * On ne « commit » pas dans un tag ;
-En fonction de l’ampleur et du nombre de projets contenus dans votre dépôt, l’emplacement de ces trois dos-siers peut varier. Il existe en fait deux formes recommandées en fonction de vos besoins :\\
-{{  bloc2:prog:gen:versioning4.png?400  |}}\\
-Quelle que soit l’architecture choisie pour les dossiers de base, l’utilisateur crée tous les dossiers intermédiaires librement. Par exemple, la branche « germanVersion » pourra être stockée dans le dossier branches/germanVersion. \\
-À consulter : [[http://www.lacl.fr/gava/cours/M2/IngLog/annexe3.pdf]]