Mot-clé - subversion

Fil des billets - Fil des commentaires

vendredi 13 mai 2011

Contribuer à un logiciel libre

Il y a de nombreuses manières pour contribuer à un logiciel libre. Et contrairement à ce que de nombreuses personnes pourraient penser, il n'y a pas besoin d'être développeur ! Par exemple, utiliser le logiciel et juste signifier qu'on l'utilise est déjà une forme de contribution. Cela le rend plus populaire !

Il y a bien sûr plein d'autres manières de contribuer...

Lire la suite ...

Dimanche 16 mars 2008

Emmener son code en voyage

Lorsque je développe sur un projet, j'utilise subversion et je fais souvent des "commit" pour éviter de garder dans mon répertoire de travail du code modifié et non propagé sur le serveur. Tout va bien lorsqu'on est connecté au serveur central mais si on est dans le train, à la campagne, dans un avion, ou dans les toilettes, cela devient plus problématique.

Lire la suite ...

jeudi 4 octobre 2007

Utilisation d'une source externe avec subversion

Lorsqu'on utilise subversion pour gérer ses sources de code, on peut être amené à utiliser des sources externes qui elles aussi peuvent être amenées à évoluer. Ces sources externes sont elles aussi bien entendu gérer par subversion. Pour ne pas aller vérifier régulièrement qu'une nouvelle version est disponible, une solution existe : svn:externals.

Pour ajouter une source externe, dans un projet, il suffit d'utiliser la propriété externals. On place dans un fichier (que l'on nommera par exemple svn-externals) les liens vers la ou les source(s) externe(s) et le tour est joué.

Exemple: contenu de mon fichier svn-externals :

nom_local svn+ssh://login@hostname.tld/svn/root/to/source_externe

source_externe est le nom du répertoire de la librairie externe que je veux utiliser.

Pour que cette source soit prise en compte il suffit de taper les commandes suivantes:

svn propset svn:ignore svn:externals .

svn propset svn:externals -F svn-externals .

La première commande permet d'ignorer le fichier svn-externals. La deuxième ajoute la proprièté svn:externals. Il ne reste plus qu'à faire le commit et après on peut faire update et la source externe est récupérée.

mercredi 18 avril 2007

Récupérer un fichier effacé

Le but du "jeu" est de récupérer un fichier sauvegardé dans subversion - que l'on appellera par exemple mon-fichier.php - , que l'on a effacé à une révision donnée. Ce n'est pas aussi simple qu'il n'y parait mais ça reste très abordable. Le plus compliqué est de retrouver à quel moment où il a été éffacé. Pour ce faire on utilise la commande log en mode verbeux: (à coup de grep au besoin.
svn log -v

On se retrouve avec une révision N où le fichier a été supprimé. Donc à la révision précédente, N-1, le fichier était présent. C'est ce fichier que l'on veut récupérer. Il suffit alors de faire:
svn -rN-1 copy http://localhost/svn/PROJET/path/2/file/mon-fichier.php path/2/file/mon-fichier.php

samedi 29 avril 2006

Gestion de plusieurs projets avec trac

Pour ajouter un projet dans trac, voici la marche à suivre:

  1. trac-admin /path/to/projetenv initenv (répertoire où sont placés les pages du wiki entre autre)

    Il faut ensuite choisir un nom pour le projet ainsi que le chemin vers le dépôt subversion

    Exemple: trac-admin /var/trac/projets/essai (le dépôt subverison correspondant est: /home/nicolas/projets/essai)

  2. Modifier la conf d'apache

    Alias /trac /usr/share/trac/htdocs/
    
    AliasMatch /projets/(projet1|projet2|projet3|projet4)(/?.*) /var/trac/projets/$1/trac.cgi$2
    
    <DirectoryMatch "/var/trac/projets/projet1/trac.cgi">
            SetEnv TRAC_ENV "/var/trac/projets/projet1"
            AllowOverride None
            Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
            AddHandler cgi-script .cgi
            Order allow,deny
            Allow from all
    </DirectoryMatch>
    
    <DirectoryMatch "/var/trac/projets/projet2/trac.cgi">
            SetEnv TRAC_ENV "/var/trac/projets/projet2"
            AllowOverride None
            Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
            AddHandler cgi-script .cgi
            Order allow,deny
            Allow from all
    </DirectoryMatch>
    
    <DirectoryMatch "/var/trac/projets/projet3/trac.cgi">
            SetEnv TRAC_ENV "/var/trac/projets/projet3"
            AllowOverride None
            Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
            AddHandler cgi-script .cgi
            Order allow,deny
            Allow from all
    </DirectoryMatch>
    
    <DirectoryMatch "/var/trac/projets/projet4/trac.cgi">
            SetEnv TRAC_ENV "/var/trac/projets/projet4"
            AllowOverride None
            Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
            AddHandler cgi-script .cgi
            Order allow,deny
            Allow from all
    </DirectoryMatch>
    

La configuration d'apache n'est pas optimale. On devrait pouvoir l'améliorer en factorisant les différents DirectoryMatch. De plus on utilise les mêmes fichiers de mots de passe pour tous les projets; on devrait pouvoir les séparer.

vendredi 24 mars 2006

Revenir à une version antérieure avec subversion

Cela fait un moment que je travaille sur le même projet en faisant des branches, des tags... Je fais des "commit" réguliers. Et tout à coup, arrivant à la révision 2347 je me suis apperçu que j'avais introduit, par mégarde, un nouveau bug qui n'était pas présent à la révision 2346.

La question qui est sur toutes les lèvres: comment revenir facilement à la révision précédente ? Et bien rien de plus simple, il suffit de taper la commande suivante:

svn merge -r2347:2346 URL .

Deux remarques:

  • c'est bien la commande merge qu'il faut utiliser; c'est clairement écrit dans la documentation.
  • je ne me suis pas trompé; les numéros de révisions sont dans l'ordre décroissant contrairement à un merge "classique". Mais en y réfléchissant bien, c'est logique, on veut bien passer de la révision 2347 à la révision 2346

Il ne reste plus qu'à faire un commit.

mercredi 22 mars 2006

Gestion des sources

Que l'on travaille seul ou à plusieurs sur un projet, le besoin se fait rapidement sentir de pouvoir garder un historique des modifications que l'on a faites. La méthode, qui consiste à commenter une partie du code pour éventuellement la réutiliser, atteint rapidement ses limites lorsqu'on travaille à plusieurs ou longtemps sur un même projet. En ayant pratiqué cette méthode je me suis retrouvé à un moment avec plus de commentaire que de code!

Pour un projet qui dure ou pour un projet collaboratif, la meilleure façon de travailler est d'utiliser un gestionnaire de versions tel que C.V.S ou Subversion. Ma préférence va à Subversion surtout couplé avec Trac qui est une interface web à Subversion pour parcourir les sources. Trac intègre aussi un wiki, un gestionnaire de bugs, de tickets.

Pour débuter avec Subersion, rien ne vaut la lecture de la documentation, sous licence Creative Commons, publiée par Oreilly.

Haut de la page