gleu's blog - Tag - svn

Subversion, Pratique du développement collaboratif avec SVN

Guillaume Lelarge — Mon, 08 May 2006 17:43:07 +0000

À la dernière bouffe de traduc.org, Balise m'avait passé sa dernière oeuvre dont je viens de finir la lecture.

C'est un très bon livre, très bien adapté par Balise. C'est clairement tourné vers les débutants mais ça fait du bien de revoir les bases. J'ai bien aimé le coup des branches expérimentales, ça va me servir très rapidement. J'ai aussi découvert SVN::Notify que j'installe demain au boulot (un exemple de ce que génère ce script).

Chuis con, j'aurais dû demander un autographe quand elle me l'a passé

SVN move et nettoyage de scripts

Guillaume Lelarge — Mon, 01 May 2006 18:22:47 +0000

Maintenant que j'arrive à générer un HTML et un PDF magnifiques (oui, oui, je me la pète ), je suis en train de nettoyer scripts et feuilles de style pour tout commiter sur le dépôt SVN.

J'ai commencé par renommer tous les fichiers SGML en XML :

find . -name "*.sgml" | while read fichier
do
  svn move ${fichier} ${fichier/sgml/xml}
done

Ensuite, j'ai corrigé le Makefile et les feuilles de style pour remplacer les LFS par des PG, histoire d'être cohérent. J'ai eu un petit soucis avec le Makefile. Je voulais qu'il crée les répertoires et les fichiers de tel façon que je n'ai plus qu'à les copier sur le serveur. Donc, il me fallait ajouter le numéro de version sur la variable contenant le répertoire de construction. La version se trouve dans le fichier version.xml. En shell, c'est très simple car il suffit de cette ligne :

BASEDIR=~/pgsql-`grep -v major version.xml | cut -c19-23`-fr

Dans un Makefile, cette commande ne fonctionne pas. En effet, il n'exécute pas la commande grep -v .... Il l'exécute quand il utilise la variable, plus exactement quand il exécute l'instruction qui utilise cette variable, ce qui peut poser quelques soucis (par exemple quand cette variable se trouve déjà des guillemets inversés). Bref, en parcourant le manuel de make, j'ai fini par découvrir qu'on pouvait exécuter une commande shell et récupérer le résultat dans une variable (y compris si ce résultat comprend plusieurs lignes) :

BASEDIR := $(shell echo "~/pgsql-`grep -v major version.xml | cut -c19-23`-fr")

Voilà. Tout con mais il fallait le savoir.

Bref, maintenant, mes scripts fonctionnent avec les feuilles de style associées. Il faudra rajouter la feuille de style CSS de Kryskool quand il l'aura terminé. En attendant je commit... et j'obtiens la révision 232.

BLFS : stats fausses, début de mise à jour décourageant...

Guillaume Lelarge — Sun, 05 Jun 2005 10:53:49 +0000

... bref, pas cool du tout.

Commençons par les stats. Quand je commençais une mise à jour du livre BLFS, j'avais pour habitude de récupérer une archive tar contenant les sources XML du livre. Cela ne fut pas le cas cette fois-ci. Une archive tar existe bien, mais uniquement pour les versions testing et unstable (oui, ça fonctionne un peu comme Debian maintenant). Du coup, j'ai dû récupérer les sources du serveur subversion avec la jolie commande suivante :

svn co svn://svn.linuxfromscratch.org/BLFS/branches/6.0/BOOK

C'est ainsi que j'ai pu faire mes stats. Un petit script ridicule, du style :

for rep in *
do
  if test -d "$rep"
  then
    nb=`find $rep -type f | wc -l`
    echo "$nb $rep"
  fi
done | sort -n

Et voilà... hop. Tranquillou, le garçon. Et ensuite, il se la pète en faisant un joli graphique avec KSpread pendant qu'il chatte avec une copine. Super, bien joué ! Bon, j'ai un peu oublié que subversion devait planquer des infos dans des fichiers, un peu à la manière de CVS avec son répertoire justement nommé CVS. Subversion est plus retors mais plus prudent aussi. Il dispose d'un répertoire .svn bourré de fichiers.

Bref, tout ça pour dire que le nombre de fichiers est bien supérieur à la réalité. Ce qui, en soi, et surtout sans trop réfléchir, est une bonne nouvelle...

Pourquoi « sans trop réfléchir » ? Tout simplement parce que les contributeurs de BLFS ont plutôt une tendance assez lourde à l'ajout de fichiers, pas à la suppression... en tout cas pas autant. Je me demandais donc ce qu'il s'était passé jusqu'à ce que je commence le travail de mise à jour samedi matin. Je n'ai pas attendu trop longtemps pour avoir ma réponse.

Au départ, un programme avait son propre répertoire, celui-ci comprenant cinq fichiers : package-config.xml (configuration du paquetage), package-desc.xml (description), package-exp.xml (explication), package-inst.xml (installation), package-intro.xml (introduction), package.ent (entités XML). Maintenant, tout est regroupé dans un seul fichier. Je comprends parfaitement bien l'idée derrière tout ça mais ça m'emmerde profondément. Oui, je sais, ce n'est pas beau, c'est grossier, toussa. Il faut bien se rendre compte que cela veut dire que je peux oublier mes outils de visualisation des différences (comme Kompare) et que je peux tout re-traduire.

J'aime beaucoup traduire, je déteste traduire ce que j'ai déjà traduit, une furieuse impression de déjà-vu, de perte d'un travail assez conséquent. Ça ne me plaît pas du tout. C'est très décourageant. Du coup, j'ai décidé d'y aller tranquillement, sans forcer la marche. Je conserve mon heure de traduction du matin et point barre. Le soir, c'est totalement repos. Pas de traduction. Comme ça, je vais pouvoir me remettre à des activités qui me plaisaient beaucoup : de la programmation, de l'apprentissage, peut-être un nouveau projet (ce ne sont pas les idées qui manquent... traduire/écrire pour wikipedia par exemple).