Project

General

Profile

Mise à jour par {{lastupdated_by}} le {{lastupdated_at}}

1. Introduction

Subversion est un système centralisé fait pour partager l'information. Le dépôt constitue le cœur de ce système, en tant que lieu de stockage central des données. Les informations y sont organisées sous la forme d'une arborescence de fichiers, c'est-à-dire une hiérarchie classique de fichiers et de répertoires. Un certain nombre de clients se connectent au dépôt, et parcourent ou modifient ces fichiers. En modifiant des données, un client rend ces informations disponibles à d'autres personnes ; en lisant des données, le client reçoit les informations des autres personnes.

Il existe différents systèmes de gestion de projet et par conséquent différentes méthodes de partage de fichier pour ne pas permettre aux utilisateurs de se marcher mutuellement sur les pieds par accident. SVN n'utilise pas le modèle de verrou ne permettant pas à plusieurs personnes de travailler sur le même fichier, mais le modèle "copier-modifier-fusionner". Attention, il est cependant possible de verrouiller des fichiers avec SVN, ce qui est peut être intéressant dans le cas d'un partage de fichier non fusionnable (images, fichiers propriétaires, binaires), mais ce ne sera que très peu notre cas. Dans le modèle "copier-modifier-fusionner", chaque utilisateur contacte le dépôt du projet via son client et crée une copie de travail personnelle, une sorte de version locale des fichiers et répertoires du dépôt. Les utilisateurs peuvent alors travailler, simultanément et indépendamment les uns des autres, et modifier leurs copies privées. Pour finir, les copies privées sont fusionnées au sein d'une nouvelle version finale. Le logiciel de gestion de versions fournit de l'aide afin de réaliser cette fusion, mais au final la responsabilité de s'assurer que tout se passe bien incombe à un être humain. Il est donc nécessaire pour la dernière personne voulant envoyer ces modifications, de récupérer en premier lieu celles de ses collaborateurs, de fusionner ce qu'il faut le plus souvent à la main et une fois les conflits réglés, envoyer les fichiers sur le dépôt.

2. Structure

La structure choisie pour le projet QExtend est la suivante :


- trunk                               (Stable)
-- tests                              (QTest)
-- demos                              (Sources des exécutables de démonstration de nos innovations )
-- translations                       (Fichiers de traduction)
-- doc                                (Pages en plus de la documentation des classes : sommaire, présentation, modules...)
-- include                            (En-têtes sans extension)
--- core
--- gui
---- qss
----- DynamicProperty
-- src
--- core                              (Modules)
--- gui
---- qss                              (Sous-modules)
----- dynamicproperty.h
----- dynamicproperty.cpp
--- opencv
--- qwt
- tags                                (Versions publiées)
-- 0.1
... Même structure que le trunk
- branches                            (Instable)
-- dev                                (En cours de développement)
... Même structure que le trunk

La partie /trunk et la partie /tags ne peut être altérée, sauf par des personnes compétentes. Toute modification sur un de ces deux branches sera directement annulées. Seule la branche /dev est accessible aux développeurs.

3. Utilisation

3.1 Utilisation d'un client graphique

Les différentes étapes suivantes sont décrites sous la forme de lignes de commandes. Il existe cependant de très bons utilitaires graphiques pour la gestion du SVN tels que TortoiseSVN sur Windows, RapidSVN sur Linux et Versions sur Mac OS. Je vous conseille de les utiliser pour plus de facilité.

3.2 Création de votre dépôt local

La première étape pour travailler sur le projet QExtend est de faire une extraction (checkout en anglais) de la branche de développement pour créer un dépôt local. Pour cela, utilisez la commande svn checkout.

svn checkout http://subversion.developpez.com/projets/qextend/branches/dev

Aucun identifiant ni mot de passe ne vous est demandé à cette étape. C'est normal étant donné qu'il s'agit d'un projet Open Source, il est disponible en lecture à tout le monde.

3.3 Mettre à jour votre copie de travail

Etant donné que QExtend est un projet communautaire, vous devez mettre à jour votre copie locale pour recevoir toutes les modifications qui ont pu être faites par les autres développeurs du projet depuis votre dernière mise à jour. Utilisez svn update pour synchroniser votre copie de travail avec la dernière version présente dans le dépôt

svn update

3.4 Apporter des modifications à votre copie de travail

Vous pouvez à présent vous mettre au travail et apporter des modifications à votre copie de travail. Il est plus commode, habituellement, de démarrer par une modification (ou un ensemble de modifications) précise, comme écrire une nouvelle fonctionnalité, corriger un bug, etc. Les commandes Subversion dont vous vous servez pour cela sont svn add, svn delete, svn copy et svn mkdir. Cependant, si vous ne faites qu'éditer des fichiers qui sont déjà dans Subversion, vous n'avez besoin d'aucune de ces commandes jusqu'à ce que vous propagiez vos modifications.

Voici un aperçu des cinq sous-commandes Subversion les plus utilisées pour faire des modifications sur l'arborescence :

  • svn add truc
    Marque le fichier, le répertoire ou le lien symbolique truc pour ajout. Lors de la prochaine propagation, truc devient un fils de son répertoire parent. Notez que si truc est un répertoire, tout ce qui se trouve à l'intérieur de truc est marqué pour ajout. Si vous ne désirez ajouter que truc lui-même, passez l'option --depth empty.
  • svn delete truc
    Marque le fichier, le répertoire ou le lien symbolique truc pour suppression. Si truc est un fichier ou un lien, il est immédiatement supprimé de votre copie de travail. Si truc est un répertoire, il n'est pas supprimé, mais Subversion le marque pour suppression. Quand vous propagez vos modifications, truc est complètement supprimé de votre copie de travail et du dépôt.
  • svn copy truc bidule
    Crée un nouvel élément bidule par duplication de truc et marque automatiquement bidule pour ajout. Lorsque bidule est ajouté au dépôt, lors de la prochaine propagation, son historique est enregistré (comme ayant été créé à partir de truc). svn copy ne crée pas de répertoires intermédiaires, à moins que vous ne lui passiez l'option --parents.
  • svn move truc bidule
    Cette commande équivaut exactement à svn copy truc bidule; svn delete truc. C'est-à-dire que bidule est marqué pour ajout en tant que copie de truc et que truc est marqué pour suppression. svn move ne crée pas de répertoires intermédiaires, à moins que vous ne lui passiez l'option --parents.
  • svn mkdir blort
    Cette commande équivaut exactement à mkdir blort; svn add blort. C'est-à-dire qu'un nouveau répertoire nommé blort est créé et marqué pour ajout

3.5 Avoir une vue d'ensemble des changements effectués

Pour avoir une vue d'ensemble des changements que vous avez effectués, utilisez la commande svn status. C'est certainement la commande que vous utiliserez le plus. Si vous lancez svn status sans argument à la racine de votre copie de travail, Subversion détecte toutes les modifications effectuées sur les fichiers et sur l'arborescence.

3.6 Voir en détail les modifications que vous avez effectuées

La commande svn diff offre une autre façon d'examiner vos changements. Vous pouvez retrouver exactement ce que vous avez modifié en lançant la commande svn diff sans argument : elle affiche les changements au format diff unifié.

3.7 Annuler des changements sur la copie de travail

Supposons qu'en examinant la sortie de svn diff, vous vous rendiez compte que tous les changements effectués sur un fichier donné sont erronés. Peut-être auriez-vous dû laisser le fichier tel quel, ou bien peut-être qu'il serait plus facile de reprendre les changements depuis le début. C'est l'occasion idéale pour utiliser svn revert :

svn revert classe.cpp

3.8 Propager vos modifications

Attention : penser à faire un svn update avant tout svn commit pour régler les éventuels problèmes apparus si quelqu'un à envoyer des fichiers entre temps sur le dépôt distant.

Enfin ! Vos modifications sont terminées, vous les avez fusionnées avec celles du serveur et vous êtes prêt à les propager vers le dépôt. La commande svn commit envoie vos changements au dépôt. Quand vous propagez un changement, vous devez l'accompagner d'un message de log qui décrit ce changement. Votre message est associé à la nouvelle révision que vous créez. Si votre message est bref, vous pouvez le passer en ligne de commande en utilisant l'option -m. Tous messages de log doivent être rédigés en anglais.

svn commit -m "Bug fix for the class xxx."

3.9 Résoudre les conflits

Dans 90% des cas, un svn update suivi d'un svn commit se déroulera sans soucis. Cependant, si une modification d'un fichier a été réalisée en même temps que vous étiez en train de le modifier, un conflit va apparaître et c'est à vous de le corriger avant de pouvoir soumettre vos modifications. La résolution des conflits est quelque chose d'assez compliquée et qui est constituée de nombreux cas différents, c'est pourquoi je vous conseille de vous reporter à la documentation de Subversion dans ce cas ou de poser la question à l'un des responsables du projet.

4. Administration

L'administration décrite dans cette partie est réservée aux membres expérimentés de ce projet et ne doit pas être faite avant accord d'au moins deux personnes parmi les responsables : yan, dourouc05, johnlamericain, qui d'autre ?

4.1 Création d'une branche

La création d'une branche n'est rien d'autre que la copie d'une partie du dépôt. La notion de branches et de tags n'est pas connue de Subversion. La création de la branche de développement se fait de la manière suivante :

svn copy http://subversion.developpez.com/projets/qextend/trunk \
        http://subversion.developpez.com/projets/qextend/branches/dev \
    -m "Creating a dev branch of /trunk."

4.2 Garder la branche synchronisée

Pour que la branche reste synchronisée avec le /trunk dans le cas de modification directe de celle-ci, il est nécessaire d'utiliser la commande svn merge à partir du répertoire de la branche en question (/branches/dev) :

svn merge http://subversion.developpez.com/projets/qextend/trunk

4.2 Réintégrer la branche

Une fois qu'une version stable est obtenue sur la branche de développement, il est nécessaire de la réintégrer sur le /trunk. Voici les différentes étapes à partir du répertoire correspondant au trunk :

svn update    # Pour être sûr que votre branche est bien à jour

svn merge --reintegrate http://subversion.developpez.com/projets/qextend/branches/dev

# compiler, tester, vérifier...

svn commit -m "Merge my dev branch back into trunk!" 

Une fois réintégré, il faut resynchroniser la branche. Pour cela, retourner dans le répertoire de la branche :


svn update    # Pour être sûr que votre branche est bien à jour

svn merge --record-only http://subversion.developpez.com/projets/qextend/trunk

# compiler, tester, vérifier...

svn commit -m "Keep alive dev branche!" 

Si c'est une branche personnelle, vous pouvez la supprimer avec la commande svn delete :

svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
    -m "Remove my dev branch."