Wiki SIO Chaptal

Outils pour utilisateurs

Outils du site

Piste : • jlist • jtable
bloc2:prog:gen:versioning

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
bloc2:prog:gen:versioning [2024/11/05 14:44] – [Les révisions] adminbloc2:prog:gen:versioning [2024/11/05 14:48] (Version actuelle) – [Organisation] admin
Ligne 18: Ligne 18:
 <WRAP half column> <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. 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). \\  +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 un arbre multidimensionnel : les branches forment une arborescence, chaque révision forme une arborescence de fichiers.+
 </WRAP> </WRAP>
  
Ligne 34: Ligne 33:
 <WRAP half column> <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). 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. 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> </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]] 
  
bloc2/prog/gen/versioning.1730814262.txt.gz · Dernière modification : 2024/11/05 14:44 de admin