On 10/4/05, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
On 10/4/05, Nicolas Desprès <nicolas.despres@gmail.com> wrote:
On 10/3/05, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
Hi, you can now update your vcs (as root):
gem update --system gem install vcs -y --no-rdoc
New in 0.4:
Pourquoir est-ce que je ne suis plus en mode ChangeLog dans mon emacs quand je dois remplir le dit ChangeLog ?
Puisque ce n'est plus directement un ChangeLog mais une version simplifier, en effet le ChangeLog est genere a partir de cette entree. (astuce tu peux confer ton emacs de maniere a avoir une autre coloration soit celle du diff, soit du yaml)
C'est donc du travail supplémentaire qui m'incombe alors que j'ai téléchargé la dernière version pour avoir moins de bugs et me rendre la vie plus simple... Mais passons, c'est pas comme si la limite des 80 colonnes correspondait désormais à avant la frontière de mon emacs.
Pourquoi suis-je obligé de me faire un .vcs pour pouvoir commiter alors que j'ai juste trois pauvre fichiers de log généré par mon programme à chaque exécution qui m'en empeche ? Depuis quand est-il dangereux d'avoir des fichiers non versionné dans sa working copy ? Les autotools en génère pourtant à la pelle !
Cf discussion avec akim les fichiers non versionné sont la cause de la plus part des patches foireux. Donc si ya des fichiers generes tu les excludes ou les unmask et pour ta TODO tu la met en precieux
En effet, ils en sont souvent la cause, mais ils y a également d'autre méthodes. Par exemple émettre un warning la première fois. Et puis la deuxième fois ca passe si le mec insiste. Avoir une option qui force. Le coup de precious ca va finir chez beaucoup de gens en: precious: - !re: .*
* Status & User Configuration File: All .vcs files between your current path and root will be honored. Example of configuration file. >>>> ~/.vcs <<<< --- exclude: # Excluded Files: - !re ,messages # not displayed (default ^-.*$)
unmask: # Unmasked Files: - !re \bdoc # displayed with a `\' (default ^\\.*$)
precious: # Precious Files: - !re .*\.(diff|patch)$ # displayed with a `+' (default ^\+.*$) # .vcs files are also treat as precious
junk: # Junk Files: - !re ... # displayed with a `,' (default ^,.*$)
>>>> ~/.vcsrc <<<<
C'est bien d'avoir un fichier de conf mais il ne devrait pas être obligatoire d'avoir à en écrire un pour pouvoir commiter et là c'est obligatoire dés qu'on a un pauvre fichier myTODO ou des fichiers de logs ou des Makefile.in, etc...
Il n'est pas obligatoire si tu regarde bien. tu peux aussi renomer tes fichiers mv myTODO +myTODO et voila il est precieux et plus ?
Moi je ne comprend pas pourquoi ce genre de comportements marginaux sont activé par défaut (c'est comme l'option gnupg en son temps). Moi j'aimais bien vcs car je pouvais rajouter des sous commande à svn. Maintenant les commandes par défaut sont surchargé et je ne reconnais plus mon svn. De plus maintenant je dois faire confiance à svn *et* à vcs par rapport aux résultats recueillit. Si un bug arrive dans l'un ou dans l'autre, je ne peux plus commiter et donc plus travailler. Sinon, je dois désinstaller vcs et du coup c'est encore moi qui bosse au profit d'une nouvelle version qui devait me rendre la vie plus simple, plus belle, etc...
* Color: - Status: the status output is now colored depending of the meaning of the status. The color activation can be choose in your configuration file (auto, never, always). - Logger: messages displayed by the Vcs logger are new colored. cyan (info), yellow (warnings), red (errors), blinking red (fatal).
C'est mignon.
D'ou le surnom donné a cette release Gui......
Enfin des fois ca part en couille (surtout après une exécution foreuse de uttk en mode cache): zugarramundi:..uby/ttk/trunk:127>svn st , ,messages + vendor ? svn + .vcs + myTODO + +commited M test/examples/cache/simple.yml M lib/uttk/status.rb + bin/driver.rb + bin/getopts/options.rb M bin/uttk Il faut que je fasse un reset pour rétablir le tout... Je pense que ce ne doit pas être une options par défaut. grep ou ls ne font pas la couleur par défaut que je sache. En conclusion: je dit oui à la kyrielle de fonctionnalités mais si elles ne sont pas mise par défaut. Comme ça, si je veux les utilisé je les actives moi même une à une en conséquence de cause et je reconnais mon vcs d'une version sur l'autre. En plus, ça force la documentation puisque si elle ne sont pas documenté, je ne les découvrirai pas (puisqu'elles ne sont pas par défaut). Néanmoins, cette release est pleine de bonnes idées et montre la puissance de l'outil. a+ -- Nicolas Desprès