Formation à l`utilisation d`un client Subversion

Transcription

Formation "Utilisation d'un client Subversion"
Paris, 27 juin 2007
Formation à l'utilisation d'un client
Subversion
Vincent Carpier et Florent Guilleux,
Comité Réseau des Universités
Document de la formation dispensée le 27 juin 2007
Version électronique téléchargeable sur
http://www.cru.fr/_media/activites/formations_du_cru/formation_subversion_juin-2007.pdf
Présentation PowerPoint de la formation
http://www.cru.fr/_media/activites/formations_du_cru/formation_subversion_juin-2007.ppt
Copyright
Copyright © Comité Réseau des Universités
Ce document peut être copié et distribué dans son intégralité, sans modification, retrait ou ajout.
Tout usage commercial est interdit.
L’utilisation de ce document dans un cadre de formation collective est soumise à l’approbation
explicite et préalable de ses auteurs.
Page 1 / 32
Paris, 27 juin 2007
Sommaire
1 - Description de la formation.............................................................................................................4
1.1 - Informations générales............................................................................................................ 4
1.2 - Objectifs.................................................................................................................................. 4
1.3 - Pré requis................................................................................................................................. 4
1.4 - Références............................................................................................................................... 4
2 - Introduction..................................................................................................................................... 5
3 - Préparation du poste de travail........................................................................................................ 5
3.1 - Accès au poste de travail......................................................................................................... 5
3.2 - Installation du client Subversion............................................................................................. 5
3.3 - Création d'un projet fictif sur son poste de travail...................................................................5
3.4 - Utilisation d'un dépôt Subversion sur SourceSup................................................................... 5
3.5 - Voir le contenu de votre dépôt avec un navigateur web........................................................ 6
4 - Opérations de base.......................................................................................................................... 7
4.1 - Importer un projet existant dans un dépôt Subversion............................................................ 7
4.1.1 - Avec TortoiseSVN...........................................................................................................7
4.1.2 - Avec Subclipse................................................................................................................ 8
4.2 - Récupérer sur son poste de travail un projet contenu dans un dépôt Subversion....................9
4.2.1 - Avec TortoiseSVN.........................................................................................................10
4.2.2 - Avec Subclipse.............................................................................................................. 10
4.3 - Modifier le contenu de sa copie de travail et ensuite enregistrer ces modifications dans le
dépôt...............................................................................................................................................11
4.3.2 - Avec Subclipse.............................................................................................................. 11
4.4 - Ne pas enregistrer certains fichiers et répertoires de sa copie de travail dans le dépôt.........13
4.4.2 - Avec Subclipse.............................................................................................................. 14
4.5 - Suivre les modifications apportées sur sa copie de travail depuis le moment où l'on a réalisé
l'enregistrement précédent ou fait le checkout...............................................................................14
4.5.2 - Avec Subclipse.............................................................................................................. 15
4.6 - Annuler des modifications réalisées sur la copie de travail.................................................. 16
4.6.2 - Avec Subclipse.............................................................................................................. 16
4.7 - Consulter l'historique des modifications du dépôt................................................................ 16
4.7.2 - Avec Subclipse.............................................................................................................. 17
5 - Travailler à plusieurs sur un dépôt................................................................................................ 18
5.1 - Mettre à jour son dépôt..........................................................................................................18
5.2 - Gestion des conflits............................................................................................................... 19
5.2.1 - Optimistic locking dans le cas où des modifications concernent des lignes différentes
d'un fichier.................................................................................................................................19
5.2.2 - Optimistic locking dans le cas où des modifications concernent les mêmes lignes d'un
fichier........................................................................................................................................ 20
5.2.2.1 - La vue Synchronize with Repository d'Eclipse..................................................... 21
5.2.3 - Locking.......................................................................................................................... 22
Page 2 / 32
Paris, 27 juin 2007
5.2.4 - Cycle de travail typique avec Subversion......................................................................22
5.3 - Qui a changé quelle ligne ?................................................................................................... 23
5.3.2 - Avec Subclipse.............................................................................................................. 23
6 - Gérer le cycle de développement d'un logiciel............................................................................. 24
6.1 - Les étiquettes......................................................................................................................... 24
6.1.1 - Création du répertoire tags.............................................................................................24
6.1.1.1 - Avec TortoiseSVN.................................................................................................24
6.1.1.2 - Avec Subclipse.......................................................................................................24
6.1.2 - Créer une étiquette......................................................................................................... 25
6.1.2.2 - Avec Subclipse.......................................................................................................25
6.1.3 - Faire une version diffusable de son logiciel à partir d'une étiquette..............................26
6.2 - Les branches.......................................................................................................................... 27
6.3 - Créer et appliquer des patchs.................................................................................................28
6.3.1 - Créer un patch................................................................................................................29
6.3.1.2 - Avec Subclipse.......................................................................................................29
6.3.2 - Appliquer un patch........................................................................................................ 29
6.3.2.2 - Avec Subclipse.......................................................................................................30
7 - Pour aller plus loin........................................................................................................................ 31
7.1 - Les propriétés........................................................................................................................ 31
7.2 - Intégrer d'autres dépôts dans sa copie de travail................................................................... 31
7.3 - Les hook scripts.....................................................................................................................32
7.4 - Toujours plus loin..................................................................................................................32
8 - Conclusion.....................................................................................................................................32
Page 3 / 32
Paris, 27 juin 2007
1 Description de la formation
1.1 Informations générales
Public concerné : développeurs souhaitant apprendre ou améliorer leur utilisation de Subversion
pour gérer le versioning du développement de logiciels.
Durée : une journée
Nombre de stagiaire : . 20 Les stagiaires sont réparties par binôme sur chaque poste.
Intervenants :
●
Vincent Carpier, Comité Réseau des Universités, adminstrateur de la plate-forme
SourceSup, [email protected]
●
Florent Guilleux, Comité Réseau des Universités, adminstrateur de la plate-forme
SourceSup, [email protected]
1.2 Objectifs
Les objectifs sont :
●
comprendre les concepts de la gestion de version dans Subversion ;
●
apprendre les commandes de base et avancées pour gérer le cycle de développement d'un
logiciel avec Subversion ;
●
maîtriser l'utilisation d'un client Subversion (TortoiseSVN ou Subclipse).
1.3 Pré requis
Cette formation ne nécessite aucune connaissance particulière préalable.
Dans ce cas de le cas de l'utilisation du client Subversion Subclipse d'Eclipse, il faut connaître
Eclipse, car aucun aspect spécifique à Eclipse hors de l'utilisation de Subversion n'est abordé.
1.4 Références
●
Manuel de référence de Subversion en ligne : http://svnbook.red-bean.com/
●
Documentation en ligne de Subclipse :
http://svn.collab.net/subclipse/help/index.jsp?topic=/org.tigris.subversion.subclipse.doc/html
/toc.html
Page 4 / 32
●
Documentation en ligne de TortoiseSVN :
http://tortoisesvn.net/docs/release/TortoiseSVN_fr/index.html
●
Autres ressources : http://www.cru.fr/faq/sourcesup/gestion_src
Paris, 27 juin 2007
2 Introduction
En début de formation sont présentées oralement les intérêts de la gestion de version, Subversion,
ses concepts de base et sa terminologie. Cette présentation va faciliter le travail pratique de la suite
de la formation, sous forme d'une suite d'exercices qui permettront d'acquérir les pratiques d'un
développement avec Subversion. Au départ les exercices sont très détaillés, ensuite ils sont de
moins en moins directifs. Toutes les possibilités de Subversion et des clients TortoiseSVN et
Subclipse ne sont pas couvertes, mais cette formation vous permettra d'en savoir assez pour les
utiliser avec efficacité.
3 Préparation du poste de travail
3.1 Accès au poste de travail
Suivre les indications données au début de la formation.
3.2 Installation du client Subversion
Les clients TortoiseSVN et Subclipse (pour Eclipse) sont installés sur les postes de la salle de
formation. Vous pouvez utiliser celui qui vous convient.
3.3 Création d'un projet fictif sur son poste de travail
Pour les besoins de la formation, créez sur le bureau Windows un répertoire (avec le nom que vous
souhaitez, par exemple mon-projet) puis à l'intérieur créez un fichier texte (par exemple
document.txt). Ce répertoire et son contenu représentent votre projet tel que vous l'avez développé
sur votre poste jusqu'au jour où vous déciderez d'utiliser Subversion.
3.4 Utilisation d'un dépôt Subversion sur SourceSup
Subversion est un système de gestion de version centralisé, il stocke donc le contenu d'un projet au
niveau d'un serveur central, dans un dépôt (repository en Anglais). Avec un client Subversion, il
n'est pas possible de créer depuis son poste un dépôt au niveau d'un serveur Subversion. Il faut donc
que l'administrateur du serveur y crée initialement le dépôt d'un projet. Pour cette formation un
dépôt a été créé pour chaque poste de travail sur le serveur Subversion de SourceSup. Le nom de
chaque dépôt est projet-x, où x est le numéro du poste que vous utilisez dans la salle de formation
('01', '02', '03', etc.). L'URL d'accès au dépôt est http://subversion.cru.fr/projet-x.
Toutes les opérations que nous effectuerons sur le dépôt Subversion transiteront via HTTP. Il existe
d'autres protocoles d'accès à Subversion (HTTPS, SVN, SVN+SSH) mais toutes les commandes
Page 5 / 32
Paris, 27 juin 2007
restent les mêmes, nous ne détaillons donc pas ces autres protocoles d'accès. L'accès à Subversion
via HTTP[S] utilise HTTP et WebDAV.
3.5 Voir le contenu de votre dépôt avec un navigateur web
Vous pouvez voir le contenu d'un dépôt Subversion avec un navigateur. Ouvrez un navigateur et
allez sur l'URL http://subversion.cru.fr/projet-x. Utilisez l'identifiant test_user et le mot de passe
test_user. Vous verrez apparaître une vue de l'arborescence du contenu actuel du dépôt de votre
projet sur le serveur Subversion, avec le numéro de révision courant. Comme pour le moment il n'y
a rien dans votre dépôt, la page qui apparaît est vide. Le numéro de révision affiché est zéro car
aucune opération n'a encore été effectuée dans le dépôt.
Quand vous travaillez avec Subversion, il est parfois très utilise d'utiliser cette vue du dépôt avec un
navigateur web, pour vérifier quel est exactement l'état de son dépôt sur le serveur.
Page 6 / 32
Paris, 27 juin 2007
4 Opérations de base
Cette partie décrit les opérations de base de Subversion qu'utilise un développeur au quoditien. A
l'issue de cette partie, vous saurez récupérer ou importer un projet dans un dépôt Subversion, y
apporter des modifications, annuler certaines modifications, connaître l'historique des modifications
apportées...
L'ordre proposé suit dans la mesure du possible les besoins successifs d'un développeur au cours de
son utilisation de Subversion.
4.1 Importer un projet existant dans un dépôt Subversion
Vous avez un dépôt vide sur le serveur Subversion, et votre projet sur le bureau de votre poste de
travail.Voyons maintenant comment importer le contenu actuel du projet dans le dépôt Subversion.
Ce terme "importer" n'est pas très naturel si l'on se place du point de vue du développeur : on aurait
tendance à penser qu'importer signifie récupérer quelque chose depuis le serveur vers son poste de
travail. Mais dans le contexte Subversion il s'agit bien du contraire : envoyer depuis son poste de
travail son projet vers le dépôt Subversion. Cette convention où l'on se place du point de vue du
serveur est héritée de CVS (l'ancêtre de Subversion).
Nous verrons plus loin pourquoi nous allons importé notre projet dans un répertoire trunk du dépôt
Subversion, et non pas directement à la racine du dépôt. Retenez pour le moment que ce répertoire
trunk est utilisé pour identifier l'axe de développement principal de notre projet. Cela le distingue
d'autres répertoires qui seront utilisés pour gérer les étiquettes et les branches.
Copie locale de travail
Import
Dépôt Subversion
4.1.1 Avec TortoiseSVN
Depuis l'explorateur Windows, sélectionner le répertoire contenant votre copie de travail de travail,
puis via le menu :
1. Fichier > Tortoise > Import
2. Choisir l'URL vers lequel vous allez copier votre projet : http://subversion.cru.fr/projetx/trunk (en remplaçant x par le numéro du poste de la salle de formation). Reste à ajouter
votre commentaire (ex : import initial). Utilisez l'identifiant test_user et le mot de passe
test_user si une fenêtre d'authentification s'affiche.
Pour vérifier l'importation de votre projet local dans le dépôt du serveur Subversion, il suffit de
consulter la page du dépôt http://subversion.cru.fr/projet-x. Le numéro de révision est 1 car le client
a effectué une opération sur le dépôt.
Page 7 / 32
Paris, 27 juin 2007
Une autre vue du contenu du dépôt du serveur Subversion est disponible directement via
TortoiseSVN : cliquez droit dans le répertoire du projet puis TortoiseSVN > Repo-browser.
4.1.2 Avec Subclipse
Créez un projet Eclipse et puis associez-le avec le projet que vous avez créé sur le bureau Windows
:
1. Lancez Eclipse en allant sur le bureau Windows dans le répertoire Eclipse puis doublecliquez sur l'icône Eclipse
2. File > New > Project... > General - Project > Next
3. saisissez projet-x comme dans 'Project name', décochez 'Use default location' et sélectionner
le répertoire de votre projet que vous avez créé sur le bureau Windows
4. Finish
Puis associez ce projet Eclipse avec votre dépôt Subversion :
1. dans la vue 'Package explorer' cliquez droit sur le répertoire mon-projet
2. Team > Share Project... > SVN > Next > Create a new repository location > Next
3. dans le champ URL saisissez http://subversion.cru.fr/projet-x (en remplaçant x par le
numéro du poste de la salle de formation) ; si la fenêtre 'Accept Digital Certificate' apparaît,
cliquez 'Accept Permanently' ; si une fenêtre d'authentification apparaît, utilisez l'identifiant
test_user et le mot de passe test_user.
4. dans la fenêtre 'Enter Folder Name', cochez 'Use specified folder name' et saisissez trunk
5. Finish
6. une fenêtre 'Commit to...' apparaît ; vous pouvez modifier le message de commit ; cliquez
sur OK. Utilisez l'identifiant test_user et le mot de passe test_user si une fenêtre
d'authentification s'affiche.
Pour vérifier que l'importation de votre projet local dans le dépôt du serveur Subversion est réussie
vous pouvez vérifier :
●
avec un navigateur que la page du dépôt http://subversion.cru.fr/projet-x affiche bien le
contenu de votre projet ; le numéro de révision est 2 car le client Subclipse a en fait effectué
deux opérations successives : 1. la création du répertoire trunk sur le dépôt, 2. l'importation
des fichiers de votre projet dans le dépôt (le commit proprement dit)
●
que la vue 'Console' d'Eclipse affiche les commandes Subversion effectué par le client
Subclipse : vous pouvez voir les deux opérations réalisées par le client Subclipse
Page 8 / 32
Paris, 27 juin 2007
mentionnées sur le point précédent
●
Subclipse propose une vue directe du contenu du dépôt du serveur Subversion :
Windows > Open Perspective > Other... > SVN Repository Exploring
Pour une raison inexpliquée, les propriétés de versionning des données (author, revision, date) ne
s'affichent pas systématiquement, à droite des fichiers et répertoires dans la vue navigateur. Pour y
remédier, il est nécessaire de relancer eclipse.
Cette imporation étant effectuée, vous pouvez supprimer entièrement votre projet en local car il est
désormais enregistré dans le dépôt du serveur Subversion :
●
avec TortoiseSVN : il suffit de sélectionner le répertoire de votre copie de travail et de le
supprimer.
●
avec Subclipe : dans la vue 'Package Explorer', cliquez droit sur le répertoire mon-projet
puis Delete puis en choisissant 'Also delete contents under...'.
4.2 Récupérer sur son poste de travail un projet contenu dans un
dépôt Subversion
Plaçons-nous maintenant dans la situation où l'on souhaite récupérer un projet contenu dans un
dépôt Subversion afin de travailler avec sur notre poste de travail. Dans la terminologie Subversion,
cela s'appelle récupérer une copie de travail (en Anglais : checkout a working copy).
Copie de travail
Une copie de travail est le contenu d'un dépôt Subversion à une révision donnée. Au niveau du
poste de travail, une copie de travail se présente dans le système de fichier comme un répertoire qui
contient les fichiers et répertoires du projet, ainsi que des méta informations qui permettront
notamment au client Subversion de reporter vers le dépôt du serveur Subversion les modifications
que l'on apportera à la copie de travail.
Nous allons réutiliser le projet que nous venons d'importer dans le serveur Subversion, en
récupérant une copie de travail sur son poste de travail.
checkout
Dépôt Subversion
Page 9 / 32
Paris, 27 juin 2007
1. Créer le répertoire dans lequel vous voulez enregistrer votre copie de travail
2. Cliquez droit sur ce répertoire puis SVN Checkout
3. Dans le champ URL, saisissez http://subversion.cru.fr/projet-x/trunk (changez le x avec le
numéro de votre poste dans la salle de formation) ; si une fenêtre d'authentification apparaît,
utilisez l'identifiant test_user et le mot de passe test_user.
4. Vérifier dans le contenu du répertoire que vous avez bien récupéré le contenu du dépôt.
Commencez par avoir une Perspective de votre dépôt Subversion dans Eclipse :
1. Windows > Open Perspective > Other... > SVN Repository Exploring > OK
2. Dans la vue 'SVN Repository' cliquez droit puis New > Repositoy Location...
3. Dans le champ URL, saisissez http://subversion.cru.fr/projet-x/trunk (changez le x avec le
numéro de votre poste dans la salle de formation) ; si une fenêtre d'authentification apparaît,
utilisez l'identifiant test_user et le mot de passe test_user
Vous pouvez voir dans la vue 'SVN Repository' votre dépôt Subversion et son contenu. Notez que
pour le moment rien n'a été téléchargé sur votre poste, il s'agit simplement d'une vue du contenu du
dépôt sur le serveur Subversion. Pour en créer une copie de travail locale :
1. Dans la vue 'SVN Repository' cliquez droit sur l'URL de votre dépôt puis Checkout...
2. Chosissez 'Check out as a project in the workspace'. Notez que vous pouvez spécifier un
numéro de Revision, en laissant coché 'Head Revision' vous récupérez la dernière révision
disponible dans le dépôt.
3. Finish
Subclipse récupère ainsi la dernière révision contenue dans le dépôt et créé une copie de travail dans
votre workspare Subversion. Pour voir cette copie de travail Windows > Show View > Navigator.
TortoiseSVN et Subclipse « comprennent » qu'une copie de travail est liée à un dépôt Subversion
grâce à la présence d'un répertoire caché .svn dans le répertoire de la copie de travail. C'est ce
répertoire .svn qui contient les méta données Subversion associées à la copie de travail. Chaque
sous-répertoire de la copie de travail contient également un dossier caché .svn.
A tout moment il est possible de vérifier de quel dépôt est issu une copie de travail :
●
avec TortoiseSVN : cliquez droit sur le répertoire de votre copie de travail puis Propriétés,
ouvrez le deuxième onglet « Subversion »
Page 10 / 32
●
Paris, 27 juin 2007
avec Subclipse : dans la vue "Navigator" ou "Project Explorer" cliquez droit sur le répertoire
de la copie de travail, puis Properties > Subversion.
Dans cet exercise, en spécifiant l'URL http://subversion.cru.fr/projet-x/trunk nous n'avons en fait
récupéré que le répertoire trunk du dépôt http://subversion.cru.fr/projet-x. Notre copie de travail
n'est associé qu'à un répertoire du dépôt. Notez qu'il est donc possible de ne faire une copie de
travail que d'une partie d'un dépôt Subversion. C'est intéressant de le faire quand l'ensemble d'un
dépôt est volumineux et que l'on n'a besoin de ne travailler que sur une partie.
4.3 Modifier le contenu de sa copie de travail et ensuite enregistrer ces
modifications dans le dépôt
L'application des modifications d'une copie de travail vers le dépôt se fait en deux temps. D'abord
les modifications proprement dites dans la copie de travail, puis leur enregistrement dans le dépôt
avec l'opération commit. C'est l'opération sans doute la plus courante dans l'utilisation de
Subversion.
commit
Dépôt Subversion
1. Modifiez le fichier contenu dans votre copie de travail
2. Cliquez droit sur le répertoire trunk puis SVN Commit...
3. Dans le champ message vous pouvez saisir un message de log associé à cette opération puis
OK
4. La fenêtre suivante vous indique les opérations effectuées, et se termine par l'état et le
numéro de version.
Les modifications se réalisent comme si la copie de travail n'avait aucun lien avec Subversion. Par
exemple pour éditer le fichier document.txt :
1. Dans la vue Navigator, cliquez droit sur le fichier document.txt puis Open
2. Ajouter une ou plusieurs lignes de texte à votre fichier
Pour enregistrer ces modifications au dépôt Subversion, il faut réaliser une opération de commit.
C'est l'une des commandes que l'on utilise le plus souvent avec Subversion :
Page 11 / 32
Paris, 27 juin 2007
1. Dans la vue Navigator, cliquez droit sur le projet trunk, puis Team > Commit...
2. Dans la fenêtre 'Commit to', saisissez un commentaire et vérifier que le fichier que vous
avez modifié est coché, puis cliquez sur OK
Avec un navigateur web vous pouvez vérifier que le fichier dont vous venez d'enregistrer les
modifications a bien été modifié dans le dépôt du serveur Subversion.
Révisions et numéros de révision
Notez également que le numéro de révision a augmenté. A chaque modification du dépôt,
Subversion incrémente en effet d'une unité le numéro de révision du dépôt, quelque soit le nombre
de fichiers concernés par la modification. Une révision identifie donc l'ensemble du dépôt dans un
état donné au cours du temps. Le dépôt d'un Subversion contient l'ensemble des révisions d'un
projet créées au cours du temps. Elles ne sont pas chacune stockées intégralement, mais pour la
plupart sous la forme des différences avec la révision précédente.
Faîtes de nouvelles modifications dans votre copie : édition, suppression, renommage d'un fichier
ou d'un répertoire. Après chacune de ces opérations il faut effectuer un commit pour qu'elle soit
enregistrée dans le dépôt.
Vérifiez que vous pouvez appliquer un commit sur un seul fichier, sur un répertoire et toute sa sousarborescence, sur un groupe de fichiers et/ou répertoires, sur l'ensemble de la copie de travail.
Attention, l'ajout d'un fichier ou d'un répertoire demande une étape supplémentaire : il faut en effet
spécifier à ToirtoiseSVN et Subclipse que le fichier ou répertoire nouvellement créé à vocation à
être enregistré dans le dépôt Subversion lors du prochain commit. Pour cela, après avoir créé le
fichier dans la copie de travail :
●
avec TortoiseSVN : cliquez droit sur le fichier puis TortoiseSVN > Add... puis OK
●
avec Subclipse : cliquez sur le fichier puis Team > Add to Version Control
Commit atomique
Un intérêt de Subversion est que l'opération de commit est atomique. Cela signifie que soit
l'opération réussit entièrement, et dans ce cas l'ensemble des enregistrements à effecuer dans le
dépôt est réalisé, soit l'opération échoue (au début, au milieu ou en cours des modifications) et dans
ce cas aucune modification n'est appliquée sur le dépôt. Grâce à cette propriété l'on est assuré que
jamais le dépôt ne sera retrouvera dans un état intermédiaire non souhaité.
À quel rythme faut-il effectuer des commit ?
Les "bonnes pratiques" de développement invitent à effectuer ses commits souvent, et dans la
Page 12 / 32
Paris, 27 juin 2007
mesure du possible en groupant dans un même commit les modifications qui correspondant à une
même fonctionnalité. L'idéal est de tester et valider en local ses modifications avant d'appliquer
l'enregistrement dans le dépôt avec le commit. Lorsqu'il y a plusieurs développeurs des commits
réguliers simplifient la gestion des conflits et facilitent le suivi du travail des uns et des autres.
Faut-il renseigner les messages de log lors d'un commit ?
Oui c'est important pour les autres développeurs et pour vous plus tard lorsque vous consulterez
l'historique des messages de log de votre dépôt. Un message de log ne doit pas décrire l'opération
effectuée ("édition du fichier main.c") mais plutôt la raison de l'opération ("correction d'un bogue
#245"). En fait il est possible avec Subversion de connaître quelle opération est associée à un
message de log, et sur quels fichiers et/ou répertoires elle porte. Il est donc redondant d'écrire cette
information dans le message de log. Voyez par exemple les instructions données aux développeurs
de Subversion (le projet Subversion est géré lui-même dans un dépôt Subversion) :
http://subversion.tigris.org/hacking.html#log-messages
Avec TortoiseSVN il est possible d'empêcher un commit tant qu'un message de log est vide, voir
http://tortoisesvn.net/docs/release/TortoiseSVN_fr/tsvn-howto-minlogmsgsize.html#tsvn-howtominlogsize-projectproperties.
4.4 Ne pas enregistrer certains fichiers et répertoires de sa copie de
travail dans le dépôt
Lorsque l'on développe sur son poste de travail dans sa copie de travail, un certain nombre de
fichiers et répertoires n'ont pas forcément vocation à être enregistrés dans le dépôt du serveur
Subversion, par exemple des fichiers temporaires ou des données de test. Subversion offre un
mécanisme pour empêche de se voir proposer l'ajout de ces fichiers à chaque opération de commit.
1. Créez un fichier file.tmp dans votre copie de travail
2. Cliquez droit sur ce fichier puis TortoiseSVN > Add to ignore list
3. TortoiseSVN vous propose de n'ignorer que ce fichier ou tous les fichiers ayant la même
extension.
4. Editer un autre fichier puis effectuez un commit sur le réperoitre de votre copie de travail : le
fichier file.tmp n'apparaîtra pas dans la liste des fichiers de la boîte de dialogue de commit
Page 13 / 32
Paris, 27 juin 2007
Vous pouvez effectuer l'opération inverse en cliquant droit sur le fichier puis TortoiseSVN >
Remove from ignore list.
1. Créez un fichier file.tmp dans votre copie de travail : dans la vue 'Navigator' cliquez droit
sur le répertoire racine de votre projet puis New > File
2. Cliquez droit sur ce fichier puis Team > Add to svn:ignore
3. Subclipse vous propose alors de choisir de n'ignorer que ce fichier, tous les fichiers avec une
certaine extension ou de définier un modèle de noms de fichiers à ignorer. Consultez la
documentation pointée dans cette boître de dialogue si vous voulez en savoir plus sur ces
différentes options.
4. Editer un autre fichier puis effectuez un commit, le fichier file.tmp n'apparaîtra pas dans la
liste des fichiers de la boîte de dialogue de commit
Que doit-on conserver dans le dépôt ?
Une règle simple est de ne pas enregistrer ce qui peut être automatiquement généré, des fichiers
compilés ou de la documentation Javadoc par exemple. Outre l'alourdissement inutile du dépôt et le
fait que le reste du contenu permet de les reconstituer, il y a toujours des risques que ces fichiers ne
soient pas à jour par rapport à leurs sources dans une révision si les développeurs ne prennent pas
soin de systématiquement les régénérer avant chaque commit.
Inversement on aura intérêt à enregistrer dans le dépôt tout ce qui susceptible de changer au cours
du temps et qui ne peut être automatiquement généré à partir du reste : code, documentation, ce qui
peut servir au déploiement de l'application (script d'installation par exemple).
4.5 Suivre les modifications apportées sur sa copie de travail depuis le
moment où l'on a réalisé l'enregistrement précédent ou fait le checkout
Lorsque l'on travaille sur sa copie de travail, les modifications que l'on apporte peuvent être
importantes. Parfois, avant de réaliser leur enregistrement dans le dépôt via un commit, on peut
vouloir vérifier quelles sont les modifications que l'on a effectuées depuis le moment où l'on a
réalisé l'enregistrement précédent ou fait le checkout.
Plusieurs moyens sont possibles :
●
Après un rafraîchissement de l'affichage avec la touche F5, des icônes indiquent le statut de
Page 14 / 32
Paris, 27 juin 2007
chaque fichier et répertoire de la copie de travail ayant changé. Consultez la page
http://tortoisesvn.net/docs/release/TortoiseSVN_fr/tsvn-dug-wcstatus.html#tsvn-dugwcstatus-1 pour connaître la signification de ces icônes.
●
En cliquant droit sur le fichier ou répertoire puis Propriétés dans l'onglet Subversion vous
pouvez voir son statut dans le champ Text Status.
●
On peut aussi lancer la commande commit sans la valider, car elle affiche l'état des
différents fichiers qui ont changé (créés, supprimés, modifiés, renommés).
Il existe plusieurs méthodes :
●
Pour chaque fichier et répertoire Subclipse affiche dans les vues 'Navigator' et 'Project
Explorer' des icônes différentes selon qu'un fichier ou un répertoire ait été modifié,
supprimé, ajouté... depuis le moment où l'on a réalisé l'enregistrement précédent ou fait le
checkout. Attention ces icônes ne sont pas systématiquement mis à jour, utilisez la fonction
Refresh d'Eclipse pour avoir une vue à jour.
●
De plus à droite du nom du fichier apparaissent plusieurs informations : le numéro de la
dernière révision à laquelle le fichier a changé (édition, création, renommage...), la date et
l'auteur de cette modification.
●
Toutes les informations relatives à Subversion pour un fichier ou répertoire d'une copie de
travail sont visibles en cliquant droit sur le fichier ou répertoire puis Properties >
Subversion.
●
On peut aussi lancer la commande commit sans la valider, car elle affiche l'état des
différents fichiers qui ont changé (créés, supprimés, modifiés, renommés).
Pour chaque fichier, on peut voir les différences, ligne à la ligne, entre la version actuelle et la
version de l'enregistrement précédent ou du checkout. Pour cela, modifiez un fichier, puis :
1. avec TortoiseSVN :cliquez droit sur le fichier puis TortoiseSVN > Diff
2. avec Subclipse : cliquez droit sur le fichier puis Compare With > Base Revision
Une vue des différences apparaît alors.
Pristine copies
Cette fonctionnalité de comparaison est possible car dans les méta données .svn d'une copie de
travail sont contenues les versions originales de chaque fichier. C'est ce qu'on appelle les pristine
copies. Leur numéro de révision est identifié par le mot-clé 'BASE'. C'est par rapport à ces pristine
copies qu'est effectuée l'opération de comparaison. Leur existence dans les copies de travail
Page 15 / 32
Paris, 27 juin 2007
permettent à un client Subversion d'effectuer plusieurs opérations sans avoir à contacter le serveur.
4.6 Annuler des modifications réalisées sur la copie de travail
Grâce à ces pristine copies, il est possible d'annuler des modifications réalisées dans votre copie de
travail depuis sa dernière mise à jour. Editez un ou plusieurs fichiers de votre copie de travail. Vous
allez maintenant pouvoir annuler ces modifications grâce à la commande revert de votre client
Subversion.
Sélectionnez un fichier vu comme tel, puis :
1. Menu TortoiseSVN > Revert
2. Selectionnez les fichiers pour lesquels vous voulez annuler les modifications
Pour annuler les modifications sur lesquelles vous souhaitez revenir :
1. sélectionnez le ou les fichiers qui ont été modifiés
2. cliquez droit et choisissez Team > Revert... > OK
Pour annuler toutes les modifications de la copie locale, il suffit dans l'étape 1 de sélectionner le
répertoire racine du projet.
4.7 Consulter l'historique des modifications du dépôt
Subversion enregistre toutes les opérations effectuées sur le dépôt. Pour chaque modification, son
auteur associe un message de log. Il est possible de consulter l'historique des modificiations pour
un dépôt dans son ensemble, pour un fichier ou un répertoire.
1. Cliquez droit sur l'élément dont vous voulez connaître l'historique (répertoire de la copie
locale, sous-répertoire, fichier) puis TortoiseSVN > Show log. Une fenêtre présente un
tableau des messages de log des opérations en relation avec l'élément sélectionné, avec
dates, auteurs et messages de logs de ces modifications.
Page 16 / 32
Paris, 27 juin 2007
1. Dans les vues 'Navigator', 'Package Explorer' cliquer droit sur le projet, le fichier ou le
répertoire dont vous voulez connaître l'historique des modifications, puis Team > Show
History
2. La vue 'History' s'affiche en indiquant les numéros de révisions auxquelles l'élément a été
modifié (ou créé, renommé...), avec les dates, auteurs et messages de logs de ces
modifications.
Page 17 / 32
Paris, 27 juin 2007
5 Travailler à plusieurs sur un dépôt
Les opérations décrites dans le chapitre précédent permettent d'utiliser Subversion lorsque l'on
travaille seul sur un dépôt. Cependant elles deviennent insuffisantes pour gérer l'utilisation d'un
dépôt par plusieurs développeurs sur un même projet. L'objectif de ce chapitre est de vous fournir
les commandes et bonnes pratiques qui simplifient le travail à plusieurs sur un dépôt Subversion.
Vous verrez quel cycle de commande typique un développeur doit suivre pour minimiser les risques
de conflit, gérer ces conflits quand ils surviennent, et comment retrouver l'auteur d'une modification
précise.
Vous allez simuler un travail entre deux développeurs sur votre projet en créant une seconde copie
de travail sur votre poste de travail. Pour cela reprenez les instructions du chapitre "Récupérer sur
son poste de travail un projet contenu dans un dépôt Subversion" en prenant soin de choisir un nom
différent du répertoire (avec TortoiseSVN) ou projet (pour Eclipse "Project Name") de votre
première copie de travail. Par exemple suffixez avec '2' le nom de votre seconde copie de
travail.N'apportez pour le moment aucune modification à cette nouvelle copie de travail.
Avec les clients TortoiseSVN et Subclipse une session utilisateur unique est partagée pour les accès
des différentes copies de travail. Les modifications au dépôt apportées via vos deux copies de
travail auront donc le même auteur, mais cela ne change en rien les mécanismes décrits par la suite.
5.1 Mettre à jour son dépôt
Lorsque plusieurs développeurs travaillent sur un même dépôt, il est important que chacun s'assure
que sa copie de travail soit la plus à jour possible avant qu'il ne commence à retravailler dessus.
Pour cela, un développeur, quand il souhaite apporter de nouvelles modifications à son projet dans
le dépôt, pourrait supprimer sa copie de travail et refaire une copie de travail en récupérant la
dernière révision disponible avec un checkout.
Subversion propose une façon de faire plus simple et rapide au travers de la commande update. Elle
permet de mettre à jour une copie de travail existante : le client Subversion met à jour la copie de
travail en interrogeant le dépôt Subversion pour récupérer la dernière révision disponible. Pour
utiliser la commande update :
●
avec TortoiseSVN : cliquez droit sur le répertoire de votre copie de travail puis SVN Update
●
avec Subclipse : dans la vue 'Navigator' ou 'Package Explorer' cliquez droit sur le répertoire
racine de votre copie de travail puis Team > Update
Vérifiez l'intérêt de cette commande update au travers de l'exercice suivant :
1. faîtes un update sur chacune de vos deux copies de travail pour les positionner à la même
révision.
2. apportez des modifications dans votre première copie de travail puis enregistrez-les dans le
dépôt
Page 18 / 32
Paris, 27 juin 2007
3. appliquez un update dans votre seconde copie de travail et vérifiez que les modifications
effectuées dans votre première copie de travail ont été répercutées dans la seconde copie de
travail
Dans ce scénario, le développeur de la seconde copie de travail n'a rien modifié dans sa copie de
sauvegarde entre le moment où il a fait son premier update (étape 1 ci-dessus) et celui où il refait un
update qui ramène les modifications du premier développeur (étape 3). Bien sûr dans la "vraie vie"
(si l'on peut dire ça en parlant d'informatique...) cela ne se passe pas toujours ainsi et des collisions
peuvent avoir lieu. Nous allons voir maintenant comment gérer ces cas avec Subversion.
5.2 Gestion des conflits
Dans la terminologie Subversion, un conflit désigne la situation où deux développeurs ont modifié
en parallèle le même fichier dans leur copie de travail, et ensuite l'enregistrent l'un après l'autre dans
le dépôt : les modifications du second enregistrement vont potentiellement détruire les
modifications qui ont été enregistrées en premier. Subversion propose deux mécanismes pour gérer
cette situtation : un fonctionnement par défaut, l'optimistic locking, et un système de verrouillage
locking.
L'optimistic locking sera expliqué en cours de journée dans la présentation PowerPoint. Prévenez
les formateurs quand vous êtes rendus ici si cette partie n'a pas encore été exposée.
L' optimistic locking et le locking sont présentés dans le manuel de référence, où l'optimistic
locking est appelé "Copy-Modify-Merge Solution" et le locking "The Lock-Modify-Unlock
Solution" :
http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html
Ce manuel rappelle également les trois sens différents du mot lock que l'on peut rencontrer dans
Subversion :
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html#svn.advanced.locking.meanings
5.2.1 Optimistic locking dans le cas où des modifications concernent des
lignes différentes d'un fichier
Suivez le scénario suivant pour comprendre de l'optimistic locking de Subversion dans le cas où les
modifications concernent des lignes différentes d'un même fichier :
1. faîtes un update sur chacun de vos copies de travail pour vous assurer qu'elles sont à jour
2. éditez dans chacune le même fichier, mais sur des lignes différentes (par exemple la
première pour la première copie de travail, et la dernière pour la seconde copie de travail)
3. faîtes un commit pour appliquer les modifications de la première copie de travail dans le
Page 19 / 32
Paris, 27 juin 2007
dépôt
4. faîtes un commit pour appliquer les modifications de la seconde copie de travail dans le
dépôt : une erreur "Merge conflict during commit" s'affiche. Elle signifie que le fichier que
vous essayer d'enregistrer dans le dépôt a changé dans le dépôt depuis la dernière fois que
vous avez fait un update de votre copie de travail.
5. faîtes un update de votre seconde copie de travail, aucun message d'erreur ne doit s'afficher.
Vous pouvez vérifier le contenu de votre fichier pour constater que votre client Subversion a
fusionné les modifications du fichier issu du dépôt (qui incluait les modifications effectuées
dans la première copie de travail) avec vos modifications locales.
6. vous pouvez ensuite effectuer un commit de votre seconde copie de travail pour enregistrer
dans le dépôt le fichier incluant les deux modifications.
La fusion réalisée par Subversion est uniquement syntaxique
Subversion réalise la fusion de deux versions d'un fichier sans déclencher d'erreur quand ce sont des
lignes différentes qui diffèrent. Cependant cette fusion automatique n'empêche pas bien sûr
d'introduire potentiellement des bogues dans votre fichier, dans le cas où les modifications
fusionnées sont contradictoires dans la conception de votre programme.
5.2.2 Optimistic locking dans le cas où des modifications concernent les
mêmes lignes d'un fichier
Suivez le scénario suivant pour comprendre de l'optimistic locking de Subversion dans le cas où les
modifications concernent les mêmes lignes d'un même fichier :
1. faire un update sur chacun de vos copies de travail pour vous assurer qu'elles sont à jour
2. dans chaque copie de travail, éditer la même ligne du même fichier (par exemple la
première) en y écrivant des choses différentes
3. faîtes un commit pour appliquer les modifications de la première copie de travail dans le
dépôt
4. faîtes un commit pour appliquer les modifications de la seconde copie de travail dans le
dépôt : une erreur ("Commit failed (details follow)" pour TortoiseSVN, "Merge conflict
during commit" pour Subclipse) s'affiche. Elle signifie que le fichier que vous essayer
d'enregistrer dans le dépôt a changé dans le dépôt depuis la dernière fois que vous avez fait
un update de votre copie de travail.
5. faîtes un update de votre seconde copie de travail. Avec TortoiseSVN s'affiche le message
"One or more files are in conflicted state", avec Subclipse aucun message d'erreur ne
s'affiche. Dans les deux cas, votre fichier a été largement modifié : Subversion y a inclut des
séquences particulières. D'autre part d'autres fichiers ont été créés, qui n'ont pas vocation à
être enregistrés dans le dépôt, mais qui permettent de bien identifier les différentes versions
Page 20 / 32
Paris, 27 juin 2007
du fichier :
1. un fichier .mine qui est la version que vous vous apprêtiez à commiter
2. un fichier suffixé par le numéro de révision du dernier update de votre copie de travail
3. un fichier suffixé par le numéro de révision de la dernière révision disponible dans le
dépôt
6. Subversion a bien sûr été incapable de choisir laquelle des modifications d'une même ligne
devait être retenu. C'est à l'équipe de développeur de se mettre d'accord sur le résultat à
retenir. Pour notre exemple faîtes un choix arbitraire en nettoyant le fichier des lignes
insérés par Subversion et en retenant celles que vous souhaitez.
7. Une fois ce choix appliqué dans la copie de travail, effectuez un commit de votre copie de
travail pour enregistrer dans le dépôt le fichier. Avec TortoiseSVN l'erreur "Aborting
commit" s'affiche, avec Subclipse l'erreur "A conflict in the working copy obstructs the
current operation". Elle signifie qu'il faut indiquer explicitement au client Subversion que le
fichier n'est désormais plus 'en conflit'. Pour cela :
●
avec TortoiseSVN : cliquez droit sur le fichier puis TortoiseSVN > Resolved...
●
avec Subclipse : cliquez droit sur le fichier puis Team > Mark Resolved
8. Une fois ceci fait vous pouvez appliquer votre commit pour enregistrer le fichier dans le
dépôt.
L'intérêt de l'optimistic locking
Cette façon de procéder pour gérer les conflits potentiels peut paraître peu naturelle et peu fiable.
Cependant en pratique elle fonctionne bien (au point donc que cela soit le mode de fonctionnement
par défaut de Subversion) : un bon découpage des tâches entre développeurs dans un projet
implique qu'il doit être rare que deux développeurs modifient simultanément les mêmes lignes d'un
fichier. L'expérience d'un système de locking explicite de verrouillage de fichier (empêchant un
autre développeur de travailler sur un même fichier) présente en pratique plus d'inconvénients que
d'avantages, notamment à cause des oublis de déverouillage.
5.2.2.1 La vue Synchronize with Repository d'Eclipse
Avec la vue Synchronize with Repositroy, Eclipse offre des outils performants pour simplifier la
gestion des modifications concurrentes sur un dépôt Subversion. Voici un exemple d'utilisation en
reprenant le scénario précédant :
1. réitérez les opérations 1, 2 et 3 du paragraphe 5.2.2
2. cliquez droit sur la racine de votre seconde copie de travail puis Team > Synchronize with
Repository. En bas de la fenêtre Eclipse apparaissent trois flèches de différentes couleurs et
un chiffre à côté de chaque. La troisième, en rouge, donne le nombre de fichiers en conflit
Page 21 / 32
Paris, 27 juin 2007
entre la seconde copie de travail et le dépôt.
3. Dans la vue Synchronize double cliquez sur le fichier marqué d'une icône rouge. Il apparaît
une vue où la version locale du fichier et celle du dépôt sont mises en vis-à-vis. Vous
pouvez naviguer entre les différents parties qui divergent. Cela facilite grandement
l'intégration ou la non intégration de modifications dans une copie de travail, quand ces
modifications concernent des fichiers de grande taille. Modifier votre fichier pour retenir les
modifications que vous souhaitez.
4. Cliquez droit sur le fichier puis Team > Mark as Merged
5. Dans la vue Navigator cliquez droit sur le fichier puis Team > Commit pour enregistrer
votre fichier dans le dépôt.
5.2.3 Locking
La nécessité du locking dans certaines situations
Il existe parfois des situations où un système de verrouillage explicite est utile. Par exemple pour les
fichiers binaires où il est impossible de réaliser une fusion ligne à ligne. Ou lorsque la notification
d'un bogue de sécurité critique peut amener deux développeurs à vouloir simultanément corriger ce
bogue. Dans ce cas il peut être utile pour le premier développeur qui intervient, de verrouiller le
fichier afin de terminer sa correction sans avoir à gérer d'interaction avec d'autre développeur.
Nous ne détaillons pas dans cette formation l'utilisation du locking dans Subversion mais vous
pouvez consultez les documentations en ligne suivantes pour vous exercer sur le locking à l'aide de
vos deux copies de travail :
●
manuel de référence de Subversion :
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
●
documentation de TortoiseSVN :
http://tortoisesvn.net/docs/release/TortoiseSVN_fr/tsvn-dug-locking.html
●
pour Subclipse : le locking est supporté dans Subclipse mais pas documenté. Vous pouvez
essayer de suivre la documentation de TortoiseSVN en l'adaptant au contexte Subclipse. La
commande Lock est accessible dans le menu contextuel Team.
5.2.4 Cycle de travail typique avec Subversion
Tout ce que nous avons vu jusqu'à présent permet d'établir un cycle de travail typique avec
Subversion. Il s'agit d'un enchaînement de commandes qu'il est recommandé de suivre pour
minimiser les risques de conflits et de blocage. Il commence au moment où un développeur souhaite
travailler sur sa copie de travail et s'achève au moment où il enregistre ses modifications dans le
dépôt :
Page 22 / 32
Paris, 27 juin 2007
1. mise à jour de sa copie de travail avec update pour être sûr d'avoir la dernière révision
disponible dans le dépôt, incluant les éventuelles dernières modifications faîtes par d'autres
développeurs.
2. travail sur sa copie de travail : édition/création/ajout/suppression/renommage de fichiers et
répertoires
3. visualisations des modifications par rapport à l'état initial de sa copie de travail et
éventuellement l'état actuel du dépôt
4. mise à jour de sa copie de travail via update pour détecter d'éventuels conflits, puis dans ce
cas résolution des conflits
5. enregistrement des modifications avec commit
6. retour à l'étape 1
5.3 Qui a changé quelle ligne ?
La commande blame de Subversion est très utile. En Anglais "blame" signfier accuser... Elle permet
de savoir, pour un fichier donné, qui est l'auteur de la dernière modification de chaque ligne. Les
joies du travail en équipe amènent en effet parfois à devoir investiguer jusqu'à ce niveau de détail.
Dans notre situation simplifiée où le même utilisateur travaille sur les deux copies de travail,
l'accusé est tout désigné et l'application de cette commande ne révélera pas grand chose. Voici
quand même la façon d'utiliser cette commande.
1. Cliquez droit sur le fichier puis TortoiseSVN > Blame...
2. Cliquez OK dans la fenêtre qui apparaît. Elle permet de définir la fenêtre des révisions sur
laquelle on veut connaître l'auteur des modifications. Le choix par défaut est tout l'historique
du dépôt.
3. La fênetre qui s'affiche liste pour chaque ligne du fichier l'auteur de la dernière modification
de la ligne et la révision à laquelle a eu lieu cette modification. Consultez la documentation
http://tortoisesvn.net/docs/release/TortoiseSVN_fr/tsvn-dug-blame.html pour connaître
toutes les possibilités d'inspection offertes.
1. Cliquez droit sur le fichier puis Team > Show Annotate
2. Dans la vue du fichier qui s'affiche, placez la souris à gauche d'une ligne pour voir
apparaître le nom de l'auteur et la date de la dernière modification de cette ligne.
Page 23 / 32
Paris, 27 juin 2007
6 Gérer le cycle de développement d'un logiciel
Le développement d'un logiciel est ponctué par la diffusion de versions, l'ajout de nouvelles
fonctionnalités, la correction de bogues... Les outils de gestion de version (tel Subversion)
permettent l'utilisation d'étiquettes (tags en Anglais) et de branches pour faciliter la gestion de ces
différentes opérations.
Tout le reste...
La problématique de la diffusion d'un logiciel dépasse largement la seule gestion des versions des
sources. Le passage à un produit diffusable a été présenté lors du premier tutoJRES
http://www.jres.org/doku.php?id=tuto/tuto1#comment_rendre_son_developpement_diffusable. Le
document http://producingoss.com/html-chunk/index.html offre un panorama très complet sur la
production d'un logiciel open source.
Les étiquettes et les branches seront expliquées en cours de journée dans la présentation
PowerPoint. Prévenez les formateurs quand vous êtes rendus ici et que cette partie n'a pas
encore été exposée.
6.1 Les étiquettes
6.1.1 Création du répertoire tags
Les étiquettes sont créées dans un répertoire tags situé à la racine du dépôt. Il s'agit d'une
convention, les étiquettes pourraient être situées dans n'importe quel autre répertoire. Nous allons
créer ce répertoire directement dans le dépôt, sans passer par une copie de travail local.
6.1.1.1 Avec TortoiseSVN
1. Depuis le bureau Windows cliquez droit puis TortoiseSVN > Repo-Browser
2. Cliquez droit puis TortoiseSVN > Import...
3. Dans le champ Url saisissez http://subversion.cru.fr/project-x/tags avec comme message de
log 'Création du répertoire des étiquettes', puis OK
6.1.1.2 Avec Subclipse
1. Dans la vue 'SVN Repository' cliquez droit sur l'URL
http://subversion.cru.fr/projet-x puis New > New remote folder
de
votre
dépôt
2. Dans la fenêtre qui apparaît resélectionnez http://subversion.cru.fr/depot-x puis saisissez
tags dans le champ 'Folder name' puis Next puis saisissez un commentaire (par exemple
'Création du répertoire des étiquettes'), puis Finish.
Page 24 / 32
Paris, 27 juin 2007
Vous pouvez voir avec un navigateur web à l'URL http://subversion.cru.fr/depot-x que le répertoire
tags a bien été créé dans votre dépôt. Vous pouvez faire un update de votre copie de travail puis
consultez son historique pour constater que le numéro de révision a été incrémenté d'une unité. C'est
normal, car chaque opération qui modifie le dépôt créé une nouvelle révision.
Effectuer des opérations directement sur le dépôt
Cette opération montre qu'il est possible d'effectuer directement certaines opérations sur un dépôt,
sans passer par une copie de travail : supprimer, renommer, déplacer des fichiers ou répertoies,
créer des répertoires.
Répétez la même opération pour créer à la racine du dépôt le répertoire branches qui sera utilisé
plus tard.
6.1.2 Créer une étiquette
La création d'un étiquette est une opération très simple. Nous prenons ici le cas où nous créons une
étiquette de l'état actuel du dépôt dans le trunk. Nous nommerons cette étiquette REL-1.0 (pour
Release 1.0). Faîtes d'abord un update sur votre copie locale pour la mettre à jour.
1. Cliquez droit sur le répertoire de votre copie de travail puis TortoiseSVN > Branch/tag...
2. Saisissez dans le champ 'To Url' l'adresse http://subversion.cru.fr/projet-x/tags/REL-1.0
3. Saisissez un message de log, par exemple "Création de l'étique pour la release 1.0' puis
cliquez sur OK
4. Vérifiez avec un navigateur web dans http://subversion.cru.fr/projet-x/tags/ que l'étiquette a
bien été créée
1. Cliquez droit sur le répertoire de votre copie de travail puis Team > Branch/tag...
2. Saissiser dans le champ 'To Url' l'adresse http://subversion.cru.fr/projet-x/tags/REL-1.0 et
cochez 'Working Copy'
3. Saisissez un message de log, par exemple "Création de l'étique pour la release 1.0' puis
cliquez sur OK
4. Vérifiez avec un navigateur web dans http://subversion.cru.fr/projet-x/tags/ que l'étiquette a
bien été créée
Page 25 / 32
Paris, 27 juin 2007
Quel nommage retenir pour les étiquettes (et les branches) ?
Il n'y a pas de règles pré définies mais il est important au sein d'un projet de se mettre d'accord sur
une convention de nommage des étiquettes et branches.
Comment empêcher la modification d'une étiquette ?
Le contenu d'une étiquette n'a pas vocation à priori à changer, puisqu'une étiquette sert à identifier
le dépôt à un instant donné. Or les étiquettes n'étant que des copies de certaines révisions dans le
répertoire tags, rien n'empêche à priori de les modifier. Il est possible de rendre les étiquettes du
répertoire tags non modifiables en utilisant un hook script au niveau du serveur (les hook scripts
sont abordés en fin de cette formation). En général les développeurs se contentent de se mettre
d'accord pour ne pas modifier les étiquettes existantes.
6.1.3 Faire une version diffusable de son logiciel à partir d'une étiquette
En général un logiciel est diffusé sous la forme d'un paquet ou d'une archive par exemple, les
utilisateurs finaux ne vont pas dans un dépôt Subversion pour récupérer une étiquette. Pour préparer
une version diffusable de son logiciel, il faut extraire du dépôt une étiquette. Pour cela la commande
checkout n'est pas recommandée, car elle rapatrie les méta données Subversion qui sont inutiles
hors du contexte de l'utilisation de Subversion.
Il est préférable d'utiliser la commande export qui permet d'extraire depuis le dépôt une révision ou
étiquette :
●
avec TortoiseSVN :
1. Allez dans le vue Repository Browser : cliquez droit dans le répertoire du projet puis
TortoiseSVN > Repo-browser
2. Cliquez droit sur le répertoire source de la version à diffuser (le trunk ou un sous
répertoire de branches ou de tags) puis Export...
3. Spécifiez dans le répertoire local de destination dans le champ Export directory puis OK
●
avec Subclipse :
1. Allez dans la vue SVN Repository Exploring : Windows > Open Perspective > Other...
> SVN Repository Exploring
2. Cliquez droit sur le répertoire source de la version à diffuser (le trunk ou un sous
répertoire de branches ou de tags) puis Export...
3. Spécifiez dans le répertoire local de destination dans le champ Export directory puis OK
Page 26 / 32
Paris, 27 juin 2007
6.2 Les branches
Les branches peuvent être vues comme une ligne de développement parallèle à la ligne de
développement principale contenu dans le répertoire trunk du dépôt. Elles ont de multiples
utilisations possibles mais leur emploi excessif peut engendrer de la confusion et des problèmes à
terme (les instructions détaillées pour chaque client sont données par la suite).
Voici un scénario pour découvrir l'utilisation des branches. Un bogue a été signalé aux
développeurs et l'un d'entre d'eux se charge de le résoudre. Il semble complexe et long à corriger.
Le faire directement dans la ligne de développement principal (le trunk) mettrait le code dans un
état instable, empéchant sans doute les autres développeurs de continuer à travailler sur l'ajout de
nouvelles fonctionnalités. Voici une méthode pour le développeur corrigeant le bogue qui lui
permet de ne pas pertuber le travail dans le trunk (les instructions détaillées pour suivre le scénario
sont données plus bas) :
1. le développeur crée une branche (du numéro du bogue tel qu'il est enregistré dans le
gestionnaire de tickets du projet)
2. il créée une étiquette pour identifier le démarrage de la correction du bogue
3. il corrige le bogue dans la branche, en plusieurs itérations (commits)
4. il créée une étiquette pour identifier la fin de la correction du bogue
5. il utilise les deux tags pour fusionner la correction dans le trunk et éventuellement d'autres
branches affectées par le bogue
Suivez ces instructions pour mettre en application cette méthode :
1. Une branche se créée de la même façon qu'une étiquette. Reprenez les instructions du
paragraphe "Créer une étiquette" en utilisant comme URL http://subversion.cru.fr/projetx/branches/BUG-214 pour créer une branche nommée BUG-214.
2. Récupérer dans une nouvelle copie de travail la branche que vous venez de créer.
3. A partir de cette copie de travail, créez une étiquette AVANT-214 pour identifier le
démarrage de la correction du bogue.
4. Editez plusieurs fichiers dans la copie de travail de la branche en appliquant plusieurs
commits successifs. Notez que les numéros de version restent globaux à l'ensemble du dépôt.
5. Créez une nouvelle étiquette APRES-214 pour identifier la fin de la correction du bogue.
6. Utilisez les deux étiquettes AVANT-214 et APRES-214 pour fusionner la correction dans
le trunk en suivant les instructions suivantes :
●
avec TortoiseSVN : cliquez droit sur votre copie de travail correspondant au trunk puis
TortoiseSVN > Merge.... Dans la fenêtre spécifiez http://subversion.cru.fr/projet-
Page 27 / 32
Paris, 27 juin 2007
x/tags/AVANT-214 dans le champ 'Start Url' et http://subversion.cru.fr/projetx/tags/APRES-214 dans le champ 'End Url' (pour cela décochez la case 'Use From Url')
puis cliquez sur Merge.
●
Avec Subclipse : cliquez droit sur votre copie de travail correspondant au trunk puis
Team > Merge.... Dans la fenêtre spécifiez
http://subversion.cru.fr/projetx/tags/AVANT-214 dans le champ 'Start Url' et http://subversion.cru.fr/projetx/tags/APRES-214 dans le champ 'End Url' (pour cela décochez la case 'Use From Url')
puis cliquez sur Merge.
7. Vous pouvez vérifiez dans votre copie de travail correspondant au trunk que les
modifications ont bien été appliquées. Si vous aviez d'autres branches dans lesquelles il
faudrait reporter la correction du bogue, il suffirait d'y refaire l'opération de merge de la
même manière.
Dans ce scénario la création et l'utilisation des étiquettes AVANT et APRES n'est pas
indispensable, on aurait pu utiliser à la place les numéros de révision de création de la branche et de
fin d'édition dans la branche. Le risque est de se tromper de numéro de révision lors du merge.
Nous
vous
conseillons
la
lecture
du
chapitre
http://svnbook.redbean.com/nightly/en/svn.branchmerge.html du manuel de référence en ligne si vous souhaitez
mieux comprendre l'utilisation des branches et des fusions.
6.3 Créer et appliquer des patchs
En général un dépôt Subversion n'est accessible en écriture qu'à un certain nombre de développeurs.
Il peut être ouvert en lecture seule à une population plus grande, voir à tout le monde. Ainsi certains
utilisateurs peuvent récupérer des révisions depuis le dépôt pour corriger des bogues ou ajouter de
nouvelles fonctionnalités au produit. Cependant ils n'ont pas les droits pour écrire leurs
modifications dans le dépôt. Ils soumettent aux développeurs du produit leur modification sous
forme de patch. Un patch regroupe les différences entre les fichiers modifiés par l'auteur de la
modification et les fichiers tels qu'il les a récupés depuis le dépôt. Cette forme facilite la tâche d'un
développeur du projet pour appliquer les modifications dans le dépôt.
Pour comprendre comment créer un patch et l'appliquer nous allons suivre le scénario simplifié
suivant :
1. considérer que la première copie de travail est celle d'un contributeur qui ne peut pas écrire
dans le dépôt et que la seconde est celle d'un développeur pouvant écrire dans le dépôt
2. modifier la première copie de travail pour simuler la correction d'un bogue
3. créer un patch
4. appliquer ce patch dans la seconde copie de travail
5. enregistrer les modifications dans la seconde copie de travail
Page 28 / 32
Paris, 27 juin 2007
Commencez par faire un update de vos deux copies de travail, puis modifiez au moins deux fichiers
dans la première. Les deux premières étapes du scénario sont réalisées.
6.3.1 Créer un patch
1. Cliquez droit sur répertoire contenant votre première copie de travail puis TortoiseSVN >
Create patch...
2. Cliquez OK pour inclure dans le patch les différences de tous les fichiers que vous avez
modifiés
3. Enregistrez le patch dans un fichier, en dehors de votre copie de travail
1. Dans la vue 'Navigator' cliquez droit sur la racine de votre copie locale puis Team > Create
Patch...
2. Choisissez 'Save In File System' puis définissez un nom de fichier pour votre patch et un
endroit où l'enregistrer puis cliquez sur Finish
3. La fênetre suivante vous invite à inclure d'éventuels fichiers que vous auriez créé pour votre
patch, dans notre cas cliquez sur 'Deselect All' puis OK
4. Subclipse enregistre par erreur dans le fichier de patch le chemin d'accès complet des
fichiers modifiés. Or il ne faut que le chemin relatif des fichiers modifiés par rapport à la
racine de la copie locale. Il faut corriger ceci à la main : éditez le fichier de patch créé pour
transformer tous les chemins d'accès complet des fichiers modifiés préfixés par "Index: " en
chemin
d'accès
relatifs,
par
exemple
"Index:
C:/Documents
and
Settings/user/workspace/mon-projet/fichier.txt" en "Index: fichier.txt".
6.3.2 Appliquer un patch
1. Cliquez droit sur le répertoire de la seconde copie locale puis TortoiseSVN > Apply patch...
puis sélectionnez votre fichier de patch
2. Deux fenêtres apparaissent pour vous permettre de consulter les modifications apportées sur
chaque fichier modifié par le patch. Pour le moment ces modifications n'ont pas encore été
appliqués à votre copie de travail.
Page 29 / 32
Paris, 27 juin 2007
3. Dans la petite fenêtre double-cliquez sur le premier fichier listé. Vous voyez alors dans
l'autre fenêtre les différences apparaîtrent ligne à ligne. Cliquez sur l'icône de sauvegarde
pour les enregistrer dans votre copie de travail. Répétez l'opération pour chaque fichier listé.
4. Vous pouvez vérifiez dans votre copie de travail que les fichiers ont bien été modifié et
ensuite faire un commit de votre copie de travail pour appliquer les modifications dans votre
dépôt.
1. Dans la vue 'Navigator' cliquez droit sur la racine de votre copie locale puis Team > Apply
Patch...
2. Cliquez sur 'File' puis choisissez votre fichier de patch puis cliquez sur Finish
3. Vous pouvez vérifier dans votre copie de travail que les fichiers ont bien été modifié et
ensuite faire un commit de votre copie de travail pour appliquer les modifications dans votre
dépôt.
Page 30 / 32
Paris, 27 juin 2007
7 Pour aller plus loin
Ce chapitre présente quelques fonctionnalités avancées de Subversion. Nous ne détaillons pas
d'exercices pour les mettre en pratique, mais les pointeurs donnés doivent vous permettre de vous
exercer avec.
7.1 Les propriétés
Les propriétés sont les mécanismes de Subversion qui permettent aux développeurs d'associer des
méta données aux fichiers et répertoires dans un dépôt Subversion (ce ne sont pas les méta données
.svn utilisées par Subversion pour ses propres besions). Une propriété a un nom et un contenu
(chaîne de caractère, données binaires). Comme pour un fichier ou un répertoire, les propriétés
peuvent être modifiées au cours du temps par différents utilisateurs. Ces propriétés sont mises à jour
dans un copie de travail quand la commande update est utilisée et peuvent être elles aussi sujet à des
fusions et conflits.
Il est possible de définir n'importe quelle type de propriété. Voici quelques exemples :
●
associer à ses fichiers sources une propriété nommée reviewer qui contient le nom de la
dernière personne qui a relu et vérifié le fichier source.
●
associer à des fichiers musicaux une propriété nommée sample contenant un extrait du
morceau. C'est plus simple que de stocker dans le dépôt un fichier séparé contenant un
extrait et s'assurer de la cohérence du morceau et son résumé au cours du temps.
●
etc.
Il existe aussi plusieurs propriétés spéciales, qui modifient le comportement de Subversion quand ce
dernier rencontre des fichiers avec ces propriétés spéciales. Le nom de ces propriétés est préfixés
par svn:. Elles sont listées dans le manuel de référence http://svnbook.redbean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.special.
Vous pouvez consulter le manuel de référence de Subversion pour plus de détails sur les propriétés
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html et les documentations des clients
Subversion :
●
pour TortoiseSVN :http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dugpropertypage.html#tsvn-dug-propertypage-props
●
pour Subclipse :
http://svn.collab.net/subclipse/help/index.jsp?topic=/org.tigris.subversion.subclipse.doc/html
/reference/svn-properties-view.html
7.2 Intégrer d'autres dépôts dans sa copie de travail
La propriété spéciale svn:externals permet d'inclure le contenu d'autres dépôts dans sa copie de
Page 31 / 32
Paris, 27 juin 2007
travail. Il faut la définir sur un répertoire et spécifier une liste d'URL d'autres dépôts à inclure
lorsque l'on récupère une copie de travail (checkout). Votre client Subversion ira automatiquement
récupérer le contenu de ces autres dépôts pour les inclure dans votre copie de travail. Il est ainsi
possible d'inclure dans la copie de travail d'un projet le dépôt d'une librairie partagée entre plusieurs
projets. Ces dépôts extérieurs inclus peuvent être hébergés sur le même serveur Subversion ou être
hébergé sur d'autres serveurs sur Internet.
Consultez le manuel de référence de Subversion pour plus de détails sur ce mécanisme :
http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html.
7.3 Les hook scripts
Il s'agit de scripts déclenchés par un évènement qui a lieu sur un dépôt Subversion. Ces scripts sont
installés dans le serveur Subversion, il faut donc être administrateur du serveur Subversion pour les
installer et les configurer. On peut ainsi adapter et enrichir le comportement de Subversion pour les
besoins spécifiques d'un projet, par exemple :
●
empêcher les commits quand le message de log est vide
●
à chaque commit, envoyer un mail à une liste de diffusion contenant l'auteur, la date, les
modifications apportées au commit
●
rendre impossible la modification d'une étiquette
●
imposer un format précis pour les messages de log
●
etc.
Quelques exemples sont fournis sur la page :
http://subversion.tigris.org/tools_contrib.html#hook_scripts.
Si vous avez un dépôt hébergé sur le serveur Subversion de SourceSup, vous pouvez contactez
[email protected] pour demander la mise en place d'un hook script pour votre projet.
7.4 Toujours plus loin...
...tellement loin que les formateurs ne peuvent plus rien pour vous ;)
Consultez le manuel de référence en ligne pour connaître d'autres fonctionnalités avancées de
Subversion : http://svnbook.red-bean.com/nightly/en/svn.advanced.html
8 Conclusion
Une courte conclusion sera présentée à la fin de la journée de formation.
Merci de compléter le formulaire d'évaluation.
Page 32 / 32

Formation à l`utilisation d`un client Subversion

Transcription

Documents pareils

Logiciels de suivi de problèmes

Big bang - destruction et 2005 digitalisiert durch: IDS Luzern

CV développeur Applications WEB - Jean

Serveur Subversion

Tutorial d`utilisation de la forge MAGE

Lire le texte de l`intervention dans les annales médico

GENRE ET SEXE - Bibliothèque de philosophie

Format PDF - CV JUANOLA Stephan

Correspondances Windows-Linux - ORI-OAI