/tmp % vcs-svn --version
help (?, h): Describe the usage of this program or its subcommands.
usage: help [SUBCOMMAND...]
Valid options:
--version : print client version info
-q [--quiet] : print as little as possible
--config-dir arg : read user configuration files from directory ARG
>>>>> "Nicolas" == Nicolas Pouillard <nicolas.pouillard(a)gmail.com> writes:
Nicolas> On 1/26/06, Roland Levillain <roland(a)lrde.epita.fr> wrote:
>> >>>>> "Nicolas" == Nicolas Pouillard <nicolas.pouillard(a)gmail.com>
>> writes:
Nicolas> Soit dit en passant il faut toujours que l'on fasse cette
Nicolas> presentation d'Uttk ce qui permettra de mettre les choses au
Nicolas> claire dans la tête de tout le monde.
>> Je suis preneur ! (Je ne pense pas être le seul). Est-ce que vous
>> avez du temps pour ça ?
Nicolas> Pas tout de suite mais dans un mois par exemple, genre un
Nicolas> mercredi disons le 22 fevrier si cela vous arrange. Mais cela
Nicolas> dépend peut être de vos contraintes si le choix des
Nicolas> technologies doit être absolument fait plus tôt ou pas ?
Le 22/2 me semble une bonne date. Mises à part les réunions usuelles,
le calendrier indique qu'il y a une réunion Transformers de 14h à
16h. Est-ce que tu auras/vous aurez un créneau compatible avec cet
emploi du temps ?
Au passage, si vous pouviez présenter (même rapidement) Vcs aux
nouveaux, ce serait super !
>>>>> "Nicolas" == Nicolas Pouillard <nicolas.pouillard(a)gmail.com> writes:
Nicolas> Je pense qu'il faudrait que vous exposier ici vos besoins en
Nicolas> terme de tests de maniere a ce que l'on puisse mieux répondre
Nicolas> a vos attentes.
Il faudrait que je fasse la liste des services proposés par
l'infrastructure de tests d'Olena + ceux qu'on voudrait.
Nicolas> Soit dit en passant il faut toujours que l'on fasse cette
Nicolas> presentation d'Uttk ce qui permettra de mettre les choses au
Nicolas> claire dans la tête de tout le monde.
Je suis preneur ! (Je ne pense pas être le seul). Est-ce que vous avez
du temps pour ça ?
(Je crossposte dans lrde.proj pour que toutes les gens intéressées
fassent connaître leur opinion.)
Ce serait pas mal de faire croître la test suite en même temps que le
code d'Olena 1.0, en particulier pour tout le code template de Metalic
que l'on ne peut véritablement vérifier qu'en l'instanciant.
Personnellement, je ne suis pas très chaud pour conserver ce qui
existe actuellement dans le proto 1.0. À l'usage, je ne trouve pas ça
très pratique à utiliser (il est difficile de lancer un seul test, on
ne peut pas garder de traces d'un test qui réussit, etc.).
Donc, que choisit-on comme outil/cadre de test pour Olena 1.0 ? Les
propositions incluent :
1. garder le mécanisme actuel du proto 1.0 (càd, celui d'Olena 0.10) ;
2. se baser uniquement sur les services proposés par Automake ;
3. passer à un outil tiers comme DejaGnu, Autotest ou Uttk.
La troisième proposition me tente bien, mais je ne connaît aucun des
projets cités...
(Au passage, est-ce que ce genre de questions a sa place dans
lrde.olena.core, ou bien plutôt dans lrde.olena ?)
>>>>> "Nicolas" == Nicolas Pouillard <nicolas.pouillard(a)gmail.com> writes:
Nicolas> On 1/19/06, Roland Levillain <roland(a)lrde.epita.fr> wrote:
>> * existe-t-il une commande Vcs pour supprimer les
>> fichiers-supports de Vcs (`,log', `,form', `,iform', `,message') ?
Nicolas> Ya junk mais il retire tous les ,* en te posant la question
Nicolas> avant.
Nickel, merci !
Cependant, `help' ne le documente pas :
brasilia ~/src/tc % vcs-svn help junk
"junk": unknown command.
>> * Vcs n'honore pas complètement les noms de fichiers passés en
>> argument à la commande `commit' ; en effet, le diff présent dans
>> ,form se fait récursivement sur `.', et non sur ces fichiers. (Je
>> n'ai pas testé si le commit effectif ne s'applique qu'à ces
>> fichiers.) Exemple : si j'ai modifié foo.cc, bar.cc et baz.cc dans
>> ma copie de travail, et que j'invoque
>>
>> vcs-svn commit foo.cc bar.cc
>>
>> le fichier ,form qui apparaîtra dans mon éditeur fera mention des
>> changements sur baz.cc (ChangeLog + diff). C'est pas cool !
>>
Nicolas> Oui en effet mais cela doit etre coriger désormais.
Ok, c'est cool.
>> * dans la version de Vcs actuellement présente dans RubyGems
>> (0.4.1), le numéro de version est incorrect :
>>
>> brasilia ~ % grep version
>> /usr/lib/ruby/gems/1.8/gems/vcs-0.4.1/lib/vcs/vcs.rb\ | head -1
>> @@version ||= '0.4.0'
Nicolas> Et oui il me manque du temps pour releaser une nouvelle
Nicolas> version qui serait pourtant prete sur bcp de points.
Nicolas> J'ai tout de meme placer sur
Nicolas> http://www.lrde.epita.fr/~pouill_n/vcs les gem necessaires a
Nicolas> l'installation de la version beta.
Hé, je ne veux surtout pas t'embêter avec tout ça ! Je peux tout à
fait attendre la sortie de Vcs 0.5.0. :)
Je voulais juste dire que le numéro de version du répertoire de Vcs
dans RubyGems (/usr/lib/ruby/gems/1.8/gems/vcs-0.4.1) ne correspondait
pas avec celui que Vcs affiche (0.4.0).
>> * enfin (je sais que Noël est passé, mais je remets sur ma liste de
>> cadeaux cette fonctionnalité que je chéris) : Vcs pourrait-il
>> prendre en compte un ChangeLog écrit par l'utilisateur avant le
>> commit ?
Nicolas> Ca le fera un jour mais quand ?
Je le mets sur ma liste de Noël 2006 alors. :)
Je commence à utiliser Vcs de plus en plus, et j'apprécie le temps
qu'il me fait gagner. Cependant, j'ai quelques
questions/remarques/critiques à son sujet :
* existe-t-il une commande Vcs pour supprimer les fichiers-supports de Vcs
(`,log', `,form', `,iform', `,message') ?
* Vcs n'honore pas complètement les noms de fichiers passés en
argument à la commande `commit' ; en effet, le diff présent dans
,form se fait récursivement sur `.', et non sur ces fichiers. (Je
n'ai pas testé si le commit effectif ne s'applique qu'à ces
fichiers.)
Exemple : si j'ai modifié foo.cc, bar.cc et baz.cc dans ma copie de
travail, et que j'invoque
vcs-svn commit foo.cc bar.cc
le fichier ,form qui apparaîtra dans mon éditeur fera mention des
changements sur baz.cc (ChangeLog + diff). C'est pas cool !
* dans la version de Vcs actuellement présente dans RubyGems (0.4.1),
le numéro de version est incorrect :
brasilia ~ % grep version /usr/lib/ruby/gems/1.8/gems/vcs-0.4.1/lib/vcs/vcs.rb\
| head -1
@@version ||= '0.4.0'
* enfin (je sais que Noël est passé, mais je remets sur ma liste de
cadeaux cette fonctionnalité que je chéris) : Vcs pourrait-il
prendre en compte un ChangeLog écrit par l'utilisateur avant le
commit ?
En tout cas, bravo et merci pour Vcs, c'est un outil très pratique !