Bloc-Notes sur Subversion

Organisation \"typique\" d'un dépôt

'organisation d'un dépôt est affaire de besoin et doit être bien pensée dés le début même si tout peut être changé, ou presque, par la suite.

Dépôt unique ou dépots multiples

La première question à se poser est "un ou plusieurs dépôts". En effet, si nous avons deux projets à versionné, il n'est pas idiot de se dire que l'on va créer deux dépôts avec chacun leur URL. Mais il est aussi possible de créer deux dossiers dans le même dépôt et de gérer ces deux dossiers de manière indépendante. Ce qu'il faut prendre en compte dans son choix à ce stade, c'est :

• Un compteur de révision par dépôt. Cela veut dire que si deux projets sont sur le même dépôt, chaque commit d'un côté fera augmenter le compteur de révision de l'autre côté. Pour moi la révision est comme un numéro de série, pas une version, donc je ne trouve pas cela gênant. Mais pour les anciens de CVS cela peut être perturbant de commiter il y a 6 mois une révision 10, et lors d'un nouveau commit, six mois plus tard, de se retrouver à la révision 4512 parce qu'entre temps, les autres projets ont vécu. Donc chacun ses goûts à ce stade.

• Un dépôt = plus de fluidité. En effet, lorsqu'une sous branche d'un projet devient bien dense et que l'on veut la transformer en projet indépendant, il suffit de faire un simple MOVE dans un nouveau dossier pour lui-donner son nouveau statut en conservant en prime tout l'historique.
• Plusieurs dépots = moins d'espace. Un argument pour le multi-dépôts est qu'il sépare les espaces disques. En effets, si le projet A meurt une fois pour toute, supprimer son dépot libère de l'espace disque. Car il ne faut pas oublier que pour subversion, le mot supprimer n'existe pas.

En conclusion, au delà du numéro de révision, le critère de choix est "est-ce que mes projets vont se mélanger les uns les autres". Si je suis une SSII, c'est rarement le cas, je vais créer un dépôt par client/projet car il est rare que le sous-projet du client A se retrouve un jour projet du client B (et encore . Si je suis une organisation type "Apache" ou "KDE", mes projets sont tous plus où moins liés, j'ai donc tout interêt à ne faire qu'un seul dépôt.

Organisation des dossiers par projet

Un dépôt peut contenir autant de sous-dossier que désiré jusqu'à arriver à celui d'un projet. Subversion permettant de gérer les droits de manière fine sur chacun des dossiers. Nous pouvons donc avoir une structure adapté à nos besoins du type :

En revanche, arrivé au niveau du projet lui-même il convient de normaliser le premier niveau de dossiers comme suit :

Les sous-dossiers trunk, branches et tags vont permettre de s'y retrouver quant à l'étiquetage des versions. Le premier niveau mon application n'est donc en réalité jamais chekouté. Seuls les dossiers fineaux monApplication le seront. Le trunk correspond à la version courrant de développement (head en CVS), branches contient des sous dossiers correspondant aux branches (expérimentales ou pas) et tags aux versions release. Dans les deux derniers cas le niveau en dessous est un dossier nommé pour s'y retrouver (ex. Version 1.1) et en dessous nous retrouvons le dossier de l'application elle-même.

Commandes de base

Import initial d'un dossier (et de son contenu) dans SubVersion

Ensuite tout marche comme un système de fichier classique

Etat de la copie locale

Pour s'assurer que tout est en ordre, ou pour avoir la liste des fichiers ajoutés et modifiés, la commande suivante est bien utile :

Liste des commentaires de révision

Modification des méta-données

Une des nouveauté de subversion est la possibilité de stocker des méta données au niveau des répertoires. Cela peut servir à renseigner la liste des dossiers/fichiers invisibles, à définir la liste des références externes, etc...

éditeur externe

Pour éditer les propriétés, nous allons avoir besoin d'un éditeur externe. Cela peut-être n'importe quelle application capable d'éditer du texte de la manière qui vous convient :

Les commandes de gestion des propriétés

Déclarer un dossier comme ignoré

La propriété responsable du fait d'ignorer un fichier, un dossier, un ensemble, etc, est svn:ignore. Il suffit donc d'éditer cette propriété pour ajouter une régle par ligne contenant le nom d'un fichier, d'un dossier, ou un "pattern" du type *.bak.

Charger des sous-projets externes

Une des possibilités très utile de SubVersion est de pouvoir "monter" dans l'arborescence d'un projet des branches (au sens système de fichier du terme) provenant d'autre dépôts. Cela se fait très simplement par la commande d'édition de propriétés. Par exemple, imaginons que dans un dossier monProjet, nous cherchions à grêffer le projet moduleAmi.

Pour ajouter une référence, il faut éditeur la propriété svn:externals du dossier où lm'on désire établir la greffe. Ensuite nous ajoutons la référence comme suit :

Il prut y avoir autant de ligne de référence que désiré. Une la propriété fois sauvé, il suffit de faire une mise à jour du dossier monProjet (svn co) pour mettre à jour ou, si le dossier externe n'existe pas encore, checkouter le dossier greffé automatiquement.

De manière général, une mise à jour (svn up) à la racine, entraîne une mise à jour des dossiers externes. En revanche, les commits (svn co), eux, ne franchissent pas les "barrières" des externals. Pour commiter une version d'un sous-dossier externe, il font explicitement commiter celui si.

Astuces diverses

Revenir en arrière sur une action (avant commit)

Commiter un dossier complet

Obtenir l'url d'une copie de travail

Changer l'url d'un espace de travail

Il arrive parfois que l'URL de base d'un dépôt doive être changé.

Par exemple impaginons que votre copie locale de monProjet ait été obtenue par :

Or, l'url de base a changé entre temps, et n'est aujourd'hui plus http://svn.masociete.com/depots mais http://intranet.masociete.com/subversion. Vous avez alors deux solutions, la plus "simple" consiste à détruire votre copie locale et à refaire un checkout. C'est jouable si vous n'avez aucune modification en cours sinon vous perdez tous vos ajouts...

La "vraie" solution consiste quant à elle à relocaliser votre copie locale vers le nouveau dépôt. Pour cela, allez dans le dossier racine de votre projet et tapez la commande suivante :

Notez bien que seule l'url de base est utilisée, par le nom du projet. Ceci fait, vous pouvez à nouveau commiter vos modifications.

Annuler le dernier commit

Grosse cata, vous avez commité des horreurs et pour votre malheur, la règle absolue de subversion est de ne rien effacer. Pas de panique, voici la marche à suivre.

Imaginons que vous ayez commité des erreurs dans la revision 666 et que vous vouliez revenir à la révision 665. L'astuce est de fusionner la revision 665 sur la 666 et de commiter l'ensemble en 667 qui sera donc un nouveau 666. Pour cela, placez-vous dans votre dossier à restaurer :

Résolution de problèmes

Erreur \"502 Bad Gateway\"

Si vous avez droit un jour à un svn: COPY of package.sh: 502 Bad Gateway (https://mondomaine.subversion.com/dev), il est probable que vous ayez tenté une copie/déplacement à travers un accès HTTPS au dépôt subversion. Hors dans le cas du https, un cas qui pose problème, celle de l'utilisation de reverse proxy sur le serveur cible (La cible est une machine apache A qui est accédé via HTTPS et qui relaye les requêtes sur une machine apache B qui gère le dépôt), ou alors de mauvais définition du nom de serveur au niveau de la cible (le servername du vhost est mal configuré). Bref, pas beaucoup de solution là dessus, juste de ne pas le faire Cela ne pose problème que sur les commande COPY et MOVE, assez rare donc. Dans ces deux cas, préférer un accès plus proche du serveur de dépôt en HTTP ou en SVN.

Commentaires