Le principe d'une faq est d'ajouter les questions aussi bien que les réponses... le but est que les questions soient posées une fois et répondues une seule fois également, donc n'hésitez pas à inscrire la question ici, avant d'appeller à l'aide pour la réponse.

J'ai développé un truc, je le mets dans vlm ou dans vlmtools ?

En cas de doute, le mettre dans vlmtools. Le but de vlmtools est d'être un incubateur d'idées, de développements, finalisés ou pas.

Si ce qui est développé est utile et doit être intégré dans vlm à terme, il sera toujours temps de le déplacer.

Donc, dès lors que vous avez accès à subversion, ne vous posez pas de question, publiez le code dans vlmtools.

Il y a une arborescence spéciale à respecter dans vlmtools ?

par convention, un projet stocké dans un dépôt subversion possède 3 répertoires :

• le trunk, qui contient la version "courante", celle de travail
• le branches qui contient les versions stables ou maintenues (par exemple branches/version_1_0/)
• le tags, qui sert uniquement à faire des "photos" d'une branche ou du trunk.

La création des photos (pour créer une branche ou tagguer une version) se fait avec la commande svn copy

C'est quoi la différence entre Milestone et Version ?

Un milestone ?

Transition, Community powered, Team New Code, Take five, Have Foehn, etc... sont des "Milestones", en français des jalons, des points de passage ou point d'étapes.

C'est différent d'une version pour plusieurs raison :

• un version est (souvent) normée (1.2.3), un milestones est la plupart du temps une chaine de texte
• il peut y avoir plusieurs milestones entre 2 versions et réciproquement (je sens que je suis en train d'obscurcir le sujet).
• la date d'une version est mis à posteriori (quand la version sort), la date d'un milestone est mis à priori (la cible qu'on veut atteindre).
• dit autrement, le milestone c'est un outil de pilotage des tâches ;)

Bref, le nom d'une milestone est souvent plus poétique / plus chargé de sens (ou dénué de sens) qu'une version.

A quoi ça sert ?

Beaucoup de projet font une "identité" entre version et milestones, pour se simplifier la vie. C'est ce que fait Vlm.

Sur VLM, l'idée est de publier de nouvelles versions souvent, donc les 3 premiers "jalons" correspondaient à :

• Transition, qui contenait essentiellement les bugs sur l'hébergement de base du serveur. (à peu près associé à la version actuelle de Vlm)
• Community Powered pour une première version commune, placée pour la fin décembre (dont le contenu textuel correspond à ton mail de l'autre jour)
• Team New Code, juste un jalon créé pour voir en mettant une date 'd'échéance' (hé, ho! on va pas se fouetter non plus) dans 3 mois.

Nous aurions pu mettre des noms café croissants ou les noms des cap horniers du siècle dernier, c'était pareil :)

Règle d'usage sur VLM

* identité entre milestone et version : la 0.12 correspond au milestone Take Five, etc... * la version dans un ticket est la plupart du temps la version courante, celle sur laquelle on a détecté le bug * le milestone est le moment ou on souhaite avoir corrigé le ticket. Dans la pratique, comme on est idéaliste, il s'agit du prochain milestone...

Comment le changer ?

Tout ça ce change dans Admin / Milestones, pour ceux qui sont habilité.

Ca correspond à quoi ces "différents tableaux" de l'état 6 ?

Au détails des bugs ouverts et fermés pour chaque jalon (milestones)

Copie de travail verrouillée

Si vous rencontrez le pb suivant :

svn: La copie de travail '/data/www/vlm/trunk/site' est verrouillée

svn : lancer 'svn cleanup' pour enlever les verrous (cf 'svn help

cleanup')

mettez vous dans trunk ou même à la racine du subversion et executez svn cleanup trunk